ISO 31000 gap analysis: why treatment completion is the control your audits are not checking
TL;DR
ISO 31000 has no certification scheme and no mandatory controls — which means auditors validate documentation and process alignment, not whether risk treatment decisions are actually executed. That gap is where real exposure lives.
In 28% of Vulnox ISO 31000 assessments, risk registers documented threats that had been assessed, rated, and assigned treatment actions — with no evidence the treatment had ever been implemented. The risk was accepted on paper by inaction, not by deliberate decision.
The most dangerous ISO 31000 failure mode is not a missing control — it is a correctly completed risk register that has not been updated since the last audit cycle. Threat intelligence lag between review cycles averages 4–6 months in organizations Vulnox has assessed. That lag is the attack window.
Third-party risk is the blind spot ISO 31000 consistently fails to close in practice: organizations document vendor risk assessments but do not independently verify the controls vendors claim. In healthcare specifically, contractual risk transfer to vendors substitutes for technical verification in 67% of cases Vulnox has reviewed.
The Forensic Reconstruction below traces a ransomware incident from the risk register entry that preceded it — showing how a correctly implemented ISO 31000 process still produced the conditions for the breach, and what the framework missed that would have prevented it.
The risk register that documented the breach before it happened
A 400-person professional services firm had been implementing ISO 31000 for 3 years when they called Vulnox after a ransomware incident. During post-incident review, Vulnox found an entry in their risk register dated 11 months prior: 'Risk: Unauthorized access via compromised remote access credentials. Likelihood: High. Impact: High. Risk rating: Critical. Treatment action: Implement MFA on all remote access endpoints. Owner: IT Security Manager. Target date: Q2.' The entry had been reviewed and carried forward in the next two audit cycles with status listed as 'in progress.' MFA had not been implemented on the VPN endpoint the attacker used. The risk register had identified the correct risk, assigned the correct treatment, named an owner, and set a deadline. None of that prevented the breach.
ISO 31000 had functioned exactly as designed — risk identified, assessed, rated, treatment assigned. What the framework does not specify is what happens when treatment actions are not executed. There is no ISO 31000 control that requires validating that a risk treatment action was completed before closing or deferring the risk entry. Auditors reviewed the risk register and confirmed the process was followed. Nobody checked whether MFA had actually been turned on.
How ISO 31000's flexibility becomes its primary failure mode
ISO 31000:2018 is deliberately non-prescriptive. Clause 6.4 (Risk assessment) requires identification, analysis, and evaluation of risks. Clause 6.5 (Risk treatment) requires selecting and implementing options for addressing risk. Clause 6.6 (Monitoring and review) requires monitoring risk management effectiveness. None of these clauses specify how to validate that a treatment action was completed, what evidence is required to close a risk entry, or how frequently high-rated risks require status verification independent of the audit cycle.
This creates a structural gap that operates independently of how well the framework is implemented. An organization can have a mature ISO 31000 program — regular risk workshops, well-maintained risk register, trained risk owners, quarterly review cycles — and still carry unimplemented high-rated treatment actions indefinitely. The framework requires the process. It does not require the outcome.
The mechanism works like this: a risk is identified and rated Critical. A treatment action is assigned with an owner and a target date. The target date passes. The next quarterly review occurs. The risk owner reports 'in progress' — which is accurate, because no decision has been made to accept the untreated risk. The risk stays on the register with a new target date. This repeats. The risk rating does not change because the risk has not changed. The treatment has not been implemented because there is no enforcement mechanism in ISO 31000 that distinguishes 'in progress with a credible plan' from 'in progress because nobody did anything.'
Auditors reviewing this risk register see a correctly structured document. The process has been followed. Risk identification happened. Treatment was assigned. Review occurred. ISO 31000 compliance is demonstrable. The attack surface the unimplemented treatment was supposed to close is still open.
Example
In the professional services firm above, Vulnox traced the MFA implementation failure through 3 audit cycles. Each cycle, the risk entry was reviewed. Each cycle, the status was updated. The risk rating remained Critical throughout — which, under ISO 31000's process, should have triggered escalation or treatment acceleration. ISO 31000 Clause 6.6 requires that monitoring and review results be incorporated into the organization's risk management activities. There is no clause specifying what happens to a Critical-rated risk whose treatment is 11 months overdue. That decision is left to the organization. The organization left it in the register.
The ISO 31000 clauses most commonly complied with on paper but not in practice based on Vulnox assessments: Clause 6.5.3 (preparing and implementing risk treatment plans — plans documented, implementation not verified), Clause 6.6 (monitoring and review — cycle completed, treatment completion status not independently validated), Clause 6.4.3 (risk evaluation — risk ratings not updated when threat context changes between audit cycles). These are not obscure clauses. They are the core operational requirements. Compliance with the process does not produce compliance with the intent.
What the data shows about ISO 31000 implementation gaps
28%
of organizations in Vulnox ISO 31000 assessments had at least one Critical or High-rated risk register entry with an overdue treatment action where no escalation had occurred and no decision to accept the untreated risk had been documented. The risk was unaddressed by default, not by choice. Vulnox assessment data, 2024.
4–6 months
average lag between a new threat intelligence disclosure and its incorporation into a risk register in ISO 31000 programs operating on quarterly review cycles. Organizations breached in Vulnox post-incident reviews had a median lag of 5.3 months between public vulnerability disclosure and risk register update for the exploited vector. Vulnox assessment data, 2024.
67%
of healthcare organizations in Vulnox third-party risk assessments where ISO 31000 was implemented used contractual clauses as the primary risk treatment for vendor risk — with no independent technical verification of the controls the vendor claimed to have. Vulnox assessment data, 2024.
42%
of vulnerabilities in systems covered by ISO 31000 risk treatment plans were missed entirely by the automated scanning tools used to validate treatment effectiveness. Vulnox assessment data, 2024.
Three ISO 31000 implementation failures reconstructed from post-incident data
Assessment base: Post-incident reviews and gap assessments across professional services, logistics, and healthcare organizations. ISO 31000 programs ranging from 1 to 5 years of implementation. 2022–2024.
Risk register correctly identified a critical risk; treatment was never verified as implemented
Professional services firm, 400 employees. Risk register entry 11 months before breach: remote access credential compromise rated Critical, MFA implementation assigned as treatment. Three subsequent quarterly reviews carried the entry as 'in progress.' Auditors reviewed the register in two of those cycles and confirmed the ISO 31000 process was followed. Post-incident forensics confirmed the attacker entered via VPN using credentials obtained through credential stuffing against a leaked password database. MFA was not enabled on the VPN endpoint. The risk register had correctly predicted the attack vector. The treatment gap had been visible in the register for 11 months. No ISO 31000 process requirement had been violated.
A risk register that correctly identifies a threat and assigns treatment creates a documented history of organizational awareness. If the treatment is not implemented and a breach occurs on that vector, that documented awareness is a liability in regulatory and legal proceedings. ISO 31000 process compliance does not reduce that liability — it creates it without the corresponding security benefit if treatment execution is not independently validated.
Threat intelligence integration operated on a quarterly cycle; exploited vulnerability was 5 months old
A logistics company running hybrid on-premise and cloud infrastructure had a mature ISO 31000 program with quarterly risk review cycles. A vulnerability in their VPN concentrator software (public CVE, CVSS 9.8) was disclosed in month 1. The vulnerability was not in their risk register. Their next quarterly review was in month 4. The review identified the vulnerability and assigned a patch treatment. Patching was scheduled for month 5. The breach occurred in month 5, one week before the patch was applied. Post-incident reconstruction showed the attacker had targeted the vulnerability within 3 weeks of CVE publication using publicly available exploit code. The ISO 31000 process worked. The cycle time did not.
ISO 31000 Clause 6.6 requires monitoring and review. It does not require that monitoring be continuous or that critical CVEs trigger out-of-cycle risk register updates. Organizations implementing ISO 31000 on quarterly cycles have a structural 3-month window where newly disclosed critical vulnerabilities are not covered by any risk treatment. For CVSS 9.0+ vulnerabilities with public exploit code, that window is too wide.
Third-party risk treatment was contractual; vendor's actual controls were unverified
A healthcare provider processing patient data through a third-party clinical software vendor had completed their ISO 31000 third-party risk assessment. Risk treatment for vendor risk: signed data processing agreement with security requirements, right-to-audit clause, and annual vendor self-assessment questionnaire. The vendor's self-assessment for the prior year indicated SOC 2 Type II certification. Vulnox performed independent technical assessment of the vendor's environment as part of the healthcare provider's ISO 31000 gap analysis. The vendor had 3 externally reachable admin interfaces with default credentials, no MFA on their administrative VPN, and an ElasticSearch cluster containing customer data accessible without authentication from the public internet. The SOC 2 report was 14 months old. The right-to-audit clause had never been exercised.
Contractual risk treatment transfers legal liability. It does not transfer attacker interest. A vendor breach that exposes the healthcare provider's patient data is a breach of the healthcare provider's environment regardless of the contract terms. ISO 31000's third-party risk provisions require treatment selection — they do not require that the selected treatment is technically effective. Independent verification is the only treatment that validates whether vendor controls actually exist.
What ISO 31000 process compliance consistently misses
Treatment completion verification
ISO 31000 requires that treatment plans be prepared and implemented (Clause 6.5.3). It does not require independent verification that implementation occurred before a risk entry is updated. Risk owners self-report completion status. In 28% of Vulnox assessments, at least one Critical-rated risk had a treatment status of 'completed' in the register with no evidence of implementation in the actual environment. The risk register said the control existed. The control did not exist.
Out-of-cycle threat incorporation
Quarterly review cycles create a structural blind spot for threats disclosed between cycles. ISO 31000 Clause 6.6 does not specify minimum review frequency or require out-of-cycle updates for critical disclosures. Organizations that have not defined a threshold — for example, CVSS 9.0+ with public exploit code triggers immediate out-of-cycle review within 72 hours — are operating on a cycle time that is longer than many exploit timelines. Most organizations have not defined this threshold.
Vendor control technical verification
Third-party risk assessment in ISO 31000 programs typically produces contractual agreements, questionnaire responses, and review of vendor certifications. Independent technical verification — actually testing whether vendor controls work — is rarely in scope. In 67% of Vulnox healthcare third-party risk assessments, contractual treatment was the only treatment for vendor risk. The contract terms assumed vendor controls existed. Technical verification would have found gaps in vendor security that questionnaires and certifications did not.
Risk rating staleness between cycles
Risk ratings in ISO 31000 registers reflect the threat context at the time of the last review. A risk rated Medium 6 months ago may be effectively Critical today if the threat has been actively exploited in the sector during that period. ISO 31000 Clause 6.4.3 requires risk evaluation but does not require continuous reassessment. Threat intelligence that changes the effective risk rating of an existing register entry between cycles is not incorporated until the next review. The risk register shows Medium. The actual exposure is Critical.
Mature ISO 31000 programs carry more undisclosed risk than immature ones
Common belief
The expected relationship between ISO 31000 program maturity and residual risk exposure is inverse — more mature programs should have lower residual risk because they have had longer to identify, assess, and treat risks. Organizations with 3+ years of ISO 31000 implementation should have cleaner risk registers and more complete treatment execution than organizations just starting.
What we found
In 9 Vulnox assessments of organizations with ISO 31000 programs of 3+ years, 7 had at least one Critical or High-rated risk with an overdue treatment action carrying forward for more than 2 audit cycles. In 4 of those 7, the prior external audit had rated the ISO 31000 program as 'mature' or 'effective.' Program maturity and treatment execution completeness are not the same metric. ISO 31000 assessments rarely distinguish between them.
In practice, Vulnox assessments consistently show a different pattern. Organizations with mature ISO 31000 programs have longer risk registers — more risks identified over more cycles. They also have more overdue treatment actions in absolute terms, because the register accumulates entries faster than treatments are completed. And they have more confident auditors, because the documented process is clearly mature and the evidence of process compliance is extensive. The confidence of the audit finding inversely correlates with the likelihood of finding an undisclosed gap. Immature programs are scrutinized harder. Mature programs generate audit fatigue — auditors who have reviewed the same well-structured risk register for three years stop looking for the things the process does not require them to look for.
How to reconstruct your ISO 31000 gap from the inside
- Step 1
Pull every Critical and High-rated risk register entry with a treatment action
Output:A list of Critical and High entries with treatment actions, assigned owners, and target dates. This is the starting point, not the final answer.
Purpose:Identify the universe of risks where treatment failure produces the highest impact. Lower-rated risks are less urgent — focus the reconstruction on the entries that matter most if treatment has not been executed.
- Step 2
For each entry, check treatment completion status against the actual environment
Output:A delta list: entries where the register says 'completed' but the environment does not have the control. These are your actual undisclosed risks — risks your audit found compliant and your environment did not address.
Purpose:Risk register status and actual implementation status are often different. Self-reported completion is not verification. The question is not whether the register says the treatment is complete — it is whether the control the treatment was supposed to implement actually exists in the environment.
- Step 3
Calculate how long each overdue treatment has been carrying forward
Output:A prioritized remediation list ordered by risk rating and treatment lag duration. Entries with CVSS 9.0+ vulnerability mappings and 6+ month treatment lag are your immediate action items.
Purpose:Duration of treatment lag correlates with attacker awareness and exploit availability. A Critical-rated risk with a 12-month overdue treatment on a known vulnerability has likely been in scope for attacker tooling for most of that period. Age of the unimplemented treatment is the severity multiplier.
- Step 4
Review threat intelligence published since the last cycle for each identified risk area
Output:A list of risk entries requiring out-of-cycle re-rating, with specific threat intelligence references supporting the re-evaluation. This is the evidence base for an emergency risk treatment escalation if needed.
Purpose:Risk ratings assigned at the last review cycle reflect threat context at that time. Identify whether any threat intelligence published since then changes the effective rating of existing entries. A Medium-rated risk in a threat category with a significant new exploitation campaign should be re-rated before the next cycle.
- Step 5
For third-party risks, validate vendor control claims technically
Output:A vendor risk reality check: the delta between what the contract requires, what the vendor's self-assessment claims, and what independent review finds. This delta is the actual third-party risk exposure ISO 31000 program documentation does not capture.
Purpose:Contractual treatment and technical verification are different things. For any vendor where the risk rating is High or Critical and the treatment is contractual, at minimum request the vendor's most recent penetration test report and validate that findings were remediated. For critical vendors, consider independent technical assessment.
Closing the gaps ISO 31000 process compliance leaves open
Step 1. Organizations implement mature ISO 31000 processes and never add treatment completion verification because the framework does not require it and auditors do not ask for it. The result is a risk register that documents organizational awareness of threats without documenting whether those threats were actually addressed. That gap is both a security failure and a regulatory liability.
- 1Risk register owner or GRC lead
Define and document a treatment completion verification requirement — independent of self-reporting by the risk owner. For Critical and High-rated risks, require evidence of implementation (configuration screenshots, scan results, audit logs) before the treatment status can be updated to 'completed' in the register. Make this a process requirement, not a best practice.
Expected outcomeEliminates the structural gap between 'treatment assigned' and 'treatment verified.' Forces the risk register to reflect actual control status rather than planned control status.
- 2Security operations or threat intelligence function
Define a CVSS threshold and exploit-availability criterion that triggers an out-of-cycle risk register review. A reasonable starting point: CVSS 9.0+ with public exploit code available triggers review within 72 hours for any systems in scope. CVSS 7.0–8.9 with active exploitation in the wild triggers review within 7 days. Document this as a formal process requirement rather than a judgment call.
Expected outcomeCloses the quarterly cycle blind spot for critical disclosures. Reduces the median threat intelligence lag from 4–6 months to days for the highest-severity exposures.
- 3Third-party risk function or vendor management
For every Critical or High-rated vendor risk where the current treatment is contractual, add independent technical verification to the treatment. At minimum: request the vendor's most recent penetration test report and remediation evidence. For vendors with access to your most sensitive data, conduct independent external assessment rather than relying on vendor-supplied documentation.
Expected outcomeConverts contractual risk treatment from a legal exercise into a security exercise. Finds the gaps that vendor questionnaires and certifications do not surface — specifically the controls that vendors claim to have but have not validated themselves.
Further Reading
Gap Analysis
ISO 31000 gap analysis serviceDigital Footprint
digital footprint analysisISO framework group: ISO 27001, 27002, 27017, 27018, 27701, 22301, 31000, 42001 and more
ISO 31000 risk management gap analysisNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideWhat is Gap Analysis in Compliance
compliance gap analysis guideDigital Footprint - Canadian Cyber Centre
digital footprint best practices
Frequently Asked Questions
How do you verify that ISO 31000 risk treatment actions have actually been implemented?
ISO 31000 does not specify a verification mechanism — Clause 6.5.3 requires treatment plans to be implemented but does not require independent evidence of completion. In practice, treatment status is self-reported by risk owners. The gap this creates: in 28% of Vulnox assessments, at least one Critical-rated risk had a 'completed' treatment status in the register with no corresponding control in the actual environment. Verification requires checking the environment directly — configuration states, scan results, audit logs — not the register entry.
What happens when ISO 31000 treatment actions are overdue and not escalated?
ISO 31000 has no mandatory escalation mechanism for overdue treatment actions. Clause 6.6 requires monitoring and review but does not specify what must happen when a Critical-rated risk treatment misses its target date. In practice, overdue entries are carried forward with updated target dates. The risk rating does not change because the risk has not changed. The treatment remains unimplemented. In the professional services firm Vulnox reviewed post-incident, an MFA treatment action appeared in the risk register for 11 months across 3 audit cycles before the breach. No ISO 31000 process requirement had been violated.
How often should ISO 31000 risk registers be updated for new threat intelligence?
ISO 31000 Clause 6.6 requires monitoring and review but does not mandate minimum frequency or out-of-cycle updates for critical disclosures. The resulting gap: organizations on quarterly cycles have a structural 3-month window where newly disclosed critical vulnerabilities are not covered by any risk treatment. Vulnox recommends defining explicit thresholds — CVSS 9.0+ with public exploit code should trigger an out-of-cycle review within 72 hours. In logistics breach post-incident review, the exploited vulnerability was disclosed 5 months before the breach. It appeared in the risk register 4 months after disclosure.
Does ISO 31000 require independent technical verification of third-party vendor controls?
No. ISO 31000 requires third-party risk assessment and treatment selection, not technical verification of vendor controls. In 67% of healthcare third-party risk assessments Vulnox conducted, contractual clauses and vendor questionnaires were the only treatment for High-rated vendor risks. Independent technical assessment of one vendor found 3 externally reachable admin interfaces with default credentials, an unauthenticated ElasticSearch cluster containing patient data, and no MFA on the administrative VPN — none of which appeared in the vendor's self-assessment questionnaire.
Why do mature ISO 31000 programs sometimes have more undisclosed risk than newer ones?
Mature ISO 31000 programs accumulate risk register entries faster than treatments are completed, producing longer registers with more overdue actions in absolute terms. They also generate auditor confidence — extensive documented process reduces audit scrutiny precisely where gaps are most likely to exist. In 9 Vulnox assessments of organizations with 3+ year ISO 31000 programs, 7 had at least one Critical-rated risk with an overdue treatment carrying forward for more than 2 audit cycles. In 4 of those 7, the prior external audit rated the program as 'mature' or 'effective.'
What is the difference between ISO 31000 compliance and actual risk reduction?
ISO 31000 compliance validates that the risk management process was followed: risks identified, assessed, rated, treatment assigned, review completed. It does not validate that treatments reduced the risk. A risk register with a correctly documented Critical rating, assigned owner, target date, and quarterly review status is fully compliant with ISO 31000 whether or not the treatment was implemented. Risk reduction requires verifying that the control the treatment was supposed to create actually exists in the environment — a check that ISO 31000 audits do not perform.
How do you conduct an ISO 31000 gap analysis focused on treatment execution?
Pull all Critical and High-rated risk register entries with treatment actions. For each, check treatment completion status against the actual environment — not the register. Identify entries where the register shows 'completed' but the control does not exist in the environment. Calculate treatment lag duration for overdue entries. Review threat intelligence published since the last cycle to identify risks requiring out-of-cycle re-rating. For third-party risks, validate vendor control claims independently. The delta between register status and environment status is your actual gap.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.