A cybersecurity risk assessment is not a vulnerability scan, and it is not a compliance checklist. It is a structured attempt to answer three questions: what could go wrong, how bad would it be, and what should we do about it first. Done well, it produces decisions. Done poorly, it produces a spreadsheet nobody opens again.
The method below is deliberately lightweight. It is designed for organizations that need a defensible process without a dedicated risk function.
1. Define the scope before anything else
Assessments fail most often at the start, by being scoped either so broadly that nothing gets adequate attention or so narrowly that the real exposure sits outside the boundary. Write the scope down explicitly, including what is excluded and why.
- Which business processes and systems are in scope
- Which locations, networks and cloud accounts are included
- Which third parties and vendor connections are included
- What is explicitly out of scope, and what risk that leaves unmeasured
2. Inventory what you are protecting
You cannot assess risk to assets you have not enumerated. The inventory does not need to be perfect, but it needs to cover the things whose loss or compromise would actually matter: systems that hold sensitive data, systems the business cannot operate without, and the identities and infrastructure that control access to both.
For each significant asset, record the business process it supports, the data it holds, who owns it, and what the organization would do if it were unavailable for a day, a week, or permanently.
3. Identify realistic threats
Threat identification should be grounded in what actually happens to organizations like yours, not in a catalogue of everything theoretically possible. For most mid-market organizations, the dominant scenarios are narrow and well documented.
- Credential compromise leading to business email compromise or fraudulent payment
- Ransomware entering through remote access, phishing or an unpatched internet-facing service
- Compromise of a vendor or service provider with access to your environment
- Misconfiguration exposing data or a management interface to the internet
- Insider error — deletion, misdirected data, misconfigured sharing
4. Assess likelihood and impact honestly
Precision here is false comfort. A simple three- or five-point scale applied consistently is more useful than a numerical model built on estimates nobody can defend. What matters is that the same people apply the same scale across all scenarios, and that they write down the reasoning.
Impact should be expressed in business terms: operational downtime, financial loss, regulatory exposure, contractual breach, reputational harm. Likelihood should account for the controls you actually have in place and operate — not the ones you have licensed.
5. Evaluate the controls that exist
For each significant scenario, identify which controls would prevent it, which would detect it, and which would limit the damage. This is where most assessments produce their most valuable findings, because the gap between a control being purchased and a control being operated is consistently wide.
- 1Is the control deployed everywhere it needs to be, or only partly?
- 2Is it configured to actually block, or is it in monitor mode?
- 3Does anyone see its output, and would they act on it?
- 4Has it been tested against the scenario it is supposed to address?
6. Produce a prioritized plan, not a list of findings
The output of a risk assessment should be a sequence of actions with owners, effort estimates and the specific risk each one retires. Group findings by root cause so one remediation closes several items, and separate work that can be done this month from work that requires architectural change.
Document accepted risks explicitly, with the name of the person accepting them and a review date. Risk acceptance is a legitimate decision; undocumented risk acceptance is just an unmanaged risk.
7. Set a review cadence
A risk assessment describes a moment in time. Environments change, and so does the threat landscape. An annual full reassessment with quarterly review of the register is a reasonable baseline for most organizations, with an out-of-cycle review triggered by significant change — an acquisition, a new platform, a major architectural shift, or an incident.
Common failure modes
- Scoring everything as high, which removes the ability to prioritize
- Assessing documented controls instead of operating controls
- Producing a register with no owners and no dates
- Treating the assessment as the deliverable rather than the decisions that follow it
- Never revisiting accepted risks