A risk assessment directs limited security resources toward threats that could disrupt revenue, operations, compliance, or customer trust. A likelihood-by-impact matrix can rank findings. But one score cannot prove controls reduced exposure or show who owns the decision.
A risk assessment is a repeatable process. It identifies threats, weaknesses, business impact, and control gaps. It then ranks treatment decisions. Build one with scope, a likelihood-by-impact matrix, named owners, inherent and residual scores, and review dates. NIST SP 800-30 offers a widely used U.S. framework for defensible, auditable records.
Summary of the process
A defensible assessment does not start with a color-coded matrix. It starts with a leadership decision.
- Set scope and decision criteria: Define the asset, process, business goal, evidence standard, and accepted exposure.
- Identify the scenario: Link a threat, weakness, and business consequence in one clear risk statement.
- Score inherent risk: Estimate likelihood and impact before crediting existing safeguards.
- Test controls: Check coverage, settings, logs, and response ability. Do not trust a policy document alone.
- Score residual risk: Estimate exposure after tested controls. Then choose treatment and a review date.
- Maintain the register: Keep evidence, ownership, approvals, and changes to support an audit.
A 5×5 matrix helps decisions. It is not a universal standard. Its score bands must match the approved risk appetite. Risk appetite means the exposure leaders accept while pursuing business goals.
Start with the business decision
A risk is more than a technical flaw. It is the chance that an event blocks revenue, operations, safety, customer commitments, or legal duties.
A score only helps when it leads to a named decision, owner, and date.
Keep the minimum audit evidence
An auditor should trace a risk from its first observation to its current status. The record needs the asset or process, source evidence, threat, cause, weakness, controls, scores, owner, treatment, and dates.
Choose the method based on the decision, available data, and compliance duty. A qualitative method uses labels like low, medium, and high when loss data is limited. A quantitative method estimates financial loss, downtime, or event frequency when credible data exists.
A semi-quantitative matrix offers a practical middle ground for many teams. NIST SP 800-30 helps structure information-security assessments. ISO 27005 can align this work with an ISO management system.
The same register can support project delays, supplier concentration, safety, production outages, and financial controls. Each domain must define relevant impact criteria and control evidence.
Set scope with the 5 cs
The 5 Cs create a decision-focused boundary for an assessment.
Define context and criteria
Context states what needs protection and why. It may cover online checkout, HR payroll, a factory line, a cloud app, or a planned acquisition.
Criteria defines likelihood and impact scores. It should state required evidence, financial or operating limits, escalation rules, and residual exposure that needs executive approval.
Clear criteria prevent teams from debating labels instead of evidence.
Define consequences and controls
Controls are safeguards that reduce likelihood, impact, or both. Multi-factor authentication (MFA) asks for more than one identity proof. Encryption protects stolen data from being read without a key.
An endpoint detection and response tool (EDR) watches devices for suspicious behavior. Think of it as a security camera with alerts. It helps teams spot harmful activity.
The most common error is treating a listed control as an effective control. A firewall rule, MFA policy, or backup platform may fail. Coverage may be incomplete, settings weak, alerts ignored, or restoration untested.
Use this test: Can the team show where the control applies and when it last worked? Can it show who receives alerts and how quickly that person acts? If not, give the control limited credit in the residual score.
Separate the terms before debate starts
A hazard is a possible source of harm. Examples include energized machinery, customer data, or a volatile supplier market. A threat is an event or actor that could cause harm.
Threats include phishing, equipment failure, and fraud. A vulnerability is a weakness that makes harm possible. Examples include excess access, missed maintenance, or weak approval rules.
Risk combines the likelihood and business impact of that scenario. A control prevents, detects, or corrects harm. It can change likelihood, impact, or recovery time.
Risk appetite sets the exposure leadership will accept. Documentation alone does not make an uncontrolled risk acceptable.
These terms set the base for consistent scoring.
Score inherent and residual risk
Score each scenario twice.
Build scoring bands around appetite
A 5×5 model produces scores from 1 to 25. It supports cross-functional decisions. Written definitions ensure a score of 4 means the same thing in finance, operations, and security.
| Score range | Decision rule | Review cadence |
|---|
| 1–4 | Accept within approved appetite | Every 12 months |
| 5–9 | Monitor and assign owner | Every 6 months |
| 10–16 | Fund mitigation plan | Every 30–90 days |
| 17–25 | Escalate or stop activity | Weekly until reduced |
Work through one zero trust example
Consider this scenario: a contractor keeps broad cloud rights after a project ends. A phishing attack compromises that account. The attacker then accesses customer data in production.
Before controls, likelihood is 4. Contractor accounts use external email and have broad access. Impact is 5 because the data is regulated and supports a revenue-critical app.
The inherent score is 20.
A control that cannot stop, detect, or support recovery should not receive full scoring credit.
Make the score evidence-based
Likelihood should reflect exposure, attacker skill, past events, and control gaps. Impact should reflect data class, downtime limits, contract duties, replacement cost, and recovery capacity.
From finding to auditable decision
Scope
asset + objective
→
Inherent score
before controls
→
Test controls
evidence required
→
Residual decision
owner + review date
Continue the contractor-account scenario by testing relevant controls. Evidence shows enforced MFA and quarterly access reviews. Offboarding removes cloud roles within 24 hours.
Dormant-account monitoring is not automated. The team may reduce likelihood from 4 to 2. Impact stays at 5 because a compromise could expose regulated customer data.
The inherent score is 4 × 5 = 20. The residual score is 2 × 5 = 10.
The risk owner approves a treatment plan for automated account removal. An IAM manager owns it. The record includes audit evidence and a review date 30 days after completion.
A defensible assessment scores inherent exposure before controls, then scores residual exposure after testing. This approach works when evidence exists and owners have decision authority. It does not replace a required PCI DSS assessment or an active-incident process. Link each residual score to an owner, treatment choice, and review date. That creates an auditable decision, not just a heat map.
Build an auditable risk register
A register must stay current.
Use this reproducible register template
Copy these columns into a controlled spreadsheet, GRC platform, or database. Keep links to evidence. Do not paste sensitive logs or credentials into the register.
| Field | What to record |
|---|
| Risk ID and affected asset | Unique ID, business process, system, data class, and dependency |
| Scenario and cause | Threat, vulnerability, cause, consequence, and evidence link |
| Inherent and residual scores | Likelihood, impact, control effectiveness, and scoring rationale |
| Decision and ownership | Risk owner, control owner, treatment, approver, budget, and target date |
| Review trail | Review date, status, version, change history, and exception approval |
Assign owners with decision authority
The risk owner is accountable for the business result. That person is not always the security manager. The owner needs authority to accept, reduce, transfer, or avoid the risk.
Transfer can include insurance or contract terms. Avoidance means stopping the activity that creates the exposure. A team label alone does not create accountability.
Use a spreadsheet for a small, stable set of risks. Use a GRC platform when many teams need approval trails and role-based access. Use a database when teams need custom reports or links to technical evidence.
The tool matters less than disciplined updates and clear ownership. A stale register gives leaders a false sense of control.
A living register makes control gaps visible before they become incidents.
Test zero trust access paths
Zero Trust changes what teams must test.
Test identity and privilege first
Map the route from the identity provider to the app, cloud role, database, and privileged command. Test identity and access management (IAM), MFA coverage, conditional access, service accounts, privileged access, dormant accounts, and contractor offboarding.
A practical test asks whether an unmanaged device can reach sensitive data. It also asks whether a compromised session or expired contractor account can gain access. If yes, residual likelihood should remain high.
Broad MFA deployment does not fix every access path.
Test containment and response
Review endpoint telemetry, EDR or extended detection and response (XDR), network segments, cloud settings, backups, and incident exercises. A control is stronger when alerts give enough context for action within the business downtime limit.
Evidence can include configuration exports, access logs, policy tests, penetration-test findings, tabletop results, incident records, and exception reports. Collect evidence for normal behavior and failure conditions.
This works well in theory, but practice reveals missed paths. A common case involves protected employee accounts but unmanaged service accounts. The service account bypasses MFA and keeps production access.
Do not use this general method alone during an active incident or emergency decision. Do not use it alone for a mandated formal assessment. PCI DSS, a GDPR data protection impact assessment, business impact analysis, and some government programs require their own evidence, scope, and approvals. Follow the required framework first. Then link its findings to the enterprise register.
Testing the full access path shows where Zero Trust controls actually fail.
What people ask
What are the five steps of risk assessment?
The five steps are scope, scenario identification, inherent scoring, control testing, and residual treatment with review. Each step should record evidence, an owner, and a decision threshold.
What are the 5 cs of risk assessment?
The 5 Cs are Context, Criteria, Consequences, Controls, and Communication. They connect scores to business goals, defined scales, tested safeguards, and authorized decision-makers.
How do I write a risk assessment?
Write a cause-threat-consequence statement, then score inherent likelihood and impact. Test controls and score residual risk. Add the asset, evidence link, owner, treatment choice, target date, and review date to a controlled register.
Is a CVSS score a risk assessment?
A CVSS score measures technical weakness severity, not full business risk. Add exposure, affected data, business dependency, controls, and recovery ability before setting remediation priority.
Make risk reduction visible
A well-run assessment makes uncertainty manageable.
- Score inherent risk before controls so leaders can see starting exposure.
- Score residual risk after testing controls, including coverage, settings, telemetry, and response.
- Give each material risk a business owner and review date, not a generic team label.
- Link each score to evidence and treatment so the register can withstand audit review.
- Test Zero Trust by access path, from identity through privilege and data, not product inventory.
The goal is not a prettier heat map. The goal is a living record of accepted and reduced exposure. It should show whether the organization can prove the difference.
Related sources
These articles can help you explore the topic in more depth:
