Aim for decisions, not just a score
Maturity scores and heat maps are useful signals, but on their own they don't tell anyone what to do next week. A useful risk assessment answers the questions leadership actually has.
- Which risks matter most to this business, and why?
- What should we fix first, and what can wait?
- Roughly what will it take in effort, money, and time?
- Who owns each piece of work?
How to do a risk assessment: the four steps in NIST SP 800-30
NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments (September 2012), breaks the process into four steps. It was written for federal information systems and organizations, but the steps give any organization a method it can repeat and explain.
- Prepare for the assessment.
- Conduct the assessment.
- Communicate and share the results.
- Maintain the assessment.
Prepare: purpose, scope, and method
Preparation settles what the assessment is for and how it will be done, so its results can be compared and repeated later. NIST lists five preparation tasks:
- Identify the purpose: the decisions the results will inform.
- Identify the scope: which parts of the organization and which systems, over what time frame.
- Record the assumptions and constraints the assessment works under.
- Identify where threat, vulnerability, and impact information will come from.
- Choose the risk model and analytic approach, including the scales you'll use for likelihood and impact.
Conduct: threats, vulnerabilities, likelihood, and impact
The assessment itself works through six tasks and ends with a level of risk for each threat event that matters. NIST SP 800-30 assesses risk as a combination of likelihood and impact, and suggests ordering threat events by their level of risk, so the greatest attention goes to the highest risks.
- Identify and characterize the threat sources of concern.
- Identify the threat events those sources could cause.
- Identify the vulnerabilities and predisposing conditions that make those events more likely to cause harm.
- Determine how likely each threat event is to result in adverse impacts.
- Determine the adverse impacts if it does.
- Determine the risk, as a combination of likelihood and impact.
Communicate: get the results to the people who decide
Results matter only when decision makers get them in a form they can use. The third step is to communicate the results to the organization's decision makers to support risk responses, and to share risk-related information with the people who need it. The leadership summary described later in this guide is one way to do that.
Maintain: monitor and update
The fourth step keeps the assessment current: monitor the risk factors that change your risk, and update the assessment with what monitoring finds. A risk register that owners update between assessments is the practical tool for both.
Use a shared frame: NIST CSF 2.0 and CIS Controls
Anchoring the assessment to recognized frameworks makes results comparable over time and easier to explain to customers, auditors, and boards. NIST CSF 2.0 describes outcomes rather than specific products or settings, across six Functions.
The CIS Controls complement the CSF with specific safeguards and Implementation Groups that suggest where to start. Mapping findings to both gives leaders a common language and gives engineers concrete tasks.
- Govern: strategy, roles, policy, oversight, and supply chain risk.
- Identify: understanding assets, risks, and where to improve.
- Protect: safeguards such as identity management, training, and data security.
- Detect: finding and analyzing possible attacks and compromises.
- Respond: taking action on a detected incident.
- Recover: restoring the assets and operations an incident affected.
Describe where you are and where you need to be
Start with business context: what you sell, which data you hold, which laws and contracts apply, and how much risk leadership is willing to accept. That context sets the target.
CSF 2.0 frames this as a Current Profile and a Target Profile. The gap between them, weighed against your context, is what the roadmap should close.
Base the current picture on evidence, not only on interviews and questionnaires. Reviewing configurations, access lists, and records shows how controls actually operate.
Rank risks in terms leaders recognize
Write each significant risk as a scenario with a cause and a consequence, not as a missing control. “An attacker uses a reused password to reach the admin console and export customer records” is easier to prioritize than “MFA not enforced.”
Record the results in a risk register so they can be tracked, reviewed, and formally accepted where appropriate. If everything is rated high, the ranking isn't doing its job.
- The assets and data involved.
- Likelihood and impact, with the reasoning behind each rating.
- Existing controls that already reduce the risk.
- A recommended treatment: reduce, transfer, avoid, or accept.
What a risk register entry looks like
A register doesn't need special software; a shared spreadsheet works if someone owns it. What matters is that each entry reads as a scenario, shows the reasoning behind its ratings, and names who will act. The entries below are invented examples of the format, not findings from any organization.
Keep the scales you chose during preparation, and write down why each rating was given. When the next assessment disagrees with this one, the reasoning shows whether the risk changed or only the opinion did.
| Risk scenario | Likelihood, and why | Impact, and why | Treatment and owner |
|---|---|---|---|
| An attacker uses a reused password to reach the admin console and export customer records | Moderate: multifactor authentication isn't enforced on admin accounts | High: exposure of customer data and loss of customer trust | Reduce: enforce multifactor authentication on every admin account. Owner: IT lead |
| Ransomware encrypts the file servers and the backups they can reach | Moderate: backups sit on the same network and can be overwritten | High: operations stop until systems are restored | Reduce: keep an offline or immutable backup copy and test restores. Owner: infrastructure lead |
| A breach at the payroll provider exposes employee records | Low: the provider shares a current SOC 2 report with no relevant exceptions | Moderate: employee data exposure and the work of responding to it | Transfer and monitor: contract terms plus a yearly report review. Owner: finance lead |
Turn findings into a roadmap with owners
The roadmap is where an assessment becomes a plan. Sequence the work so early steps reduce the most risk and make later steps easier.
Every roadmap item needs a named owner, an effort estimate, its dependencies, a target date, and a clear definition of done.
- Near-term actions that close serious exposures quickly.
- Foundational projects, such as an asset inventory or centralized logging, that other improvements depend on.
- Longer-term program work, such as vendor risk management or a regular policy review cycle.
Give leadership a summary they can act on
Executives and boards need a short summary: the top risks in business terms, the decisions needed from them, the budget and staffing implications, and any risks they are being asked to accept.
Keep the technical detail in appendices, where the teams doing the work can find it.
Keep it current
A risk assessment describes a moment in time. Revisit it on a regular schedule and after major changes, such as a new product, an acquisition, a move to a new cloud platform, or a significant incident.
Some rules set this expectation directly. The HIPAA Security Rule requires a periodic evaluation, including in response to environmental or operational changes (45 CFR 164.308(a)(8)), and ongoing review of security measures as needed (164.306(e)). ISO/IEC 27001 requires a defined risk assessment process (clause 6.1.2) inside a management system the organization maintains and continually improves (clause 4.4). Tracking roadmap progress and updating the register between assessments makes the next one faster and more useful.