Audit Ready ISO 27001 Risk Register for ISMS Teams, One Downloadable Template

An ISO 27001 risk register is the working document that records each identified risk scenario, its likelihood and impact, the owner, the treatment decision, and the residual risk left after controls are applied, tied directly to Clause 6.1.3 and the Statement of Applicability. If you have not started one, the fastest path forward is to open a template with those fields already built in and begin populating your asset inventory today.

TL;DR:

• A risk register is essential for audit proof, linking each risk scenario, control decision, and justification in a traceable, structured format.
• Building a clean asset inventory with clear classifications and ownership is a prerequisite for credible risk scenarios and consistent scoring.
• Effective risk scenarios identify specific assets, threats, vulnerabilities, and impacts using source data from logs, CVEs, and incident history, avoiding guesswork.
• A well-designed register schema should include unique risk IDs, treatment actions with owners and deadlines, residual risk, and links to technical evidence.
• Regular review, ownership assignment, and maintaining version history are critical to keeping the register accurate, actionable, and audit-ready over time.

Table of Contents

• Why the risk register matters for audit readiness
• Building an asset register before you can assess anything
• Writing risk scenarios that hold up to scrutiny
• Choosing your register schema: columns, tools, and version control
• Scoring, prioritizing, and mapping treatment to the SOA
• A worked example and template you can start with today
• Keeping the register alive: cadence, ownership, and reporting
• Aligning your register to NIST’s enterprise risk reporting model
• What auditors actually flag when they sample a register
• ISMS Calculator: validating your register’s effort and timeline assumptions
• Primary sources and templates
• Sources
• FAQ

Why the risk register matters for audit readiness

Auditors do not take your word that risk assessment happened. They ask to see it, row by row, and trace a line from an identified risk to a control decision to a documented justification in the Statement of Applicability. The register is that evidence trail. Without it, Clause 6.1.3 of ISO/IEC 27001:2022 has nothing to point to, and the SOA becomes a list of assertions instead of a defensible set of decisions.

The register also does real work beyond audit theater. It is the mechanism that turns a risk assessment into control selection. When a risk scenario scores above your appetite threshold, the register should show which control was chosen, why, and what risk remains afterward. That chain of reasoning is exactly what ISO/IEC 27001 guidance expects when it says necessary controls must be identified before anyone checks Annex A for a match.

A common mistake is cramming every technical detail into the register itself: raw log excerpts, vulnerability scan output, ticket histories. That produces a document nobody can read in a management review. The better pattern, borrowed from enterprise risk practice, separates the register into concise summary rows and a linked detail record for each one:

• The register row states the scenario, score, owner, and decision in language an executive can scan in seconds.
• A linked Risk Detail Record holds the evidence: scan results, log timestamps, remediation tickets, and test outcomes.
• Auditors sample the register, then pull the linked detail record for any row they want to verify.
• Management reviews stay short because nobody has to scroll past technical noise to find the decision.

This split keeps the register usable for its two audiences at once: the people who need to act on a risk and the people who need to prove it was managed.

Building an asset register before you can assess anything

You cannot write a credible risk scenario without knowing what asset is exposed. This is where most first-time ISMS builders stall: they try to write risk rows before they have a clean asset inventory, and the register ends up full of vague entries like “the network” or “customer data” with no owner and no boundary.

Start by defining classification and criticality before you enumerate a single asset. Decide, in writing, what makes an asset “high,” “medium,” or “low” criticality for your organization. Typical criteria include whether the asset holds regulated personal data, whether its loss would stop a revenue-generating process, and how long the business could tolerate its unavailability. Fixing these definitions first means every asset gets scored the same way, regardless of who enters it.

Once criteria exist, work through a repeatable sequence:

1. Pull existing inventories first: CMDB exports, cloud account resource lists, and asset tags from endpoint management tools give you a fast baseline.
2. Interview process owners in finance, HR, and operations to catch shadow IT and manual processes that never show up in a CMDB.
3. Assign each asset an owner who is accountable for its risk decisions, not just a custodian who happens to administer it.
4. Tag confidentiality level, physical or logical location, and the business process each asset supports.
5. Reconcile duplicates and retire entries for decommissioned systems before they pollute your risk scenarios.

Practical asset categories usually cover information assets (databases, document repositories), software, hardware and infrastructure, people and roles with privileged access, physical locations, and third-party services. For each one, capture enough metadata to write a risk scenario later: owner, location, confidentiality rating, and the business process it maps to. Skipping any of these fields is the single biggest reason risk rows end up too vague to score consistently.

Pro Tip: Run your asset discovery and your risk workshop in the same week. Assets discovered in isolation tend to sit unused for months because nobody connects them to a live risk conversation.

Data cleanliness pitfalls are predictable. Teams double-count the same asset under two names, forget to assign an owner and leave the field blank, or import a CMDB dump without filtering out test and staging environments that carry no real business impact. Clean these before you start scoring, because every downstream risk row inherits the asset data’s quality.

Writing risk scenarios that hold up to scrutiny

A risk register row is only as useful as the sentence describing the risk. “Ransomware risk” tells an auditor nothing. A structured scenario does the work: name the asset, the threat agent, the vulnerability it exploits, and the specific business impact, stated in terms of confidentiality, integrity, or availability.

A workable template looks like this: [asset] is exposed to [threat agent] exploiting [vulnerability], resulting in [loss of confidentiality/integrity/availability] and [business consequence]. For example: the customer billing database is exposed to an external attacker exploiting an unpatched database server, resulting in loss of confidentiality of payment records and regulatory notification obligations. That sentence gives you everything needed to assign likelihood, impact, and eventually a treatment owner.

Credible scenarios need credible sources, not guesses pulled from a workshop whiteboard. Draw threat and vulnerability data from:

• Internal logs and SIEM alerts that show what has actually been attempted against your environment.
• Vendor and supplier security notices, particularly for third-party software with known CVE timelines.
• Published CVE databases mapped against your own asset inventory to flag unpatched exposure.
• Incident history from your own organization or sector, when available, rather than generic industry claims.

Our risk assessment methodology guide walks through this scenario-building process in more depth if you want a longer worked sequence.

Assigning likelihood and impact is where asset criticality earns its keep. A vulnerability on a low-criticality test server and the identical vulnerability on a production payment gateway should never land at the same risk score, even though the technical flaw is the same. Impact should be scored against the asset’s criticality rating you already defined, not against a generic severity scale borrowed from a vulnerability scanner. Likelihood should reflect what you know about exposure: is the asset internet-facing, does it sit behind network segmentation, has this exact vulnerability class been exploited against you before. Vague likelihood ratings (“medium, probably”) are the single most common weakness auditors flag when they sample a register.

Choosing your register schema: columns, tools, and version control

The columns you choose to determine whether the register is usable six months from now or whether it collapses into an unmaintainable spreadsheet. A recommended schema, built around what auditors actually expect to see, includes:

• Risk ID: a stable, unique identifier that never gets reused, so historical references and RDR links stay valid.
• Risk description: the structured scenario sentence, not a one-word label.
• Asset reference: a link back to the asset register entry, avoiding duplicated asset data.
• CIA impact: which of confidentiality, integrity, or availability is affected, and how.
• Likelihood and impact ratings: scored against your defined criteria, not a floating gut feel.
• Risk score: the calculated output of likelihood times impact, or your chosen weighting.
• Existing controls and control efficacy: what is already in place and how well it is working.
• Treatment action, owner, and target date: the decision, who is accountable, and when it is due.
• Residual risk: the score remaining after treatment, which is what leadership actually needs to see.
• Link to Risk Detail Record: where the technical evidence lives.
• Last review date: proof the row is being maintained, not just created once and forgotten.

A spreadsheet is genuinely sufficient for smaller organizations with a modest asset count and a single ISMS owner keeping the file current. It is fast to build, easy for auditors to sample, and cheap to maintain. It stops being sufficient once you have multiple business units contributing risks, need workflow automation for treatment deadlines, or require role-based access control so that not everyone can edit every row. At that point a GRC platform earns its cost, mainly through automated reminders, audit trails, and the ability to aggregate risks across departments without manual consolidation.

Pro Tip: If you migrate from a spreadsheet to a GRC tool later, keep your risk ID format stable from day one. Renumbering rows during migration breaks every historical audit reference and RDR link you built.

Whichever format you choose, version control is not optional. Lock down who can edit the master register, log every change with a timestamp and editor name, and keep prior versions retrievable rather than overwritten. Auditors frequently ask to see how a specific risk score changed over time, and a spreadsheet with no change history cannot answer that question.

Scoring, prioritizing, and mapping treatment to the SOA

Three scoring approaches cover most organizations. A simple three-level qualitative model (low, medium, high) works for small ISMS programs where speed matters more than granularity. A 5×5 numeric matrix, multiplying likelihood by impact on a scale of one to five, gives you finer prioritization and is the model most auditors are used to seeing. A hybrid model, adding a weighting factor for regulatory exposure or reputational impact on top of the 5×5 base score, suits organizations with complex compliance obligations layered on top of standard information security risk. Our risk matrix template walks through building the 5×5 version with worked scoring examples.

The rule of thumb: start with the 5×5 model unless your organization is small enough that a three-level scale gets the same decisions made faster. Do not build a hybrid weighted model until the simpler version has proven too coarse in practice.

Risk appetite thresholds turn scores into action. Define, in advance, the score above which a risk must be escalated to leadership rather than closed at the operational level. A common pattern sets a numeric ceiling on risk scores that triggers automatic escalation to a risk committee or executive sponsor, regardless of who identified it. Without a written threshold, escalation becomes a judgment call that varies by who is in the room.

Once a treatment decision is made, mapping to Annex A is the final step, and it is where checklist thinking causes the most damage. ISO/IEC 27001 requires that you identify necessary controls from the risk assessment first, then check Annex A for a match, documenting justification for anything excluded in the Statement of Applicability. Practice notes from ISO’s own committee resources stress that Annex A is a reference set, not an exhaustive checklist, and that necessary controls may come from other standards entirely. Our Annex A controls guide covers how to avoid treating the annex as a box-ticking exercise. For deeper guidance on documenting the treatment decision itself, ownership, and deadlines, see our risk treatment guide.

A worked example and template you can start with today

Abstract schema advice only goes so far. Here is one full row, built out from identification to residual risk, for a mid-sized software company.

The scenario: the customer support ticketing platform, hosted by a third-party SaaS vendor, is exposed to a credential-stuffing attack exploiting weak password policies on support agent accounts, resulting in loss of confidentiality of customer support tickets containing personal data. The asset was flagged during stakeholder interviews because support agents have broad read access across all customer records. Likelihood was rated high given no multi-factor authentication was enforced at the time of review; impact was rated high because the asset holds regulated personal data. The treatment decision was to enforce multi-factor authentication for all agent accounts within 30 days, owned by the IT security lead. After treatment, residual risk dropped to low, because credential-stuffing attacks are substantially harder to execute against accounts protected by a second factor.

For readers building from scratch, a starter spreadsheet template with these columns pre-built is the fastest way to begin, and an auditor-ready version adds the RDR link column and version history tab. Teams planning to feed a GRC platform later should keep column headers aligned to the schema above, since matching field names is what makes a later import painless rather than a manual remapping exercise. Small teams can run the entire register in one sheet; larger organizations aggregating across business units will eventually want each unit’s register rolling up into an enterprise-level summary, which the NIST alignment section below covers in more detail.

Keeping the register alive: cadence, ownership, and reporting

A register built once and never revisited is worse than no register at all, because it gives false assurance. Review cadence should combine a scheduled check, typically quarterly for most organizations, with change-triggered reviews whenever a new system goes live, a major vendor changes, or an incident reveals a gap the register missed.

1. Assign every risk row a named owner who is accountable for keeping it current, not a department or team name.
2. Link each register row to its Risk Detail Record, and to any open tickets or remediation tasks tracking the treatment.
3. Keep the executive-facing view to a short snapshot: risks above appetite threshold, their owners, and target dates, rather than the full technical register.
4. Track a small set of KPIs: average time-to-treatment for high-scoring risks, the percentage of high risks with a named owner and active deadline, and the trend in residual risk scores over successive quarters.
5. Re-score any risk whose underlying control changes, rather than waiting for the next scheduled review cycle.

These KPIs matter because a register with dozens of open high risks and no movement over three quarters tells a very different story to an auditor than one showing steady residual-risk decline. The trend line is often more persuasive than any single row.

Aligning your register to NIST’s enterprise risk reporting model

ISO 27001 does not mandate a specific register format, which is exactly why aligning to an established schema pays off. NIST’s December 2025 revision of its cybersecurity and enterprise risk management publications recommends that cybersecurity risk registers capture, at minimum, the risk scenario, threat and vulnerability mapping, likelihood, impact, treatment decision, risk owner, and residual risk, which maps almost field for field onto the schema recommended earlier in this piece.

The NIST model’s real contribution is the split between the Cybersecurity Risk Register (CSRR) and the Risk Detail Record (RDR). NIST IR 8286A provides a notional CSRR template alongside an RDR schema, explicitly designed to keep the CSRR succinct for management review while preserving the technical depth auditors need in a linked record. NIST IR 8286B extends this with JSON schema examples for machine-readable risk reporting, which matters once you are aggregating risk data across multiple business units or feeding a GRC platform.

Three practical benefits follow from adopting this structure:

• A concise CSRR is what executives and auditors actually read, while the RDR preserves evidence without cluttering the summary view.
• Standardized field names that map to NIST’s schemas make later migration into an enterprise aggregation pipeline far less painful.
• Assigning one canonical risk ID per scenario, never duplicated across business units, is what makes enterprise-level rollup possible without manual reconciliation.

You do not need to adopt the full NIST JSON schema to benefit from this thinking. Even a spreadsheet that separates summary rows from a linked detail tab captures most of the value.

What auditors actually flag when they sample a register

Three failings show up again and again when a register gets sampled during an audit. The first is vague risk descriptions, entries like “cyber risk to IT systems” that give an auditor nothing to trace back to a specific asset or control decision. The second is missing or stale owners, rows assigned to a role that no longer exists or a person who left the company eight months ago. The third is treatment actions with no target date, which reads as a risk everyone agrees exists but nobody has committed to fixing.

The fix for all three is the same discipline: write scenarios in full sentences, review ownership every quarter regardless of whether anything else changed, and never let a treatment action sit in the register without a date attached. A register that both a security engineer and a chief financial officer can read without translation is doing its job. Keep the technical detail in the linked record, and the summary row in language a non-technical executive can act on in one read.

The auditors I have seen move fastest through a register are the ones where every row links directly to evidence: a ticket, a scan result, a signed-off exception. That single habit saves more audit time than any formatting choice.

— Martin

ISMS Calculator: validating your register’s effort and timeline assumptions

Building the register answers what needs treatment. It does not tell you how much that treatment will cost or how long an ISO 27001 program realistically takes to run, which is the gap ISMS Calculator fills. The free 2-minute check gives an instant readiness read before you commit to a full assessment, and the ISO 27001 Cost Calculator produces a real-time, organization-specific estimate based on your company size, industry, and current security maturity, with editable assumptions you can adjust as your register fills in.

If your register already lists a dozen high-priority treatment actions with target dates, the calculator helps sanity-check those timelines against model reference comparisons rather than guessing at effort in isolation. It also produces a maturity assessment across the four Annex A control themes, letting you see where your register’s coverage is thin before an auditor does, and exports the results as a shareable PDF report for management review. For a deeper diagnostic once your register is in shape, the ISO 27001 Readiness Assessment goes further than the initial check. Start with the free check and see where your current effort estimate lands.

Primary sources and templates

The NIST IR 8286 series, including IR 8286A and IR 8286B, publishes the CSRR and RDR schemas referenced throughout this guide, alongside NIST’s December 2025 notice on integrating cybersecurity and enterprise risk management. The official ISO/IEC 27001:2022 standard page covers the Clause 6.1.3 and Annex A requirements this article builds from. Organizations connecting register rows to incident response evidence can also review Netverge’s incident response guide for practical RDR linkage examples.

Sources

• NIST revises publications integrating cybersecurity and enterprise risk
• Prioritizing Cybersecurity Risk for Enterprise Risk Management (NIST IR 8286B update)
• IR 8286A: Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management (NIST)
• ISO/IEC 27001:2022 - Information security management systems

FAQ

Is it a legal requirement to have a risk register?

ISO/IEC 27001 does not use the term “legal requirement” for a risk register, but Clause 6.1.3 requires a documented risk assessment and treatment process, and a register is the standard way organizations produce that evidence. Without one, certification against ISO 27001 is not achievable, since auditors need a traceable record linking risks to control decisions.

How do you conduct an ISO 27001 risk assessment?

An ISO 27001 risk assessment starts with a populated asset inventory, then identifies threats and vulnerabilities against each asset to build structured risk scenarios, and scores each one for likelihood and impact against defined criteria. Our risk assessment methodology guide covers the full sequence from asset classification through treatment decision in more depth.

Is there a free ISO 27001 checklist available?

Free checklists and starter templates for ISO 27001 risk registers are widely available, though quality varies significantly in whether they include the fields auditors actually expect, such as owner, target date, and residual risk. ISMS Calculator offers a free 2-minute readiness check that gives an instant gap read without requiring signup.

How do you build a risk register from scratch?

Start with a clean asset inventory that includes owner, classification, and business process mapping for each entry, since risk scenarios cannot be written without it. From there, write structured risk scenarios naming the asset, threat, vulnerability, and business impact, score each for likelihood and impact, and assign a treatment owner and target date to every row scoring above your defined risk appetite threshold.

What is the difference between a CSRR and a Risk Detail Record?

A Cybersecurity Risk Register (CSRR) holds concise summary rows meant for management and audit review, while a Risk Detail Record (RDR) holds the underlying technical evidence, such as scan results and remediation tickets, linked to each CSRR row. This split, described in NIST IR 8286A, keeps the register readable while preserving audit-grade detail elsewhere.

Recommended

• ISO 27001 Risk Matrix: 5×5 Template for Audit-Ready InfoSec
• ISO 27001 Risk Treatment: An Auditor-Ready Guide
• Audit-Ready ISMS Documentation Guide for ISO 27001