Security Risk Assessment: A Practical Guide for Business Leaders

A security risk assessment is a structured review of what could go wrong with the systems and data your business depends on. It identifies the assets that matter, the threats to them, and the weaknesses those threats could exploit, then rates each risk by likelihood and impact so leadership can decide what to fix first, what to insure, and what to accept.

You need one before you can make defensible security decisions, and several regulations require one outright. HIPAA covered entities and business associates need a risk analysis. Companies that handle card data need PCI DSS targeted risk analyses. SOC 2 and ISO 27001 auditors will ask to see your risk assessment. Outside of compliance, the practical triggers are a new board or investor asking how exposed you are, a merger or major system change, a serious incident, or a security budget that nobody can tie to specific risks.

This guide walks through how to run one at a 50 to 2,000 person company, using the methods that NIST, ISO and the regulators actually publish.

What the standards say a risk assessment is

The most widely used method is NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments. It breaks the process into four steps: prepare for the assessment, conduct the assessment, communicate the results, and maintain the assessment over time. The conduct step is where the analysis happens: identify threat sources, identify the threat events they could cause, identify vulnerabilities and predisposing conditions, determine likelihood, determine impact, and combine likelihood and impact into a level of risk.

The NIST Cybersecurity Framework 2.0 puts the same idea in outcome form. Its Risk Assessment category (ID.RA) expects that vulnerabilities in assets are identified and recorded, that internal and external threats are identified, that potential impacts and likelihoods are recorded, and that threats, vulnerabilities, likelihoods and impacts are used to prioritize risk response. The GOVERN function adds the management side: risk appetite and tolerance statements (GV.RM-02) and a standardized method for calculating, documenting, categorizing and prioritizing cybersecurity risks (GV.RM-06).

ISO/IEC 27005:2022 is the international counterpart. It gives guidance for meeting the ISO/IEC 27001 requirements on information security risk assessment and treatment, and it applies to organizations of any type or size. If you are pursuing ISO 27001 certification, your method should line up with it.

None of them require a particular tool. They require a defined method, applied consistently, that drives decisions.

Types of security assessments and how they differ

Buyers often use "risk assessment" to mean any security review. The four common types answer different questions, and mixing them up is how companies end up with a long scan report and no idea what to do next.

Assessment type	Question it answers	Typical output
Security risk assessment	Which risks to the business matter most, and what should we do about each?	Rated risk register and treatment plan
Vulnerability assessment	What known technical weaknesses exist in our systems?	List of findings from scanning, ranked by technical severity
Penetration test	Can a skilled attacker actually get in, and how far can they go?	Narrative of exploited paths with evidence and fixes
Controls assessment	Are the controls we claim to have designed and working as intended?	Control-by-control gap findings against a framework

A vulnerability assessment and a penetration test are inputs to a risk assessment. They tell you what is weak. The risk assessment tells you which of those weaknesses could hurt the business, how badly, and how likely that is given your threats and existing defenses. A controls assessment checks your safeguards against a framework such as SOC 2 or CIS; we cover that method in our guide to IT security controls assessments. In a mature program, all four feed the same risk register.

How to conduct a security risk assessment, step by step

The steps below follow the NIST SP 800-30 structure, adapted for a company without a dedicated risk team.

1. Define purpose, scope and method

Write down why you are doing the assessment (compliance, a board request, a new system), what is in scope, and what is not. Scope can be the whole company, one business unit, or one environment such as the systems that touch cardholder data. Then pick your scales for likelihood and impact before you start rating anything. Agreeing on the scales up front is what keeps the results consistent between assessors and from one year to the next.

2. Identify and rank assets

List the things whose loss or compromise would hurt: customer and employee data, the systems that generate revenue, financial systems, intellectual property, and the identity platform that controls access to everything else. For each one, note the owner and what the business impact would be if its confidentiality, integrity or availability were lost.

3. Identify threat sources and threat events

NIST SP 800-30 separates adversarial threat sources (criminal groups, insiders, competitors) from non-adversarial ones (human error, system failure, natural events). For each relevant source, describe the events it could cause against your assets: ransomware on file servers, business email compromise against finance, an administrator misconfiguring cloud storage, a key vendor going offline.

4. Identify vulnerabilities and existing controls

For each threat event, list the weaknesses that would let it succeed and the controls already in place that reduce it. Pull from scans, test and audit findings, and interviews with the people who run the systems. A missing control is a vulnerability. So is a control that exists on paper but is not enforced.

5. Determine likelihood and impact

Rate how likely each threat event is to occur and succeed given current controls, and how severe the impact would be if it did. Use the scales you defined in step 1. Write a one-line rationale for every rating. Ratings without reasoning cannot be defended to an auditor or revisited next year.

6. Determine the level of risk

Combine likelihood and impact into a risk level using your matrix (see the next section). Then sort. The output of this step is a ranked list where the top items are the ones leadership should spend time and money on.

7. Decide on treatment and assign owners

For each risk above your tolerance, choose a treatment, name an owner, and set a target date. Risks below tolerance are recorded and accepted. NIST CSF 2.0 frames this as ID.RA-06: risk responses are chosen, prioritized, planned, tracked and communicated.

8. Communicate and maintain

Present the results to the people who own the decisions, usually in a short executive summary with the top risks and recommended actions. Then keep it current. NIST SP 800-30 treats ongoing monitoring of risk factors and updating the assessment as a formal step, not an afterthought.

Scoring risk with a likelihood and impact matrix

NIST SP 800-30 uses five levels for both likelihood and impact (very low, low, moderate, high, very high) and provides a table that maps each combination to a risk level. A simple way to implement this is to score each factor from 1 to 5 and multiply. The matrix below shows the result.

Likelihood / Impact	1 Very low	2 Low	3 Moderate	4 High	5 Very high
5 Very high	5	10	15	20	25
4 High	4	8	12	16	20
3 Moderate	3	6	9	12	15
2 Low	2	4	6	8	10
1 Very low	1	2	3	4	5

One reasonable banding: 1 to 4 is low, 5 to 9 is moderate, 10 to 16 is high, and 20 to 25 is critical. Your bands should reflect your risk appetite, which is exactly what GV.RM-02 in CSF 2.0 asks you to define. Two practical cautions. First, define each level in business terms. "High impact" should mean something concrete, such as a multi-day outage of order processing or a breach notification to customers, not a feeling. Second, multiplication is a convenience. A rare but catastrophic risk (likelihood 1, impact 5) scores the same as a frequent nuisance (5 times 1), so review anything with a 5 in either column by hand.

A worked threat, vulnerability and risk example

Here is one row done well. The example is illustrative, not drawn from a client.

Field	Entry
Asset	Finance team email and the accounts payable process
Threat source and event	Criminal group sends a spoofed vendor email requesting a change of bank details (business email compromise)
Vulnerability	No out-of-band verification for payment detail changes; MFA not enforced on two finance mailboxes
Existing controls	Email filtering, annual phishing training
Likelihood	4 (High): finance is a frequent target and the verification gap is easy to exploit
Impact	4 (High): a single fraudulent wire could be material and may not be recoverable
Risk	16, High
Treatment	Mitigate: require call-back verification to a known number for any bank detail change, enforce MFA on all mailboxes. Owner: Controller. Target: 30 days. Expected residual risk: 2 x 4 = 8, Moderate

Note the residual risk line. Recording what the risk should drop to after treatment is what lets you show progress later and justify the spend.

Risk treatment options

NIST defines risk response as accepting, avoiding, mitigating, sharing or transferring risk. In practice most companies work with four:

• Mitigate. Add or strengthen controls to reduce likelihood or impact. This is the default for most high risks.
• Transfer (or share). Move part of the financial consequence to someone else, usually through cyber insurance or contract terms with a vendor. The risk itself does not go away. Your insurer will also ask about your controls.
• Accept. Leave the risk as it is because it is within tolerance or the fix costs more than the exposure. Acceptance should be a documented decision by someone with authority, with a review date, not a silent default.
• Avoid. Stop the activity that creates the risk: retire the legacy system, stop storing the data, drop the feature.

What the risk assessment report and risk register should contain

The report and the register serve different readers. The report is a point-in-time document for leadership and auditors. The register is the living record you work from every month.

A security risk assessment report should include:

• An executive summary: the top five to ten risks in plain language, and the decisions needed.
• Purpose, scope, exclusions, dates and who performed the assessment.
• The method: data sources, likelihood and impact scales, the risk matrix, and assumptions.
• Findings: each risk with its threat, vulnerability, ratings and rationale.
• Recommended treatments with owners and timelines.
• Risks accepted, and by whom.

A risk register should hold, for each risk: an ID, the asset, the threat and vulnerability, existing controls, likelihood, impact and inherent risk score, the treatment decision, the owner, the due date, current status, residual risk score, and the date it was last reviewed. If a field is routinely blank, either fill it or remove it. A register nobody updates is worse than none, because it gives false comfort.

What HIPAA and PCI DSS require

HIPAA. The Security Rule at 45 CFR 164.308(a)(1)(ii)(A) requires covered entities and business associates to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information." The HHS guidance on risk analysis does not prescribe a method or a fixed frequency. It lists the elements it expects to see: scope of the analysis, data collection, identifying and documenting threats and vulnerabilities, assessing current security measures, determining likelihood, determining potential impact, determining the level of risk, finalizing documentation, and periodic review and updates. HHS notes that some organizations perform the analysis annually and others as needed depending on their environment. Our HIPAA compliance services are built around that structure.

PCI DSS. Version 3.2.1 required an annual, organization-wide risk assessment (Requirement 12.2). Version 4 replaced it with targeted risk analyses. Requirement 12.3.1 applies wherever a requirement lets you set how often an activity is performed. Each analysis must be documented and must identify the assets being protected, the threats the requirement protects against, and the factors that contribute to likelihood or impact, and it must justify how your chosen frequency or process minimizes that risk. Each analysis is reviewed at least once every 12 months. It became mandatory on 31 March 2025. The current version is PCI DSS v4.0.1. See our PCI compliance services if you are working through these.

Frequently asked questions

What are the types of security risk assessments?

The four common types are a security risk assessment, a vulnerability assessment, a penetration test and a controls assessment. A risk assessment rates business risks by likelihood and impact and decides treatment. A vulnerability assessment scans for known technical weaknesses. A penetration test proves whether an attacker can exploit them. A controls assessment checks whether your safeguards meet a framework such as SOC 2, ISO 27001 or CIS.

How often should you do a security risk assessment?

A common practice is a full assessment once a year, updated whenever something significant changes: a new system, an acquisition, a major vendor, or a serious incident. HIPAA does not set a fixed interval, though HHS expects periodic review. PCI DSS requires each targeted risk analysis to be reviewed at least once every 12 months. The register itself should be reviewed monthly or quarterly.

What is the difference between a risk assessment and a vulnerability assessment?

A vulnerability assessment finds technical weaknesses, usually with scanning tools, and ranks them by technical severity. A risk assessment asks which of those weaknesses, plus process and people gaps, could actually harm the business, how likely that is, and how bad it would be. Vulnerability findings are one input to a risk assessment, not a substitute for it.

What should a security risk assessment report include?

A good report includes an executive summary of the top risks, the scope and dates, the method and scoring scales used, each finding with its threat, vulnerability, likelihood, impact and rationale, recommended treatments with owners and deadlines, and a record of risks that leadership has formally accepted. It should be readable by a board member and detailed enough for an auditor.

What is a threat, vulnerability and risk assessment?

It is a security risk assessment that documents three things for each scenario: the threat (who or what could cause harm, such as a ransomware group), the vulnerability (the weakness it would exploit, such as unpatched remote access), and the resulting risk (likelihood multiplied by impact). Recording all three in one row makes each rating traceable and makes treatment decisions easier to justify.

Getting started

If you have never done one, start small: pick your most important business process, run the eight steps against it, and build the register from there. If you want an outside view, our security self-assessment takes a few minutes and shows where your program stands. For a full assessment led by a senior practitioner, BlueRadius runs risk assessments as part of our virtual CISO services, and you can book a free consultation to talk through scope.