How to Build a Cybersecurity Risk Assessment Management Understands

Most risk reports end up in a drawer for the same reason: they were written for the technical team. They talk about CVSS scores, attack surface and compensating controls, when the person approving the budget only needs three things: which part of the business is exposed, what happens if it fails, and what it costs to reduce that exposure. A cybersecurity risk assessment that the board actually understands is built in that order, from the business down to the technology, and it fits on one page.

Start with what the company cannot afford to lose

Before looking at a single server, write down the things that would stop your revenue if they disappeared tomorrow. In a company of 10 to 50 employees that list is short and usually fits in half a page: the ERP or management software, email, the ordering system or online shop, the shared drives where work in progress lives, and access to online banking.

Then add the personal data you handle: customers, employees, applicants and suppliers. Once personal data is involved, an incident stops being purely operational and picks up legal deadlines. Article 33 of the GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a breach, and that clock runs whether or not you have an inventory ready.

This first step is the one most people skip and the one that saves the most time later. Without it, the assessment turns into a list of technology with no priorities.

Turn threats into scenarios people can argue about

"Ransomware risk" is a label nobody can debate in a management meeting. "An employee opens an attachment, the shared drives and the ERP get encrypted, and we stop invoicing for several days" can be debated, because it describes the whole path: where it gets in, how far it reaches, and what stops working.

For a small company, four or five scenarios cover almost the entire picture:

• Ransomware encrypting shared drives and halting operations.
• CEO fraud or supplier impersonation redirecting a payment.
• Stolen corporate email credentials exposing customer conversations.
• An extended outage at a cloud provider your daily work depends on.
• Personal data leaking from an internet-facing application.

Each scenario is described in two or three sentences. If you need more, you are probably mixing two separate scenarios and should split them.

Measure impact in money and in days

A colour-coded matrix says very little to whoever runs the books. Impact lands when it is expressed in the same units as every other business decision. For each scenario, estimate:

• Likely days of downtime, multiplied by your average daily revenue.
• Staff hours diverted to handling the incident, at their hourly cost.
• Cost of emergency outside help and of rebuilding systems.
• Customers or contracts at risk, with their annual billing.
• Legal and notification work if personal data is affected.

None of those figures needs a market statistic. They come out of your own accounts and your own calendar, which is why they hold up well against awkward questions in a meeting. An imperfect number drawn from your own data is more persuasive than a flawless percentage lifted from somebody else's report.

Estimate likelihood from evidence

The second half of the calculation is how exposed you are today to each scenario. This is where the technical work belongs, and it should rest on real observations: which of your services are reachable from the internet and on which versions, which accounts have no second factor, how many users still hold administrator rights they no longer need, whether backups have ever actually been restored, and what happens to someone's access on the day they leave the company.

A vulnerability management cycle running on a regular schedule produces exactly that evidence and keeps it current. Without it, the likelihood column gets filled in by intuition and the assessment loses authority in the one place it needs it most.

From matrix to plan: who does what, and by when

An assessment that ends with a ranked list of risks is only half finished. The part management signs off comes next, and it fits in four columns: the risk, the measure that reduces it, a named owner, and a deadline with a cost. Without an owner and a date, a measure is an intention.

Decide explicitly which risks you accept, too. Accepting a risk with a date and the signature of whoever owns it is a perfectly valid management decision, and it leaves a record that the question was considered. The risks nobody mentions are the ones that resurface in the middle of an incident.

What the one-page version looks like

The management version follows a simple table: the five scenarios, estimated impact in money and days, how exposed we are today, the proposed measure and its cost. The full technical report sits behind it as an annex, for whoever has to carry the work out.

That page is also what answers the security questionnaires arriving from large clients. When someone asks whether you have a formal risk assessment and how often you review it, the answer is already written.

How often to repeat it

A risk assessment ages along with the company. A full review once a year is reasonable, plus a targeted update whenever something material changes: a new ERP, a new site, a different critical supplier, a new line of business, or a large client who starts sending you questionnaires.

That last case keeps getting more common. The NIS2 directive reaches medium and large entities in certain sectors, so a company of 10 to 50 employees is almost always outside its direct scope. Its larger clients are inside it, and they push requirements downstream through contracts and questionnaires. Arriving with the assessment already done turns that conversation into a formality.

If you would rather start from an established methodology than build one from scratch, our cybersecurity risk assessment service produces that one-page document with its technical annex, and a security assessment supplies the technical evidence behind the likelihood column.