Priya Nathan had eleven weeks until her Stage 2 audit and a spreadsheet she was quietly proud of. As the newly promoted Head of Information Security at Meridian Health Analytics — a 140-person healthcare data analytics firm processing claims data for six regional hospital networks — she had inherited a risk register with 1,847 rows. Every laptop, every switch port, every SaaS subscription, every printer had its own line. It had taken her predecessor the better part of a year to build, and it looked, at a glance, like exactly the kind of exhaustive diligence an auditor would want to see.
It was also, in the words of the lead auditor from Cascadia Assurance who reviewed it during Stage 1, "an inventory with risk scores bolted on, not a risk assessment." The finding wasn't a single line item — it was structural. Ninety percent of the register consisted of near-identical entries ("Laptop #114 — theft — Medium," "Laptop #115 — theft — Medium," repeated 200 times) while the two risks that actually mattered to Meridian's business — an unencrypted data feed to a third-party analytics vendor, and a single database administrator who held unreviewed god-mode credentials to the claims database — were buried on page 34, scored identically to a stolen laptop, and assigned no owner beyond "IT." The Stage 2 audit was six weeks out. The contract Meridian was chasing, a $340,000 annual deal with a hospital system that required ISO 27001 certification as a prerequisite, had a hard signing deadline that overlapped almost exactly with the recertification window.
Priya had, without realizing it, walked into one of the most common ways ISO 27001 risk assessments go wrong: mistaking volume for rigor. The register was thick. It was not useful. And a thick, unusable risk register is one of the fastest routes to a major nonconformity, because Clause 6.1.2 doesn't just ask you to identify risks — it asks you to produce results that are "consistent, valid, and comparable," results a competent third party can trust to reflect the organization's actual risk exposure. A register that treats a stolen laptop and an unencrypted PHI feed as equivalent fails that test on its face, no matter how many rows it has.
This is the article Priya needed six months earlier. Over fifteen-plus years of ISMS consulting — building, fixing, and defending risk assessments in front of auditors across financial services, healthcare, SaaS, manufacturing, and public-sector clients — I have seen the same fifteen or so mistakes recur with almost boring regularity. They are rarely caused by incompetence. They are caused by predictable pressures: time constraints, a desire to look thorough, a reluctance to assign real accountability, and a genuine uncertainty about what "consistent, valid, and comparable" actually means in practice. This article is a diagnostic. Work through it against your own risk assessment before your certification body does it for you.
Who This Is For
This article is for ISMS managers, CISOs, risk owners, and internal auditors who have a risk assessment in place — built by a consultant, a predecessor, or themselves — and want a structured way to stress-test it before Stage 1, Stage 2, or a surveillance audit exposes the gaps. It assumes you already understand the basic mechanics of ISO 27001 risk assessment (if you don't, start with the step-by-step risk assessment methodology guide first) and are now looking for the failure modes that specifically generate nonconformities. You'll walk away with sixteen named mistakes grouped into five themes, a self-diagnosis checklist you can run against your own register today, a look at exactly how auditors hunt for these problems, and three case studies showing what the fix actually looks like in practice.
Why Risk Assessment Is Where Audits Go to Die
Ask any experienced ISO 27001 lead auditor which clause generates the most major nonconformities, and most will say the same thing: Clause 6.1.2, the risk assessment process, and its close cousin 6.1.3, risk treatment. It's not because risk assessment is technically the hardest requirement in the standard — Annex A has 93 controls and plenty of technical depth. It's because risk assessment is the one place where the standard demands judgment, and judgment is exactly what's hardest to fake, hardest to standardize, and easiest to get subtly wrong in a way that looks fine until someone with twenty years of audit experience starts asking "why is this scored a 6 and not an 8?"
Auditors know this. A competent lead auditor will spend a disproportionate amount of Stage 2 time on the risk register and treatment plan precisely because it's the fastest way to test whether an ISMS is real or theater. A control implementation can be verified against a checklist. A risk assessment can only be verified by tracing logic — asset to threat to vulnerability to likelihood to impact to score to treatment to residual risk to owner sign-off — and logic breaks are where nonconformities live. The mistakes below are, almost without exception, breaks in that chain.
Theme One: Methodology Mistakes
These are the failures baked in before a single risk gets scored — how you defined the process, what you decided to look at, and whether you thought about your actual business before opening a spreadsheet.
Mistake 1: No Documented Methodology at All
Some organizations run a risk assessment workshop, produce a register, and never write down how they got there. There's no document stating the risk identification approach, the likelihood and impact scales, the criteria for what counts as "high," or how residual risk is calculated. The register exists; the method that produced it doesn't.
Element | Detail |
|---|---|
The mistake | A risk register exists, but no risk assessment methodology document defines the scales, criteria, or process used to produce it |
Why it happens | Teams treat the register as the deliverable and the methodology as bureaucratic overhead; consultants sometimes build the register and skip documenting the "recipe" |
The consequence | Clause 6.1.2 explicitly requires the organization to "define and apply" a risk assessment process with documented criteria — auditors ask for this document by name in Stage 1, and its absence is a fast, unambiguous nonconformity |
The fix | Write a standalone Risk Assessment Methodology document covering identification approach, likelihood/impact scales with defined anchors, risk evaluation criteria, and acceptance thresholds — before you score a single risk |
Without this document, every scoring decision downstream is arbitrary by definition, because there's no stated basis to judge it against. This is the single most preventable finding in this entire article: it costs a few hours of writing, and its absence costs a nonconformity almost every time an auditor asks to see it. If you haven't written one, the risk assessment methodology guide walks through every section it needs.
"I've stopped being surprised by how good some registers look and how empty the methodology folder is behind them. The register is the answer key. The methodology is supposed to be the exam question. Auditors want to see both, and most organizations only bring the answer key." — Marcus Oduya, Principal Consultant, Ferrow Risk Partners
Mistake 2: Asset-Register Sprawl With No Business Risk
This was Priya's problem. Thousands of individual asset entries, each scored in isolation, none connected to a business consequence anyone in the executive team would recognize. The register becomes an IT inventory with a risk-colored coat of paint.
Element | Detail |
|---|---|
The mistake | The register lists every individual asset (each laptop, each switch) as its own risk line, producing hundreds or thousands of near-duplicate entries with no aggregation to business-level risk |
Why it happens | Asset-based methodologies taken too literally — someone builds the asset inventory first and treats every row in it as a separate risk to be scored, rather than grouping assets into meaningful risk scenarios |
The consequence | The signal-to-noise ratio collapses; the two or three risks that would actually hurt the business are diluted among hundreds of trivial, near-identical entries, and auditors flag the register as failing to produce results that are "valid and comparable" |
The fix | Group assets by type, location, or business process before scoring ("all end-user laptops — theft/loss," not 200 individual laptop rows); reserve individual entries for assets with genuinely distinct risk profiles (the production database, the single admin account, the uninsured backup site) |
The standard doesn't dictate register size. It dictates that results be usable for decision-making. A 40-row register that clearly separates "unencrypted PHI feed to third-party analytics vendor — critical" from "office laptop fleet — theft/loss — routine" is more defensible than an 1,800-row register where both would be scored identically and neither stands out. If you're deciding between asset-based and scenario-based approaches to avoid this exact trap, the asset-based vs. scenario-based risk assessment comparison is worth reading before you rebuild.
Mistake 3: Confusing Likelihood and Impact
This sounds almost too basic to make a "common mistakes" list, but it is astonishingly frequent in registers built by people without formal risk training. Teams conflate "how bad would this be" with "how likely is this to happen," scoring both against the same intuitive sense of "scariness" rather than as genuinely separate dimensions.
Element | Detail |
|---|---|
The mistake | Likelihood and impact are scored as a single blended "how worried should I be" judgment rather than two independent variables, or the definitions of the two scales overlap so much that scorers can't tell them apart |
Why it happens | Untrained scorers default to a gut-feel "riskiness" number; workshop facilitators don't force the two-question discipline ("how often would this occur" vs. "what happens if it does") |
The consequence | Risk scores become unrepeatable — two different assessors scoring the same risk produce wildly different numbers, which is precisely the "inconsistent" failure Clause 6.1.2 is designed to catch, and it shows up the moment an auditor asks two team members to independently score the same sample risk |
The fix | Force separate, anchored scales for likelihood (frequency-based: "occurred at this organization within 12 months," "occurred in the industry within 3 years," etc.) and impact (consequence-based: financial loss bands, regulatory exposure, service downtime hours) and never let scorers assign a single blended number |
A useful test: if you can't explain in one sentence why a risk is a "3" on likelihood independent of its impact score, your scales aren't doing their job yet.
Mistake 4: Ignoring Business Context and Real Threats
Generic risk catalogs list generic threats — "fire," "flood," "malware," "insider threat" — without ever asking what actually threatens this organization, in this industry, given these customers and this threat landscape. The result is a technically complete but strategically hollow assessment.
Element | Detail |
|---|---|
The mistake | The risk assessment lists generic, textbook threats without grounding them in the organization's actual business model, customer base, regulatory exposure, or current threat intelligence |
Why it happens | Off-the-shelf risk catalogs or templates get adopted wholesale because they're fast, and nobody circles back to ask "does this actually apply to us, and what are we missing?" |
The consequence | The assessment misses the risks that would actually cause the organization damage — the specific vendor integration, the specific regulatory exposure, the specific attacker interest in the specific data held — and auditors interviewing management find that leadership's own stated concerns aren't reflected anywhere in the register, a direct contradiction of Clause 4 context-of-the-organization requirements feeding into Clause 6 |
The fix | Start risk identification from the organization's context statement, interested-party requirements, and current threat intelligence (feeding from control 5.7) rather than a generic list; interview business unit leaders, not just IT, about what keeps them up at night |
Meridian Health Analytics is a useful illustration here: a generic register might list "ransomware" and "phishing" as top risks — true of nearly every organization — while missing that Meridian's specific exposure was a single unencrypted vendor data feed carrying PHI for six hospital systems, a risk unique to its business model that no generic catalog would surface unprompted.
Theme Two: Scoring Mistakes
Even with a sound methodology and a well-scoped register, the scoring process itself is where subjectivity creeps back in. These four mistakes are about how numbers get assigned and what those numbers are actually for.
Mistake 5: Inconsistent or Subjective Scoring
The methodology document exists, the scales are defined — but in practice, different assessors (or the same assessor on different days) score comparable risks differently, with no calibration exercise ever performed to check.
Element | Detail |
|---|---|
The mistake | Risk scores vary depending on who's scoring, with no calibration step to confirm different people apply the criteria the same way |
Why it happens | Scales exist on paper but lack concrete anchors ("what does a 3 actually look like?"), and organizations skip the calibration workshop step where a small group scores sample risks together and reconciles differences |
The consequence | This is the direct, textbook failure of the Clause 6.1.2 requirement that the process produce "consistent, valid, and comparable results" — auditors test this by asking to see evidence of calibration, or simply by asking two team members to independently re-score a sample risk during the audit interview |
The fix | Run a calibration session before or during the annual assessment cycle: have two or three assessors independently score the same five sample risks, compare, and discuss discrepancies until the scale anchors are understood consistently; document this calibration as evidence |
Consistency doesn't require perfect objectivity — some judgment is unavoidable in any risk process. What it requires is that the same input produces roughly the same output regardless of who's doing the scoring, and that you can demonstrate this if asked.
Mistake 6: Scoring Theatre to Justify a Predetermined Answer
This is the most uncomfortable mistake on this list because it's rarely accidental. A risk owner (or their manager) has already decided they want to accept a risk, keep a legacy system, or avoid an expensive control — and the scoring gets reverse-engineered to land just under the treatment threshold.
Element | Detail |
|---|---|
The mistake | Risk scores are quietly adjusted — likelihood nudged down, impact softened — to land the final number just below the threshold that would require treatment, rather than scored honestly against the defined criteria |
Why it happens | Budget pressure, a desire to avoid a difficult project, political reluctance to flag a risk tied to a senior stakeholder's pet system, or simple fatigue with the treatment planning process |
The consequence | Auditors are trained to spot this pattern — a cluster of risks scored suspiciously close to (but just under) the acceptance threshold is one of the most recognized red flags in ISMS auditing, and it often triggers a deeper sampling exercise that surfaces the manipulation, turning a single soft finding into a credibility problem for the whole assessment |
The fix | Score risks against the documented criteria first, independent of what treatment they'd trigger; if the resulting treatment is genuinely too expensive or disruptive, use the risk acceptance process honestly — with proper authority and documented rationale — rather than manipulating the input to avoid the conversation |
"You can always tell when a register has been reverse-engineered. The scores cluster suspiciously at 'medium, but just under high' — never a clean spread. Real risk data is messy. Manufactured risk data is suspiciously tidy." — Renata Alvez, Lead Auditor, Solvane Certification Body
Mistake 7: Missing Risk Criteria or Risk Appetite
Some organizations score risks without ever formally defining what likelihood and impact values actually mean, or what level of residual risk the organization is willing to tolerate. The scoring happens, but there's no documented appetite statement to check it against.
Element | Detail |
|---|---|
The mistake | The organization has no documented risk criteria (what "high," "medium," "low" mean in concrete terms) or risk appetite/acceptance criteria (what residual risk level leadership is actually willing to live with) |
Why it happens | Risk appetite is a leadership-level decision that requires uncomfortable conversations about tolerance for loss, and it's easy for an ISMS team to skip it and just "wing" acceptance decisions case by case |
The consequence | Clause 6.1.2 explicitly requires defined risk acceptance criteria; without them, every acceptance decision looks arbitrary, and auditors will ask "on what basis was this accepted?" with no documented answer available |
The fix | Get top management to formally approve documented risk acceptance criteria — as specific as possible (financial thresholds, regulatory red lines, categories of risk that are never acceptable regardless of score) — before the register goes into use, not retrofitted afterward |
This is closely tied to who actually has authority to invoke those criteria, which is covered in risk acceptance criteria: how to define and document them and in the ownership mistakes below.
Mistake 8: Over-Engineering and Analysis Paralysis
The opposite failure from sprawl-without-substance: some organizations build genuinely sophisticated quantitative models — Monte Carlo simulations, multi-factor weighted scoring, detailed loss-event-frequency calculations — that are so complex the risk team can't actually run the annual cycle without weeks of specialist effort, and business stakeholders can't understand the outputs well enough to make decisions.
Element | Detail |
|---|---|
The mistake | The risk methodology is so elaborate (multi-variable quantitative models, excessive sub-criteria, dozens of scoring factors) that it becomes impractical to run consistently, and the outputs are incomprehensible to the business owners who need to act on them |
Why it happens | A well-intentioned desire for rigor, often introduced by a specialist consultant or a risk-obsessed team member, without weighing the ongoing operational cost of running the model every cycle |
The consequence | The register goes stale because nobody has the bandwidth to maintain it properly; risk owners disengage because they don't understand the numbers they're being asked to sign off on, undermining the "valid" requirement in a different way than sprawl does |
The fix | Match methodology complexity to organizational maturity and resourcing — a well-run qualitative 5x5 matrix that gets updated on schedule beats a sophisticated quantitative model that decays after the first cycle; add quantitative rigor only for the small number of risks where it genuinely changes the treatment decision |
The qualitative vs. quantitative risk assessment comparison is the right reference for calibrating this decision rather than defaulting to "more sophisticated must be better."
Theme Three: Ownership Mistakes
A risk assessment can have flawless methodology and clean scoring and still fail if nobody is genuinely accountable for the risks once identified. This is the theme where I see the most executive-level surprise in audit debriefs — leadership is often unaware how thin ownership actually is until an auditor asks a risk owner a direct question and gets a blank look.
Mistake 9: No Real Risk Owners, or the CISO Owns Everything
The register has an "owner" column. Every row says "CISO" or "IT Manager." No department head, process owner, or business unit lead is named anywhere, because it was faster to assign the whole register to the one person building it.
Element | Detail |
|---|---|
The mistake | A single person — almost always the CISO or ISMS manager — is listed as the owner of every risk in the register, regardless of whether they have the authority or business context to actually manage that risk |
Why it happens | It's the path of least resistance during register creation; getting genuine buy-in and sign-off from department heads takes political effort the ISMS team doesn't have time for during a certification push |
The consequence | Clause 6.1.2 requires risk owners with the authority to manage the risk — auditors routinely interview two or three "owners" directly and ask them to explain their risk, its current treatment status, and their next planned action; when the CISO is nominally the owner of a risk in, say, the finance department's expense system, and the CISO can't answer basic operational questions about it, that's an immediate and credible-looking nonconformity |
The fix | Assign ownership to the person with actual authority and context over the asset or process — the finance director for the expense system risk, the head of engineering for the source-code risk, the facilities manager for the physical access risk — and require each owner to be interview-ready, not just listed |
"The question I ask every risk owner in an audit is the same: 'walk me through your top three risks and what you did about them this quarter.' When the answer is a shrug and a glance at the CISO, I already know what I'm going to write up." — Devon Hartley, ISMS Lead Auditor, Cascadia Assurance
Ownership concentrated in one person isn't just an audit risk — it's an operational one. A CISO who "owns" 200 risks across every business function cannot realistically track, treat, or escalate all of them, which means the risks with genuine business owners get proper attention and the rest quietly stagnate. The risk owners and accountability guide covers how to build a realistic ownership model that survives an interview.
Mistake 10: Risk Acceptance by People Without Authority
Closely related but distinct: even where ownership is properly distributed, the actual acceptance of a risk — the formal decision to tolerate it rather than treat it — gets made by someone without the authority to make that call, often a mid-level manager signing off on a risk that genuinely belongs at the executive or board level.
Element | Detail |
|---|---|
The mistake | A risk with significant business, financial, or regulatory consequence is formally "accepted" by a manager, team lead, or individual contributor who lacks the organizational authority to bind the company to that level of exposure |
Why it happens | Sign-off gets pushed down to whoever is closest to the risk register at the time, especially under deadline pressure, without a defined escalation threshold tied to risk severity |
The consequence | The acceptance decision isn't valid governance — if that risk materializes, the organization has no defensible record that someone with real authority knowingly took it on, which auditors treat as a control failure in its own right and boards treat as a liability problem after the fact |
The fix | Tier acceptance authority to risk severity in the documented risk acceptance criteria — routine/low risks accepted at team-lead level, significant risks requiring department-head sign-off, critical or high risks requiring executive or board-level acceptance — and enforce it with an actual sign-off record, not a verbal nod |
This is one of the clearest places where risk acceptance criteria and risk ownership have to be designed together; one without the other just moves the same failure to a different column in the spreadsheet.
Theme Four: Treatment Linkage Mistakes
A risk assessment doesn't exist in isolation — it has to connect forward to treatment decisions and the Statement of Applicability, and backward to the reality of what's actually deployed. These four mistakes are about broken connections in that chain.
Mistake 11: No Link Between Register, Treatment Plan, and SoA
The register lists risks. A separate treatment plan lists actions. The Statement of Applicability lists control justifications. In a surprising number of organizations, these three documents were built at different times by different people and don't actually reference each other — a risk in the register has no visible path to the control that's supposed to treat it, or to the SoA line that documents why that control applies.
Element | Detail |
|---|---|
The mistake | The risk register, risk treatment plan, and Statement of Applicability exist as three disconnected documents with no traceable reference linking a specific risk to its treatment decision to its control justification |
Why it happens | The documents get built sequentially by different contributors (or at different points in the project) without a shared risk ID or cross-reference column carried through all three |
The consequence | This breaks Clause 6.1.3's requirement to produce a risk treatment plan and a Statement of Applicability that are demonstrably derived from the risk assessment — auditors trace this exact chain routinely ("show me the risk that justifies why control 8.24 is marked applicable"), and an untraceable chain is one of the most common Stage 2 major nonconformities in this entire domain |
The fix | Carry a single risk ID from the register through the treatment plan and into the SoA justification column, so any control's applicability can be traced back to a specific, scored risk in seconds |
Document | Purpose | Must Reference |
|---|---|---|
Risk Register | Identifies and scores risks | Risk ID, asset/scenario, owner, inherent score |
Risk Treatment Plan | Documents chosen treatment per risk | Same Risk ID, treatment option, controls selected, target date |
Statement of Applicability | Justifies control applicability | Same Risk ID(s) driving each applicable control, or explicit legal/contractual/business justification |
If you haven't built this traceability into your documents yet, the risk treatment plan implementation guide and the Statement of Applicability guide both cover the ID-carrying convention in detail.
Mistake 12: Ignoring Residual Risk
Teams do the hard work of identifying and scoring inherent risk, select a treatment, implement a control — and then never go back and score what's left over. The register shows the original risk score and a "treated" status, but no residual risk figure, no re-evaluation against the acceptance criteria.
Element | Detail |
|---|---|
The mistake | The register captures inherent (pre-treatment) risk scores but never calculates or documents residual risk after controls are implemented |
Why it happens | Residual risk scoring feels like redundant work once a control is "done," and there's no forcing function requiring it — treatment gets marked complete and the team moves to the next risk |
The consequence | Clause 6.1.3 requires organizations to determine whether residual risk is acceptable; without a documented residual score, there's no evidence this determination was ever made, and auditors will ask directly, "what's the residual risk on this one, and who accepted it?" |
The fix | Add a mandatory residual risk score and acceptance sign-off as the closing step of every treatment action — no treatment item is "closed" in the tracker until residual risk is scored and accepted by the owner |
Residual risk is also where the acceptance criteria conversation becomes concrete: a control might reduce impact but not eliminate it, and someone with the right authority has to actually look at what's left and decide it's tolerable.
Mistake 13: Copy-Paste Generic Registers
A shortcut that's tempting under deadline pressure: take a template or a prior client's register (or, increasingly, an AI-generated one), swap the company name, and call it done. The risks listed are plausible-sounding and technically correct in the abstract — but they were never actually assessed against this organization's assets, threats, or context.
Element | Detail |
|---|---|
The mistake | The risk register is substantially copied from a template, a generic industry list, or another organization's register, with minimal adaptation to reflect the organization's actual assets, processes, and threat exposure |
Why it happens | Time pressure ahead of certification, unfamiliarity with the risk assessment process, or over-reliance on consultants or AI tools producing generic content without a genuine identification workshop |
The consequence | Interviews expose this instantly — an auditor asking "why is this specific risk here, and where did this score come from?" gets a vague or inconsistent answer, because nobody actually derived it; this is one of the fastest ways to convert a documentation review into a credibility crisis for the whole ISMS |
The fix | Use templates and reference lists as a starting checklist, never as the final answer — every risk that ends up in the register should be traceable to an actual identification activity (asset inventory review, threat workshop, incident history, business interview), even if the wording resembles a common template |
The tell, every time, is that a genuine register has some risks that are oddly specific to the business and some scores that don't fit a clean pattern. A copy-paste register is suspiciously smooth.
Mistake 14: Ignoring Supplier, Third-Party, and Cloud Risk
Registers built primarily around internal IT assets frequently under-cover the risk introduced by suppliers, SaaS vendors, and cloud service providers — even when those third parties handle the organization's most sensitive data. This gap has grown sharply more consequential since supply-chain and cloud-specific controls were added in the 2022 revision.
Element | Detail |
|---|---|
The mistake | The risk assessment focuses almost entirely on internally owned assets and systems, giving little or no structured attention to risk introduced through suppliers, subcontractors, SaaS providers, or cloud infrastructure |
Why it happens | Internal assets are easier to inventory and feel more within the ISMS team's control; supplier and cloud risk requires visibility the organization doesn't fully own, so it gets deprioritized or handled informally outside the formal register |
The consequence | Given that controls 5.19–5.23 (supplier relationships and ICT supply chain) and 5.23 (cloud services) exist specifically because this is a recognized high-impact gap, auditors actively probe for it — an SoA that marks these controls applicable with no corresponding entries in the risk register is an obvious disconnect, and for organizations handling regulated data through third parties, it's often where the real exposure actually sits |
The fix | Build supplier and cloud risk into the identification workshop explicitly — map data flows to third parties, score risk scenarios for each critical vendor and cloud service, and tie the resulting entries directly to the supplier relationship security controls in the SoA |
This was, again, Meridian's actual top risk — an unencrypted vendor data feed — hiding in plain sight under a mountain of internal-asset entries that never should have out-ranked it in the first place.
Theme Five: Maintenance Mistakes
The last two mistakes aren't about how the register was built — they're about what happens to it after the certificate is issued, which is where a surprising number of otherwise well-built risk assessments quietly decay.
Mistake 15: Treating Risk Assessment as a One-Time Event
The register gets built carefully ahead of initial certification, survives Stage 1 and Stage 2 cleanly — and then sits untouched until it's time to worry about the next audit. New systems get deployed, vendors change, staff turn over, and none of it makes its way back into the risk assessment.
Element | Detail |
|---|---|
The mistake | The risk assessment is treated as a project deliverable completed once for certification, rather than an ongoing process reviewed and updated on a defined cycle |
Why it happens | Certification is the visible deadline that drives urgency; once achieved, attention shifts to other priorities and there's no calendar trigger forcing a re-look at the register |
The consequence | Clause 9.1 monitoring and measurement and the broader Clause 9 performance evaluation requirements expect the ISMS — including risk assessment — to be actively monitored and reviewed, and surveillance auditors specifically check register revision history for a stale "last updated" date that predates significant known organizational changes |
The fix | Schedule risk assessment review at fixed intervals (at minimum annually) and trigger ad hoc reviews on defined events — new system deployment, new supplier, security incident, organizational restructuring, significant new regulation — and record each review with a date and reviewer name even when the conclusion is "no change needed" |
"Surveillance audits are where stale risk registers get caught. Year one, everyone's register is fresh because they just built it for certification. Year two, I can tell within five minutes whether anyone touched it since." — Sanjay Kotwal, Senior Assessor, Northbridge Certification Group
This is also where the review cadence needs to be genuinely proportionate — an organization undergoing rapid change (new product lines, acquisitions, fast headcount growth) needs more frequent review than a stable one, and the review schedule itself should reflect that rather than defaulting to a single fixed annual date regardless of context.
Mistake 16: Not Covering the Full ISMS Scope
The final mistake is one of coverage: the risk assessment was built around the systems and processes that were top of mind at the time — usually core IT infrastructure — while parts of the organization formally included in the ISMS scope statement never got assessed at all.
Element | Detail |
|---|---|
The mistake | The formally defined ISMS scope includes certain business units, locations, processes, or systems that the risk assessment never actually addresses |
Why it happens | Scope statements get written broadly (sometimes for marketing or contractual reasons) without the risk assessment team fully cross-checking that every included element has actually been assessed; new acquisitions or business units get added to scope without a corresponding risk assessment update |
The consequence | Auditors literally compare the scope statement against the risk register line by line during Stage 1 — a scoped-in business unit, physical location, or major system with zero corresponding risk entries is one of the most mechanical, hard-to-argue-with nonconformities in the entire audit, because it's a simple document cross-check rather than a judgment call |
The fix | Maintain a scope-to-register coverage map as a standing artifact — every element named in the ISMS scope statement should have a traceable set of risk entries, and any scope change (new office, new acquisition, new major system) should trigger an immediate risk assessment update before the next surveillance audit, not at the next annual cycle |
This mistake is entirely mechanical to prevent and entirely mechanical to catch — which is exactly why it shows up so often in Stage 1 findings. It's a checklist problem, not a judgment problem, and it should never survive to Stage 2.
Self-Diagnosis Checklist: Run This Against Your Own Register Today
Before your certification body does this for you, walk through the table below honestly. Each row maps back to one of the sixteen mistakes above. If you can't answer "yes" with evidence you could show an auditor, treat it as an open finding.
# | Diagnostic Question | Mistake It Tests | Evidence You'd Need |
|---|---|---|---|
1 | Do we have a standalone, approved risk assessment methodology document? | Mistake 1 | Signed/approved methodology document, version-controlled |
2 | Is our register grouped into meaningful risk scenarios rather than hundreds of near-duplicate asset rows? | Mistake 2 | Register structure review; ratio of unique scenarios to total rows |
3 | Do our likelihood and impact scales have distinct, concrete anchor definitions? | Mistake 3 | Methodology document scale definitions |
4 | Does our top-10 risk list reflect our actual business model and current threats, not a generic template? | Mistake 4 | Business context statement, threat intelligence inputs cross-checked against register |
5 | Have we ever run a calibration exercise where two people scored the same risk independently? | Mistake 5 | Calibration session notes/output |
6 | Are any risk scores suspiciously clustered just under our treatment threshold? | Mistake 6 | Score distribution analysis |
7 | Do we have board- or leadership-approved risk acceptance criteria in writing? | Mistake 7 | Signed risk acceptance criteria document |
8 | Can our risk owners actually run the scoring process without specialist help every cycle? | Mistake 8 | Time-to-complete-cycle records, owner feedback |
9 | Does every risk have an owner with real authority over that specific asset or process — not a default "CISO"? | Mistake 9 | Owner assignment audit, ownership distribution across departments |
10 | Is every risk acceptance signed off at a level of authority proportionate to its severity? | Mistake 10 | Sign-off records tied to a documented authority matrix |
11 | Can we trace a specific risk ID from the register through the treatment plan into the SoA? | Mistake 11 | Sample trace exercise on 5 random risks |
12 | Does every closed treatment action have a documented residual risk score and acceptance? | Mistake 12 | Treatment tracker residual risk field completion rate |
13 | Can we explain, for any given risk, exactly how it was identified (workshop, interview, incident, inventory)? | Mistake 13 | Identification source field per risk |
14 | Are our critical suppliers and cloud services individually represented as risk scenarios? | Mistake 14 | Supplier/vendor risk entries cross-checked against vendor inventory |
15 | Has the register been reviewed and re-dated within the last 12 months, or after any major change? | Mistake 15 | Revision history log |
16 | Does every element in our ISMS scope statement have corresponding risk register entries? | Mistake 16 | Scope-to-register coverage map |
If you scored fewer than 12 "yes" answers with real evidence behind them, treat your next internal audit cycle as a risk-assessment remediation project, not a formality.
A Healthy vs. Broken Risk Process, at a Glance
The diagram below maps the same eight-step risk process twice: the broken version most of these mistakes produce, and the healthy version Clause 6.1.2/6.1.3 actually expects.
flowchart TD
A[Start: Define ISMS Scope] --> B{Methodology documented\nand approved?}
B -- No --> B1[BROKEN: scoring is ad hoc\nand unrepeatable]
B -- Yes --> C[Identify risks against\nreal business context]
C --> D{Grouped into meaningful\nscenarios, not asset sprawl?}
D -- No --> D1[BROKEN: signal drowned\nin thousands of trivial rows]
D -- Yes --> E[Score likelihood + impact\nagainst defined, anchored scales]
E --> F{Calibrated across scorers?}
F -- No --> F1[BROKEN: inconsistent,\nnot audit-defensible]
F -- Yes --> G[Assign owner with real\nauthority over the risk]
G --> H{Owner is CISO for\neverything?}
H -- Yes --> H1[BROKEN: no genuine\naccountability]
H -- No --> I[Select treatment;\nlink Risk ID to Treatment Plan and SoA]
I --> J{Traceable ID carried\nthrough all three documents?}
J -- No --> J1[BROKEN: SoA justification\ncan't be traced to a risk]
J -- Yes --> K[Score and accept residual\nrisk at proportionate authority]
K --> L{Reviewed and updated\non a defined cycle?}
L -- No --> L1[BROKEN: register goes\nstale, scope drifts]
L -- Yes --> M[HEALTHY: consistent, valid,\ncomparable, audit-ready]Every red branch on the left side of that diagram corresponds to one or more of the sixteen mistakes above. A healthy risk process isn't more complicated than a broken one — it just closes the loop at every decision point instead of leaving it open.
How Auditors Actually Spot These Mistakes
Understanding the auditor's toolkit is the fastest way to find your own gaps before they do. Experienced lead auditors don't read a risk register cover to cover looking for typos — they run a small set of targeted tests designed specifically to expose the mistakes above.
Auditor Technique | What It Exposes |
|---|---|
Trace a sample risk forward through register → treatment plan → SoA | Mistake 11 (broken linkage) and Mistake 13 (copy-paste entries with no real origin) |
Ask two different risk owners to independently re-score the same sample risk | Mistake 5 (inconsistent scoring) and Mistake 3 (likelihood/impact confusion) |
Interview a named risk owner directly about their risk's current status | Mistake 9 (no real owner) and Mistake 15 (stale, unreviewed register) |
Compare the ISMS scope statement line by line against the register | Mistake 16 (incomplete scope coverage) |
Ask "who accepted this risk, and on what authority?" for a sample of accepted risks | Mistake 7 (no acceptance criteria) and Mistake 10 (acceptance without authority) |
Check the register's last-modified date against known organizational changes (new office, acquisition, incident) | Mistake 15 (treating assessment as one-time) |
Look for a cluster of scores just under the treatment threshold | Mistake 6 (scoring theatre) |
Check whether supplier and cloud services appear as risk scenarios given SoA control 5.19–5.23 and 5.23 are marked applicable | Mistake 14 (ignoring third-party/cloud risk) |
Ask to see the residual risk field for a closed treatment action | Mistake 12 (ignoring residual risk) |
Ask management directly what their top business risks are, then check if those appear in the register | Mistake 4 (ignoring business context) |
None of these techniques require exotic tools. They're conversational, document-based, and repeatable — which is exactly why practicing them internally, through your own internal audit program, is the best preparation available. If your internal audit process isn't already running these same tests before Cascadia or Solvane or Northbridge shows up, it's missing its highest-value activity.
Case Studies
Case Study 1: Meridian Health Analytics — From Sprawl to Signal in Six Weeks
Returning to Priya Nathan's 1,847-line register: with six weeks until Stage 2 and a $340,000 contract riding on the certification date, a full rebuild wasn't realistic. Instead, her team ran a rapid consolidation exercise: individual asset rows were grouped into 46 risk scenarios organized by business process and data flow rather than by device. The unencrypted vendor data feed and the unreviewed database administrator account were pulled out, individually scored using the newly written methodology's anchored scales, and assigned real owners — the VP of Data Partnerships for the vendor feed, the Director of Engineering for the privileged account — rather than defaulting to Priya herself.
The rebuilt register dropped from 1,847 lines to 61, and every one of those 61 was traceable to an actual identification source and a named owner who could speak to it in an interview. The Stage 2 auditor still raised a minor nonconformity — the residual risk field was inconsistently completed across older treatment actions — but the structural finding from Stage 1 was fully closed. Meridian certified nine days before the contract deadline, and the finance director's post-mortem estimated the six-week remediation sprint, including two consultant days and roughly 90 hours of internal time, cost under $18,000 against a $340,000 contract that would otherwise have been at risk.
Case Study 2: Harrowgate Precision Manufacturing — Catching Scoring Theatre Before the Auditor Did
Harrowgate, a 300-employee industrial parts manufacturer running a legacy MES (manufacturing execution system) that the operations director was reluctant to replace, had a risk register where four separate risks tied to that legacy system all scored "medium" — just one point under the "high" threshold that would have triggered a mandatory remediation project in the treatment plan. During a pre-audit internal review, the ISMS manager noticed the pattern: every other system in the register had a natural spread of scores, but the legacy MES risks were suspiciously uniform and suspiciously close to the line.
A re-scoring session, conducted independently by a second assessor without knowledge of the original scores, produced three "high" results and one "medium" out of the same four risks — confirming the original scores had been softened. Rather than wait for the certification body to find the pattern (a technique described earlier in this article), Harrowgate's ISMS manager escalated to the operations director and COO directly, re-scored honestly, and built a genuine treatment plan: a $65,000 phased MES upgrade over 14 months, with interim compensating controls (network segmentation, enhanced logging) in place immediately. The external audit six weeks later found the corrected scores, the honest treatment plan, and zero nonconformities related to the MES risks — versus an almost-certain major nonconformity and a credibility hit to the whole register had the pattern been discovered externally instead.
"The moment I saw four risks tied to the same system all sitting at 'medium, one point under high,' I knew we had a problem before I even asked why. That kind of uniformity doesn't happen by accident." — Yusuf Amari, ISMS Manager, Harrowgate Precision Manufacturing
Case Study 3: Cordwell SaaS Group — Fixing Ownership and Supplier Blind Spots Together
Cordwell, a 90-person project-management SaaS vendor, had a technically sound register in most respects — well-documented methodology, decent calibration — but every single risk was owned by the CTO, and the register contained no entries at all for the three cloud infrastructure providers and two data-processing subprocessors the product depended on, despite the SoA marking supplier and cloud controls as fully applicable. The Stage 1 auditor flagged both issues as a single combined finding: ownership concentration and third-party risk coverage, tied together because the CTO, when asked, couldn't speak in detail about the subprocessors' own security posture.
Cordwell's remediation split ownership across four functional leads (engineering, customer success, finance/legal for contractual risk, and the CTO retaining only genuinely CTO-level architectural risks) and added 14 new risk scenarios covering the cloud providers and subprocessors, each scored using vendor security questionnaires and SOC 2 reports already on file as identification input. The re-audit, conducted five months later as a follow-up verification, closed both findings, and the ISMS manager reported that the new supplier risk entries directly drove two contract renegotiations — including adding breach-notification SLAs to one subprocessor agreement that hadn't previously included them, a concrete business benefit that came directly out of fixing the risk assessment rather than a separate initiative.
The Strategic Close: A Clean Risk Assessment Is a Competitive Asset, Not Just an Audit Requirement
It's tempting to read a list like this as sixteen ways to fail an audit, and stop there. That undersells what's actually at stake. A risk assessment that's genuinely traceable, honestly scored, and properly owned isn't just audit-ready — it's the tool your leadership team should be using to make real decisions about where security budget goes, which vendors carry disproportionate risk, and which legacy systems are quietly accumulating exposure. Every case study above ended with a business benefit beyond the certificate: Meridian closed a contract, Harrowgate got ahead of a legacy-system risk it had been avoiding, and Cordwell renegotiated supplier terms it hadn't previously scrutinized. The audit is the forcing function. The value is what the honest process produces once you stop performing for it.
"The organizations that treat risk assessment as a compliance chore end up rebuilding it every single year under deadline pressure. The organizations that treat it as a genuine decision-making tool end up barely touching it before an audit, because it was never allowed to go stale in the first place." — Priya Nathan, Head of Information Security, Meridian Health Analytics
If you recognize your own register in more than two or three of the mistakes above, the fix isn't a full rebuild from zero — it's a targeted remediation pass against the self-diagnosis checklist, starting with whichever row would cause the most damage if an auditor found it first. Ground the rebuild in the real Clause 6.1.2 and 6.1.3 requirements rather than in generic templates, and treat the ISO 27001 Clause 6 planning requirements as your anchor document throughout.
PentesterWorld's ISO 27001 practice works with organizations at exactly this stage — registers that were built fast under deadline pressure and now need to survive real audit scrutiny. If you want a second pair of experienced eyes on your risk assessment before your certification body provides one for you, that's a conversation worth having now, not six weeks before Stage 2.
To put these fixes into practice immediately, run your own register through the Risk Scoring Calculator to test for scoring consistency, compare your document structure against the ISO 27001 Risk Register Template, and use the ISO 27001 Gap Analysis Tool to check your risk assessment against the full set of Clause 6 requirements. If you want hands-on practice building the treatment side correctly, the Build a Sample Risk Treatment Plan lab walks through the exact Risk ID → treatment → SoA traceability this article recommends, and the Complete ISO 27001 Implementation Guide eBook covers the full risk management chapter in more depth than a single article can.
Related reading: for the mechanics of building the register itself, see how to build an ISO 27001 risk register; for choosing between assessment approaches before you rebuild, see asset-based vs. scenario-based risk assessment; and for grounding your terminology, the ISO 27001 glossary and the myths and misconceptions article are both useful references to share with new risk owners who are still learning the vocabulary. Organizations running parallel SOC 2 or NIST CSF programs should also read how SOC 2 risk assessment requirements and the NIST CSF risk management framework compare, since much of the remediation work described here transfers directly across frameworks.