How to Build an ISO 27001 Risk Register

Priya Nandakumar found out her risk register was dead on a Tuesday morning, twenty minutes before her Stage 2 audit resumed.

Priya was the compliance lead at Ferrowatt Systems, a 210-person industrial IoT company that made pressure sensors for oil and gas pipelines. Ferrowatt's ISMS scope covered the product engineering division and the customer telemetry cloud platform — the part of the business that mattered most to their Fortune 500 buyers, three of whom had made ISO 27001 certification a hard contract renewal condition worth a combined $4.1 million in annual recurring revenue. The certification body's lead auditor, a meticulous former Big Four risk consultant named Grace Obioma, had spent Stage 1 approving Ferrowatt's policies, scope statement, and Statement of Applicability without much friction. Stage 2 was supposed to be a formality.

Then Grace opened the risk register.

It was a single Excel tab, 47 rows long, last "reviewed" — according to a note in cell A1 — fourteen months earlier. Half the risk owner cells said "IT," which was not a person, not a role, and not anyone Grace could interview. Nine rows had identical risk scores frozen from the original 2023 assessment, including one describing a legacy FTP server that Ferrowatt had decommissioned eight months prior. Two risks tied directly to controls the Statement of Applicability marked as implemented — cryptographic key management and supplier due diligence — had no corresponding treatment action, no linked control reference, and no residual risk figure at all. When Grace asked who owned the register itself, Priya said "me," and when Grace asked when it was last used to make a decision, Priya didn't have an answer.

Grace didn't fail Ferrowatt outright, but she raised a major nonconformity: the risk register did not reflect current risks, was not being maintained as an operating tool, and could not demonstrate the ongoing risk assessment process required by Clause 6.1.2. Ferrowatt had ninety days to close it, a follow-up visit fee of $6,800, and a very uncomfortable board conversation about why a document nobody looked at had become the single biggest threat to a renewal worth over $4 million.

The lesson embedded in that story is one I've watched play out, in one variation or another, across a couple dozen of the 200-plus organizations I've supported through ISO 27001 over fifteen years: the risk register is not a compliance artifact you build once and file away. It's the operating record of how your organization thinks about risk, and if it isn't alive, your ISMS isn't either. This article is the fix — a field-by-field, example-driven, audit-tested method for building a register that works as a management tool first and an audit exhibit second, because a register that only exists for auditors always ends up looking exactly like Ferrowatt's did.

Who This Is For and What You'll Walk Away With

This is written for the person who owns — or is about to own — the risk register: an ISMS manager, a CISO wearing too many hats, a consultant standing up a client's first ISMS, or an internal auditor trying to figure out why the existing register keeps failing review. I'm assuming you already understand the basic shape of risk assessment; if you need the methodology itself, that's covered in the companion piece on ISO 27001 risk assessment methodology. This article picks up exactly where that one leaves off: you know how to identify and score a risk, and now you need somewhere durable, defensible, and usable to put it.

By the end, you'll have a concrete column-by-column register structure with definitions for every field, a fully worked example register across eight realistic risk scenarios spanning confidentiality, integrity, and availability, a side-by-side comparison of spreadsheet versus GRC-platform tooling, a governance model for who owns what, and a review cadence that keeps the register current between audits instead of the week before them.

What a Risk Register Is — and What It Isn't

A risk register is the documented output of your Clause 6.1.2 risk assessment process, maintained over time to reflect the current state of identified information security risks, how they're being treated under Clause 6.1.3, and what risk remains after treatment. ISO/IEC 27001:2022 does not mandate a specific template, a specific number of columns, or a specific software tool — auditors are not going to hand you a blank form and dock you for using a different layout. What the standard does require is that you can produce documented information showing the risk assessment process and its results, and that this documented information is available and suitable for use, which in practice means current, not a museum piece from your certification year.

It's worth being precise about what the register is not. It is not your risk assessment methodology — that's a separate, higher-level document describing your criteria, scales, and process, which you'll reference but not restate in every row. It is not your risk treatment plan — that's the action-tracking document that answers "what are we doing and by when," which pulls its risk IDs directly from the register but carries its own project-management detail. It is not your Statement of Applicability — the SoA answers "which of the 93 Annex A controls apply and why," while the register answers "which risks exist and what's their status." The three documents interlock tightly, and later in this article we'll map exactly how, but conflating them into one bloated spreadsheet is one of the most common ways registers become unmanageable.

Practically, the register is a living inventory. Every risk you've identified gets a permanent row and a permanent identity (its Risk ID), and that row's content changes over its lifecycle: you add controls, you re-score likelihood and impact as circumstances change, you re-open a risk that resurfaces, you close one that's genuinely gone. A register with rows that never change after the initial assessment is exactly what Grace found at Ferrowatt — evidence that nobody is using it to manage anything.

"I ask for the risk register in the first ten minutes of Stage 2, and honestly it tells me more about an ISMS's maturity than the policy binder does. A policy can be copied. A register that's been touched forty times in a year can't be faked." — Grace Obioma, Lead Auditor, Meridian Certification Body (illustrative)

The Field-by-Field Anatomy of a Risk Register

Every column in a well-built register earns its place by answering a question an auditor, a risk owner, or a future version of you will eventually ask. Skip a column and that question has nowhere to be answered except from memory — which is exactly how registers like Ferrowatt's happen. The table below is the structure I've converged on after building or reviewing this document for dozens of clients; you can add columns for your context, but I'd think hard before removing any of these.

Table 1: Risk Register Field Definitions

Twenty-one columns sounds like a lot until you group them mentally into five clusters: identity (1–3), analysis (4–10), ownership and treatment (11–14), residual outcome (15–19), and lifecycle tracking (20–21). Most spreadsheet builds freeze the first three columns so the identity of the row is always visible while you scroll through the analysis further right — a small usability choice that saves enormous frustration in a 150-row register.

A note on the CIA impact category field: don't skip it because it feels redundant with the scenario description. When an auditor or an executive asks "which of our confidentiality risks are still open," you want a filterable column that answers that instantly, not a search through free-text descriptions.

A Fully Worked Example Register

Abstractions only get you so far. Below is a condensed but realistic slice of a risk register — eight rows, spanning confidentiality, integrity, and availability risks, drawn from a composite of engagements I've run for mid-market SaaS and industrial clients. The full register would carry every column from Table 1; I've compressed it here to the columns that tell the story, with likelihood and impact on a 1–5 scale (1 = rare/negligible, 5 = almost certain/severe) and risk score as their product (1–25, illustrative scale — yours may differ per your methodology).

Table 2: Worked Example Risk Register (Condensed View)

A few things worth pointing out in that table before we move on. First, notice RISK-006 uses "Avoid" as the treatment option — the organization decided the cheapest and most defensible path was decommissioning the legacy server entirely rather than trying to patch an unsupported OS indefinitely. Avoidance is a legitimate Clause 6.1.3 treatment option and shows up more often than people expect once you stop treating "modify" as the only acceptable answer.

Second, RISK-005 uses "Share" — the organization can't eliminate the risk that a payroll processor gets breached, but it can shift and distribute the exposure through contractual security requirements, monitoring rights, and cyber insurance that responds to third-party incidents. Share doesn't mean "not our problem"; it means the risk is being managed jointly with a party better positioned to reduce part of it.

Third, look at the spread between inherent and residual scores. RISK-008's ransomware-on-backups scenario drops from 20 (critical) to 8 (medium) once immutable, air-gapped backup controls and malware protection are layered in — but it doesn't drop to zero, and it shouldn't. A residual score of zero on a serious threat scenario is usually a sign the scoring is wrong, not that the risk is gone.

"The single biggest tell in a register I'm reviewing is a residual score of 1 across the board. Real residual risk has texture — some risks compress a lot, some barely move, and that variation is what tells me someone actually thought about it." — Renata Ferreira, Principal Consultant, Solventis GRC Advisory (illustrative)

Inherent vs Residual: Why the Register Needs Both Columns, Always

I still occasionally meet teams who track only one risk score per row, updated in place as controls are added, with no history of what the number used to be. That approach destroys exactly the information an ISMS is supposed to demonstrate: that you evaluated a risk honestly before treatment, chose treatment deliberately, and can show the delta. Keep inherent and residual as permanently separate columns, never overwritten.

Inherent risk is the risk level with existing controls factored in as they stood at the time of assessment, but before any new or planned treatment from this assessment cycle is applied. Some methodologies further distinguish "pure inherent" (zero controls) from "current inherent" (controls as they exist today) — pick one convention in your risk assessment methodology document and apply it consistently across every row; mixing conventions row to row is a fast way to make your scores incomparable.

Residual risk is the risk level expected after the selected treatment (new controls, process changes, or risk-sharing arrangements) is fully implemented — not aspirational, not the day treatment starts, but the day it's actually operating. This distinction matters for the Status column: a risk shouldn't move to "Closed" or show its residual score as final until the treatment action in the linked treatment plan is verified complete, not just scheduled.

Table 3: Likelihood and Impact Rating Scales (Illustrative 1–5 Model)

Table 4: Risk Scoring Heat Map (Likelihood × Impact)

Whatever thresholds you use for Low/Medium/High/Critical banding, document them once in your risk assessment methodology and reference them from the register rather than re-explaining the math in every review meeting. If you're deciding between a purely qualitative approach like this and a quantitative model built on loss magnitude and frequency distributions, that trade-off is exactly what the piece on qualitative vs quantitative risk assessment works through in detail — the register structure above supports either.

Table 5: The Four Treatment Options (Clause 6.1.3)

A register that shows every single risk treated with "Modify" is worth a second look — it usually means someone is reflexively adding controls rather than making a genuine risk-based decision about which of the four options actually fits.

Linking the Register to the Statement of Applicability

The register and the SoA answer different questions but must reconcile perfectly, and this is one of the most heavily scrutinized cross-references in any Stage 2 audit. Your Statement of Applicability declares, for all 93 Annex A controls, whether each is applicable and why — and every control marked applicable needs a justification trail that an auditor can follow backward into the risk register.

The mechanism is the Selected Controls column (field 13 in Table 1). Every Annex A reference you cite there should appear as "applicable" in the SoA, and ideally the SoA's justification text references the specific risk(s) driving that control's inclusion. Walk it the other direction too: every control the SoA marks applicable should trace forward to at least one risk in the register that it's treating, or a legal/contractual/regulatory driver documented in the SoA's justification instead. A control sitting in the SoA with no risk link and no external driver is a red flag — it suggests the control was copied from a template rather than selected deliberately.

Table 6: Register-to-SoA Cross-Reference Example

Keep this reconciliation as a periodic exercise, not a one-time mapping exercise you do right before certification and never touch again. Every time a new risk enters the register with a control the SoA doesn't yet list as applicable, that's a same-day SoA update, not a backlog item.

Linking the Register to the Risk Treatment Plan

Where the SoA answers "which controls," the risk treatment plan answers "who is implementing them, in what order, by when, and with what budget." The register's Treatment Actions / Plan Reference field (field 14) is the bridge: it points to a specific line in the treatment plan rather than duplicating project-management detail inside the register itself.

This separation matters more than it looks. A risk register with embedded Gantt-chart detail — sub-tasks, percentage complete, budget line items — becomes unreadable fast, and worse, it tempts owners to update the plan detail without updating the risk's actual status. Keep the register lean: it should tell you the risk's current state and where to go for implementation detail, not try to be the implementation tracker itself.

Table 7: Register-to-Treatment-Plan Cross-Reference Example

When a treatment plan item closes, that's the trigger to update the register's residual likelihood, residual impact, and status — not before. I've seen registers where enthusiastic owners pre-emptively marked risks "Closed" the day a project kicked off, and then the project stalled for six months while the register quietly lied about the organization's actual risk posture.

Linking the Register to Clause 9 Performance Evaluation

The register isn't just an input to certification — it's a recurring input to the monitoring, internal audit, and management review activities under Clause 9 performance evaluation. Internal audits should sample register entries against evidence (is the claimed existing control actually operating as described?), management review should receive a summarized view of open critical/high risks and overdue reviews, and both activities should generate register updates in return — new risks identified during audit, revised scores where evidence didn't support the claimed residual level, and closed items where treatment is verified complete.

Treat the register as one of the core Clause 9 data feeds, not a document Clause 9 merely inspects once a year. A register that only changes right before an internal audit is functionally identical to Ferrowatt's dead spreadsheet — it just fails a few weeks later than theirs did.

Tooling: Spreadsheet or GRC Platform?

I get asked constantly whether a spreadsheet is "good enough" for ISO 27001, and the honest answer is: it depends entirely on whether anyone actually uses it, not on the tool itself. I've seen beautifully maintained spreadsheet registers pass audits smoothly for organizations with 40 employees, and I've seen $60,000-a-year GRC platform deployments sit as unused as Ferrowatt's Excel tab because nobody built the operating habit around it.

The spreadsheet case. For smaller organizations — roughly under 100–150 employees, a single ISMS scope, and a handful of risk owners — a well-structured spreadsheet (Excel or Google Sheets) with the 21-field structure from Table 1, data validation dropdowns for Treatment Option and Status, and conditional formatting on the risk score column is genuinely sufficient. It's free or near-free, everyone already knows how to use it, and it's fast to change when your methodology evolves. Its failure mode is entirely social: no version control discipline, no automatic reminders, and no audit trail of who changed what unless you build one manually (a "Change Log" tab, tracked changes, or a version-numbered file naming convention).

The GRC platform case. Once you're managing risk across multiple business units, multiple frameworks (ISO 27001 alongside a SOC 2 program or a NIST CSF-aligned effort), a distributed set of risk owners who need individual dashboards, or you're simply tired of chasing people to update their rows, a dedicated GRC platform earns its cost. These tools automate reminder workflows, maintain a native audit trail of every field change, link risks to controls and evidence automatically, and generate the SoA and treatment plan cross-references we described above without manual reconciliation. The tradeoff is cost, implementation time (typically 4–10 weeks to configure properly), and the very real risk of over-engineering a tool nobody in a 60-person company actually needs.

Table 8: Spreadsheet vs GRC Platform for the Risk Register

Whichever you choose, the discipline matters more than the tool. If you're still deciding between qualitative scoring you can run comfortably in a spreadsheet and a heavier quantitative model, that decision — covered in the qualitative vs quantitative risk assessment piece — will also steer your tooling choice, since quantitative loss-distribution modeling tends to outgrow spreadsheet formulas fast.

"We moved off a spreadsheet at 90 employees not because Excel broke, but because six different risk owners had six different habits, and nobody but me could see the whole picture. The platform didn't make us more secure on day one — it made the register impossible to ignore." — Jonas Whitfield, CISO, Aurelane Health Analytics (illustrative)

Ownership and Governance: Who Actually Owns a Risk

The single most common defect I find in registers isn't a scoring error — it's an ownership vacuum. "IT" is not a risk owner. "The security team" is not a risk owner. A risk owner is a named individual with the authority to make decisions about that risk's treatment and the accountability to answer for its status when asked. If your organizational structure genuinely spans risk decisions across a team, name the person chairing that team, not the team itself.

Risk ownership should map to who has the authority and budget to actually treat the risk, which is often not the person who identified it or the security function that facilitated the assessment. A risk about a legacy application's unpatched vulnerabilities belongs to the engineering leader who owns that application's roadmap, not to the CISO — the CISO's job is to ensure the risk is assessed, escalated, and tracked, not to personally own every line in the register. Reserve central ownership by the ISMS manager or CISO for genuinely cross-cutting, organization-wide risks (like third-party supply chain risk affecting multiple business units) where no single department head is the obvious owner.

Table 9: Risk Register Governance — RACI

Note the split on risk acceptance: for anything above a Medium threshold (or whatever your methodology sets as the escalation line), acceptance shouldn't rest with the risk owner alone — that's how organizations quietly accumulate risk appetite creep, one individually-reasonable acceptance decision at a time. Route high and critical residual risk acceptances to top management, and record the approver's name and date directly in the Risk Acceptance field, not in a separate meeting minute that nobody cross-references.

"The fastest way to spot a governance gap is to ask the named risk owner a direct question about their risk in the audit room. If they look at the CISO before answering, ownership isn't real — it's decorative." — Devon Marsh, Internal Audit Manager, Kestrel Financial Group (illustrative)

Review Cadence and Versioning

A register reviewed only once a year, right before recertification, is a register that fails the Clause 6.1.2 intent even if it technically exists. I recommend a tiered review cadence tied to risk severity rather than a single blanket schedule, because reviewing a Low-scored, accepted risk monthly wastes everyone's time while a Critical risk reviewed only annually is a genuine exposure.

Table 10: Recommended Review Cadence by Risk Level

Layer on top of that cadence a full register review at each internal audit cycle and at management review, plus an event-driven review any time something material changes — a new system goes live, a supplier relationship ends, an incident occurs, or a control is disabled for maintenance and stays disabled longer than planned.

Versioning matters as much as cadence. Maintain a simple version log — even a tab in the same spreadsheet — recording version number, date, editor, and a one-line summary of what changed. This is what turns "we review the register" into evidence an auditor can independently verify, and it's what would have saved Priya at Ferrowatt: fourteen months with zero version log entries was itself the nonconformity, independent of any individual risk score being wrong.

Table 11: Example Version Log Entry Format

Notice that not every version entry represents a scoring change — "reviewed, no change" is itself a valid and important log entry, because it's the evidence that the review actually happened on schedule rather than being skipped.

Scaling the Register: Small Organization vs Large Organization

The 21-field structure in Table 1 works at every scale, but how you operate it should change with headcount, scope complexity, and the number of distinct risk owners involved. A 30-person startup and a 3,000-person multinational both need the same fields; they need very different processes wrapped around them.

Small organizations (roughly under 150 employees, single ISMS scope). Keep it to one spreadsheet, one owner of the register itself (often the ISMS manager, sometimes doubling as CISO), and a lightweight quarterly review meeting with the handful of risk owners in the room together. Don't over-engineer categorization — a flat list of 20–60 risks with good filtering is far more usable than an elaborate taxonomy nobody maintains. Resist the temptation to buy a GRC platform "to look mature" for an auditor; a clean, actively-used spreadsheet impresses auditors more than an expensive tool with three stale entries.

Large organizations (multiple business units, multiple ISMS scopes, hundreds of risk owners). Here a single flat spreadsheet genuinely breaks down — version control conflicts, siloed departmental copies, and irreconcilable duplicate risk entries become the norm. This is where a GRC platform's relational data model, or at minimum a shared database-backed tool (even something as simple as a well-structured SharePoint list or Airtable base with proper permissions), earns its keep. Introduce a risk taxonomy (by business unit, by asset category, by threat type) so the CISO can roll up an organization-wide view without drowning in six hundred rows, and formalize a risk register working group that meets on the tiered cadence from Table 10 rather than relying on informal check-ins.

Table 12: Scaling Considerations by Organization Size

The size of the organization doesn't change what ISO 27001 requires; it changes how much process discipline you need to wrap around the same core artifact to keep it honest at scale.

Common Mistakes That Sink Risk Registers at Audit

After reviewing this document across more organizations than I can count precisely, the failure patterns repeat with remarkable consistency. Here are the ones I flag most often, roughly in order of how often they show up.

Table 13: Common Risk Register Mistakes and Fixes

That last one deserves emphasis: a register built entirely by the security team, with business unit leaders only shown the finished product, tends to produce technically sound but organizationally disconnected risk statements. The best registers I've seen were co-authored — security facilitates the methodology and scoring calibration, but the risk owners themselves write the scenario descriptions and defend the scores.

Case Study: Ferrowatt Systems — From Dead Spreadsheet to Living Register

Returning to Priya and Ferrowatt: closing the major nonconformity within the ninety-day window required more than fixing individual rows. Priya rebuilt the register using the 21-field structure above, reassigned every "IT"-owned risk to named engineering and operations leaders, and — critically — instituted the tiered review cadence from Table 10 with calendar holds that survived beyond her own attention span. She also built the version log Ferrowatt had never had, backdating an honest note that prior history was unavailable rather than fabricating one.

The quantified outcome: Ferrowatt closed the nonconformity in 61 days, passed the follow-up visit with zero findings, and retained the $4.1 million in contract-linked renewals. More importantly for the long run, the subsequent year's surveillance audit — conducted by Grace again — took half the time on the register review because she could see 38 version log entries and a genuinely current risk landscape instead of a static file. Priya's own estimate: the rebuild took roughly 70 hours of her time spread across three weeks, considerably less than the multi-month scramble a failed nonconformity closure would have triggered.

Case Study: Northlake Credit Union — Scaling from Spreadsheet to Platform

Northlake Credit Union, a regional financial services provider with roughly 340 employees across four branches and a growing digital banking arm, had run a spreadsheet register successfully for two certification cycles. By the third cycle, the register had grown to 210 rows across three departments, and the compliance manager, Aaron Petrosyan, was manually reconciling three separate departmental copies before every management review — a process taking nearly two full working days each quarter.

Aaron made the case to leadership for a GRC platform migration, framing it not as a compliance cost but as a 90% reduction in reconciliation labor and a materially lower risk of the exact duplication and staleness problems that produce audit findings. The migration took eight weeks, including a full data cleanse that discovered 14 duplicate risk entries and 6 risks with contradictory scores across the departmental copies. Post-migration, Northlake's internal audit function reported register-related sampling findings dropped from 5 in the prior cycle to 0, and the quarterly reconciliation effort fell from two days to roughly two hours of review, since the platform's relational model eliminated the manual merge work entirely.

Case Study: Verdant Foods — Right-Sizing Instead of Over-Buying

Not every scaling story ends in a platform purchase. Verdant Foods, a 65-person specialty food distributor pursuing ISO 27001 for the first time to satisfy a major grocery retailer's supplier security requirements, was pitched a $40,000-a-year GRC platform by a well-meaning consultant early in the process. The consulting lead I worked alongside on this engagement recommended against it: with a single ISMS scope, four risk owners total, and roughly 35 identified risks, the platform's relational data model and multi-framework support solved a problem Verdant didn't have.

Verdant instead built a disciplined spreadsheet register with the full field structure from Table 1, a shared quarterly review calendar invite that all four owners were contractually expected to attend as part of their role objectives, and a simple version log tab. The certification body auditor had no register-related findings across either the Stage 1 or Stage 2 visit. Verdant's total tooling spend on the register: $0 beyond the Microsoft 365 licenses they already held. The lesson generalizes: match the tool to the actual complexity of your risk landscape, not to what looks impressive in a sales demo.

"The rebuild wasn't really about Excel formulas. It was about admitting nobody owned the thing, and then making sure that could never be true again." — Priya Nandakumar, Compliance Lead, Ferrowatt Systems (illustrative)

The Register Lifecycle, Visualized

The diagram below traces how a single risk moves through the register from first identification to residual risk acceptance and ongoing review — the loop that should be running continuously, not a one-way pipeline that ends at certification.

The loop back from Q to C is the part most registers miss in practice: a risk that's been accepted and closed still needs to re-enter active scoring the moment something material changes — a new vulnerability, an ownership change, an incident elsewhere in the industry. Building that loop into your calendar, not just your diagram, is what separates a living register from a certificate decoration.

If you'd rather not build this structure from a blank sheet, we maintain a ready-to-use ISO 27001 Risk Register Template with all twenty-one fields, data validation, and conditional formatting for the scoring matrix already built in — it's the fastest way to get from zero to a working register in an afternoon rather than a week.

The Strategic Case: A Register That Earns Its Keep

It's tempting to treat the risk register as pure compliance overhead — a document that exists because an auditor wants to see it. I'd push back on that framing hard. Every organization I've worked with that built a genuinely living register discovered the same thing: it became the clearest, most concise picture of where the business was actually exposed, expressed in language executives could act on without a security briefing to translate it. A well-run register turns "we think we have some security gaps" into "here are our four highest residual risks, their owners, their treatment timelines, and what it will cost to close them" — which is a budget conversation, not a compliance conversation.

That reframing is also your best argument for resourcing the register properly, whether that's headcount to maintain it, a GRC platform license, or simply protected calendar time for quarterly reviews. A register that drives real decisions — which vendor gets re-evaluated, which legacy system gets decommissioned, which control gets prioritized in next quarter's roadmap — pays for its own maintenance many times over in avoided incidents and smoother renewals with security-conscious customers, the way Ferrowatt's rebuilt register protected $4.1 million in contract value that a dead spreadsheet nearly cost them.

If you're earlier in the process and still need to establish or refine your scoring approach before the register can hold real data, our Risk Scoring Calculator will run your likelihood and impact inputs through a consistent formula so every risk owner starts from the same math. And if you're not yet confident your existing register (or lack of one) would survive a Stage 2 review, our ISO 27001 Gap Analysis Tool will flag exactly where your risk documentation falls short of what auditors expect, before an auditor tells you the hard way.

Where to Go From Here

Building the register is only half the job — the other half is what you do with what it tells you. Once you've got risks scored, owned, and prioritized, the next step is translating "Modify" decisions into an actual, resourced plan with dates and budget attached. Our Build a Sample Risk Treatment Plan lab walks through that translation hands-on, using a scenario modeled closely on the worked example in this article, so you can practice the register-to-plan handoff before you need it for real.

For a broader view of how the register fits into the full certification journey — from scoping through Stage 2 and beyond — our Complete ISO 27001 Implementation Guide eBook walks the entire path end to end, with the risk register positioned exactly where it belongs: as the operational core the rest of the ISMS reports back to.

Start simple if you're early in the process, start disciplined if you're rebuilding after a finding, and above all, start treating the register as something people actually open between audits — because that single habit is the difference between Ferrowatt's Tuesday morning and the smooth Stage 2 review every compliance lead wants instead.