ISO 27001 Risk Register Explained: Building and Maintaining Your Risk Assessment

One of the most common things we hear from companies starting their ISO 27001 journey is: "We know we need a risk register, but we have no idea what should actually be in it." This is not a documentation exercise. The risk register is the engine that drives your entire information security management system — it determines which controls you implement, how you allocate security resources, and what you include in your Statement of Applicability. Get it wrong and you are building your ISMS on a foundation of guesswork. Get it right and every subsequent decision in your certification program has a clear, defensible rationale.

This guide covers everything you need to build and maintain an ISO 27001 risk register that satisfies auditors and genuinely improves your security posture: risk identification methodology, assessment criteria, treatment options, ownership assignment, ongoing maintenance, and the critical link between your risk register and your Statement of Applicability.

What the Standard Requires

ISO 27001 Clause 6.1.2 requires organizations to define and apply an information security risk assessment process. Specifically, you must establish risk criteria (including acceptance criteria), ensure the process produces consistent, valid, and comparable results, identify information security risks, analyze the likelihood and consequences of those risks, and evaluate risks against your defined criteria to prioritize treatment.

What we tell clients is that the standard is deliberately non-prescriptive about methodology. You have flexibility in how you identify, assess, and document risks. What matters is that your approach is systematic, repeatable, and documented — and that your auditor can trace a clear line from identified risks through treatment decisions to implemented controls.

Risk Identification Methodology

Risk identification is where the quality of your entire risk assessment is determined. In our experience, organizations that rush through identification end up with a register full of generic, unhelpful entries like "data breach" or "system failure" that do not drive meaningful control decisions.

Asset-Based Approach

What we recommend for most organizations is an asset-based risk identification approach. This starts with your information asset inventory and asks: for each asset, what threats could exploit what vulnerabilities to cause what impact?

The process follows three steps:

Step 1 — Identify information assets. These include data stores (databases, file shares, SaaS applications), systems (servers, endpoints, network devices), processes (software development, customer onboarding, incident response), and people (employees, contractors, third parties with access).

Step 2 — Identify threats to each asset. Threats are potential events that could harm an asset. Examples include unauthorized access by external attackers, accidental data exposure by employees, service outages from infrastructure failures, data loss from ransomware or corruption, and supply chain compromise through third-party providers.

Step 3 — Identify vulnerabilities that threats could exploit. Vulnerabilities are weaknesses that make a threat more likely or more impactful. Examples include unpatched software, weak authentication mechanisms, lack of encryption, insufficient backup processes, and absence of access reviews.

Each combination of asset, threat, and vulnerability produces a risk scenario. In our experience, a mid-size technology company typically identifies 40 to 80 risk scenarios during their initial assessment. What we tell clients is that this number should feel manageable — if you have 200 risks in your register, you have likely gone too granular and will struggle to maintain the register over time.

Threat Intelligence Sources

To ensure comprehensive identification, what we recommend is drawing from multiple sources:

• Internal incident history: Past security incidents and near-misses are direct evidence of realized risks.
• Industry threat reports: Sources like the ENISA Threat Landscape, Verizon DBIR, and sector-specific advisories help identify threats relevant to your industry.
• Vulnerability assessments: Results from penetration testing, vulnerability scanning, and cloud security posture assessments reveal specific technical weaknesses.
• Workshop sessions: Facilitated sessions with department heads surface operational risks that purely technical assessments miss.
• Regulatory requirements: Applicable regulations identify categories of risk that must be addressed regardless of your internal assessment.

Risk Assessment Criteria

Once risks are identified, each one must be assessed for likelihood and impact. What we recommend is a simple, consistent scoring framework that your entire team can apply without requiring risk management expertise.

Likelihood Scale

Score	Level	Definition
1	Rare	Could occur in exceptional circumstances; no history of occurrence
2	Unlikely	Could occur but not expected; has occurred elsewhere in the industry
3	Possible	Could occur; has occurred once in the organization or regularly in the industry
4	Likely	Will probably occur; has occurred multiple times in the organization
5	Almost Certain	Expected to occur; occurs regularly or is currently occurring

Impact Scale

Score	Level	Definition
1	Negligible	Minimal disruption; no data loss; no regulatory impact; negligible financial loss
2	Minor	Short-term disruption (hours); limited data exposure; minor financial loss
3	Moderate	Significant disruption (days); data exposure affecting multiple individuals; moderate financial loss; potential regulatory inquiry
4	Major	Extended disruption (weeks); significant data breach; major financial loss; regulatory investigation likely
5	Severe	Critical disruption to operations; large-scale data breach; existential financial impact; regulatory enforcement action

Risk Rating Matrix

The risk score is calculated as Likelihood multiplied by Impact, producing a value between 1 and 25. What we recommend is classifying risks into four levels:

Risk Level	Score Range	Response
Low	1-4	Accept or monitor; document rationale
Medium	5-9	Treatment plan required; implement within standard planning cycle
High	10-15	Treatment plan required; prioritize for near-term implementation
Critical	16-25	Immediate treatment required; escalate to senior management

In our experience, first-time risk assessments for technology companies typically produce 5 to 10 high or critical risks, 20 to 30 medium risks, and the remainder at low. If your distribution looks dramatically different, it may indicate that your scoring criteria need calibration.

Risk Treatment Options

For every risk that exceeds your acceptance threshold, you must select a treatment option and document your rationale. ISO 27001 recognizes four treatment options:

Mitigate (Reduce)

This is the most common treatment. You implement controls that reduce the likelihood or impact of the risk. For example, implementing multi-factor authentication mitigates the risk of unauthorized access through credential compromise. What we tell clients is that each mitigation control should map to one or more Annex A controls, which is how your risk register drives your Statement of Applicability.

Transfer

You shift some or all of the risk to a third party, typically through insurance or outsourcing. Cyber insurance is a common risk transfer mechanism, as is using a managed security service provider. In our experience, transfer is appropriate for residual risk that remains after mitigation, but auditors expect to see that you are not using transfer as a substitute for implementing basic controls.

Avoid

You eliminate the risk entirely by stopping the activity that creates it. For example, deciding not to store credit card numbers eliminates PCI-related data breach risks. Avoidance is the most effective treatment but often the least practical for risks associated with core business activities.

Accept

You acknowledge the risk and decide not to treat it further. Acceptance is valid only when the risk falls within your defined risk appetite and the acceptance is formally documented and approved by a risk owner with appropriate authority. What we recommend is requiring management-level sign-off for any risk acceptance above your low-risk threshold.

Risk Ownership

Every risk in your register needs a designated owner. The risk owner is the person accountable for monitoring the risk and ensuring that treatment plans are executed. In our experience, effective risk ownership follows these principles:

• Owners should be at the management level. They need the authority to allocate resources for treatment and the accountability to be answerable during management reviews.
• Owners should be aligned with the risk. The VP of Engineering owns infrastructure-related risks. The Head of HR owns personnel security risks. The CISO or equivalent owns overarching information security risks.
• Ownership is not delegation. The risk owner may assign treatment tasks to others, but they remain accountable for monitoring and reporting.

What we tell clients is that auditors frequently interview risk owners during the certification audit. If the named owner cannot explain the risk, its current status, and the treatment plan, it signals that the risk register is a paper exercise rather than an active management tool.

Building the Risk Register

Your risk register is the central document that captures everything described above. Here is the structure we recommend:

Field	Description
Risk ID	Unique identifier (e.g., RISK-001)
Risk description	Clear statement of the risk scenario (asset + threat + vulnerability + impact)
Risk category	Grouping for reporting (e.g., access control, infrastructure, personnel, supplier)
Asset(s) affected	Information assets associated with the risk
Likelihood	Score from 1-5 using defined criteria
Impact	Score from 1-5 using defined criteria
Inherent risk score	Likelihood x Impact before any controls
Existing controls	Controls already in place that affect this risk
Residual likelihood	Likelihood score after existing controls
Residual impact	Impact score after existing controls
Residual risk score	Residual likelihood x Residual impact
Treatment option	Mitigate, transfer, avoid, or accept
Treatment plan	Specific actions to be taken
Annex A control mapping	Relevant Annex A controls
Risk owner	Named individual accountable
Target completion date	When treatment should be completed
Status	Open, in progress, treated, accepted

In our experience, the most effective risk registers are maintained in a dedicated GRC tool rather than spreadsheets. GRC platforms like Vanta, Drata, or dedicated risk management tools provide versioning, workflow automation, and audit trail capabilities that spreadsheets lack. That said, a well-maintained spreadsheet is perfectly acceptable for certification — what matters is the content and the process, not the tool.

The Link to the Statement of Applicability

The Statement of Applicability (SoA) is one of the most important documents in your ISMS, and it is driven directly by your risk register. The SoA lists every Annex A control and states whether it is applicable or not applicable, with justification for each decision.

What we tell clients is that the connection works in both directions:

• Risk register to SoA: When you select "mitigate" as a treatment and map the mitigation to Annex A controls, those controls become applicable in your SoA. The risk register provides the justification for why each control is needed.
• SoA to risk register: If an Annex A control is marked as applicable, there should be at least one risk in your register that the control addresses. Controls without a risk-based justification raise auditor questions about whether your risk assessment was thorough.

In our experience, the most common audit finding related to the SoA is a disconnect between the risk register and control applicability decisions. If your register identifies a risk related to unauthorized access but your SoA marks access control logging as not applicable, the auditor will flag the inconsistency.

Maintaining the Register Over Time

An ISO 27001 risk register is not a one-time deliverable. The standard requires ongoing risk assessment as part of your ISMS maintenance, and auditors verify this during surveillance audits.

Scheduled Reviews

What we recommend is a formal, comprehensive review of the entire risk register at least annually. This review should reassess likelihood and impact scores based on current conditions, evaluate the effectiveness of implemented treatment controls, identify new risks that have emerged since the last review, close risks that are no longer relevant, and update risk ownership where organizational changes have occurred.

Triggered Reviews

In addition to scheduled reviews, certain events should trigger a risk reassessment. These include significant security incidents, major changes to infrastructure or applications, new regulatory requirements, organizational changes (acquisitions, restructuring, significant headcount changes), and findings from internal audits or penetration tests.

Management Review Input

Your risk register should be a standing agenda item in management review meetings (required by Clause 9.3). Management should review the current risk profile, approve any risk acceptance decisions, allocate resources for treatment plans, and evaluate whether the risk assessment methodology remains appropriate.

In our experience, organizations that present risk register updates at quarterly management reviews maintain much higher quality registers than those that only review risks annually. The quarterly cadence keeps risks visible to leadership and ensures treatment plans stay on track.

Common Mistakes We See

After guiding hundreds of organizations through ISO 27001 certification, these are the risk register mistakes we encounter most frequently:

Risks that are too vague. "Data breach" is not a risk — it is a category. A proper risk entry specifies the asset, threat, vulnerability, and potential impact. "Unauthorized access to the customer database through compromised employee credentials due to lack of MFA, resulting in exposure of customer PII" is a risk that drives specific control decisions.

Scoring without calibration. Teams rate every risk as high-likelihood, high-impact because they want to demonstrate thoroughness. In our experience, this actually undermines credibility. Auditors expect to see a realistic distribution of risk scores. If everything is critical, nothing is prioritized.

Treatment plans without deadlines. Identifying a treatment is meaningless without a target date and an accountable owner. Auditors check whether treatment plans are progressing, and "ongoing" is not an acceptable timeline.

Static registers. The register is built during certification preparation and never updated. Surveillance auditors specifically look for evidence of ongoing risk management activity — new risks added, scores updated, treatments completed.

Missing residual risk assessment. Organizations assess inherent risk but do not reassess after controls are implemented. The residual risk score is what determines whether your treatment was effective and whether the remaining risk is within your acceptance criteria.

Key Takeaways

• The risk register is the foundation of your entire ISMS — it determines which Annex A controls are applicable, how you allocate security resources, and what goes into your Statement of Applicability.
• What we recommend is an asset-based identification approach that produces specific, actionable risk scenarios rather than generic threat categories.
• In our experience, a 5x5 likelihood-impact matrix with clearly defined scoring criteria provides the right balance of granularity and simplicity for most organizations.
• Every risk above your acceptance threshold needs a treatment option (mitigate, transfer, avoid, or accept), a named owner, and a target completion date — no exceptions.
• The risk register must be a living document with scheduled annual reviews, triggered reassessments after significant events, and quarterly visibility at the management review level.
• What we tell clients is that the quality of your risk register is the single best predictor of certification audit outcomes — invest the time upfront and maintain it consistently.