Two Frameworks, Same Question: What Would a Breach Actually Cost?
A dual-framework gap analysis kept producing checklist gaps until I forced every one into a residual-risk number.
Halfway through the gap analysis, I had a spreadsheet with dozens of rows, each one marked "fully implemented," "partially implemented," or "not implemented" against an ISO 27001:2022 Annex A control. It looked thorough. It told the business almost nothing. A control marked "partially implemented" for third-party access review carries a completely different weight than one marked the same way for physical entry logging — and the checklist format had no way to show that difference.
The Question Frameworks Don't Answer
ISO 27001 tells you which controls exist. The NIST Cybersecurity Framework (NIST CSF) tells you how mature your capability is across Identify, Protect, Detect, Respond, and Recover. Neither one, on its own, tells you what happens to the business if a specific gap is exploited.
That's a problem, because "not implemented" isn't a risk statement — it's an observation. A missing control on a low-value, air-gapped internal tool and the same missing control on the system holding customer payment data are not equivalent findings, even though both would appear as an identical red flag on a compliance checklist. Treating them the same is how organisations end up spending remediation budget on the wrong twenty percent.
The assessment covered the full information security landscape of a simulated enterprise: access controls, data classification, network posture, endpoint protection, incident response capability, third-party risk, and business continuity. Running ISO 27001 and NIST CSF gap analyses in parallel across that scope produced two lists of findings that agreed on roughly where the weaknesses were and disagreed almost entirely on how to prioritise fixing them — because neither framework, by itself, prices the gap.
Building the Risk Register
The risk register is the tool that closes that gap. For every identified risk, it forces four things onto one line: the asset, the threat, the existing control (and its actual effectiveness, not its documented existence), and a calculated residual risk.
Residual Risk = Likelihood (1-5) × Impact (1-5)
A simplified example from the register, illustrating the format rather than reproducing the full assessment:
| Asset | Threat | Existing Control | Likelihood | Impact | Residual Risk | |---|---|---|---|---|---| | Customer database | Third-party vendor with unreviewed access | Access granted, never re-certified | 4 | 5 | 20 (Critical) | | Endpoint fleet | Phishing-delivered malware | Antivirus only, no EDR | 3 | 4 | 12 (High) | | Physical server room | Unauthorised entry | Badge access, no visitor log | 2 | 3 | 6 (Moderate) |
The likelihood and impact scores aren't guesses — they come from evaluating the threat against the asset's actual criticality to business operations and the control's actual effectiveness, not its presence on paper. A control that exists but isn't enforced (access granted but never re-certified, in the example above) scores no better than no control at all, because likelihood is unaffected by controls nobody checks.
This is the step a pure compliance checklist skips. ISO 27001 would mark "third-party access review" as partially implemented and move on. The register asks what that gap does to the customer database specifically, and returns a number — 20, critical — that a compliance status can't produce on its own.
Where the Two Frameworks Earn Their Keep
Run side by side, ISO 27001 and NIST CSF stop being redundant and start doing different jobs. ISO 27001's Annex A gives the register its inventory — a structured list of every control domain that needs a current-state and a gap assessment, so nothing gets missed. NIST CSF's five functions give the register its lifecycle view — whether the organisation's weakness sits in Identify (don't know what we have), Detect (can't see it happening), or Respond (see it, can't act fast enough).
That distinction changes what "high priority" means. Two gaps with an identical residual risk score can call for entirely different remediation if one sits in Protect and the other in Detect: hardening a control is a different project than building visibility into one that already technically exists. Mapping both frameworks onto the same register, rather than producing two separate reports, is what makes the prioritisation defensible rather than arbitrary.
The Translation That Matters
The output that actually matters to a business isn't the gap analysis. It's the sentence that follows it: "This gap has a residual risk score of 20 out of 25, driven by unreviewed third-party access to the customer database — here is what closing it costs, and here is what leaving it open costs if it's exploited."
That sentence is why the improvement programme built from this assessment was structured in three phases rather than delivered as a flat list. Phase one addressed the highest residual-risk items first, regardless of which framework flagged them — critical remediations and incident response readiness. Phase two moved to ISO 27001 control strengthening and third-party risk process, once the acute exposure was down. Phase three focused on NIST CSF maturity and continuity testing, the longer-horizon work that compounds rather than eliminates risk. The sequencing came directly from the register's scores, not from which framework's checklist looked more urgent.
A gap analysis that hands leadership a long spreadsheet of implementation status is a document. A gap analysis that hands leadership a prioritised list of business-impact numbers, with a phased plan to bring the worst ones down first, is a decision-making tool. The frameworks provide structure and vocabulary. The register — and the discipline of forcing every finding through likelihood and impact before it reaches a priority list — is what makes the output usable.
The Takeaway
A checklist tells you what's missing. A risk register tells you what missing it will cost. The real value in a compliance gap analysis isn't identifying the gap — auditors and checklists do that reliably. It's translating each gap into a number leadership can weigh against a budget, which is the difference between a report that gets filed and a plan that gets funded. It's also the difference between a compliance exercise and a GRC discipline — one that treats risk, not just control status, as the unit leadership actually acts on.
This assessment was part of my MSc Cybersecurity at Robert Gordon University. Full project write-up: Information Security Risk Assessment & ISO 27001 / NIST Gap Analysis