ISO 31010 risk assessment gaps: what the techniques miss in real environments
Julian ThorneApril 29, 2026
Key takeaways
ISO 31010 provides 31 risk assessment techniques in Annex A but does not specify when qualitative methods are insufficient and quantitative analysis is required. Organizations default to the techniques they already know, which means the technique selection reflects organizational familiarity, not risk complexity.
The framework''s requirement to consider likelihood and impact does not specify how to calibrate likelihood estimates against real attack data. In Vulnox assessments, the most common finding is risk ratings that systematically underestimate likelihood for technical attack vectors because the estimates were produced by governance teams without access to current threat intelligence.
ISO 31010 scoping decisions routinely exclude the external attack surface. What an attacker can discover through passive reconnaissance, exposed development infrastructure, and digital footprint analysis does not appear in most ISO 31010 risk registers because scoping treats the organizational boundary as the assessment boundary.
The 178-day average window between exposure and discovery in Vulnox client environments means that a point-in-time ISO 31010 assessment is measuring a risk landscape that has already changed. The framework has no mechanism for validating that risk ratings remain accurate between assessment cycles.
Risk assessments that produce clean documentation while leaving exploitable conditions undocumented are not failed assessments in any audit-visible way. The failure is invisible until something is exploited.
TL;DR
ISO 31010 is a framework for thinking systematically about risk. The problem is that systematic thinking about risk and accurate measurement of risk are not the same thing. Organizations use the framework to produce documented, auditable risk assessments. Attackers do not consult those documents. The gaps that matter are in likelihood calibration, scope definition, and the absence of any mechanism for validating risk ratings against what is actually happening in the environment. The framework produces a record of what the assessment team believed. It does not produce a record of what the attackers found.
The risk register said low. The SQL injection said otherwise.
An e-commerce platform had completed an ISO 31010 risk assessment eight months before a Vulnox engagement. The assessment was thorough by documentation standards. Risks were categorized, likelihood and impact were rated, mitigation strategies were assigned. DDoS risk was rated high and had received significant investment: additional bandwidth, a CDN layer, rate limiting controls. SQL injection risk was rated low because the development team had reviewed their input validation procedures during the assessment and confirmed they were in place. During the Vulnox scan, we found a SQL injection vulnerability in their product search endpoint that had been introduced in a deployment three months after the risk assessment closed.
The risk assessment had not failed to consider SQL injection as a risk category. It had rated the likelihood as low based on a review of documented procedures at the time of assessment. The procedure review and the production deployment existed in separate processes with no mechanism connecting them. The risk rating was accurate when it was assigned. It stopped being accurate 90 days later when new code went out. The ISO 31010 framework does not specify how often risk ratings should be revalidated against actual system state.
How ISO 31010 technique selection produces systematic blind spots
ISO 31010 Annex A lists 31 techniques ranging from simple brainstorming and checklists through structured methods like FMEA and HAZOP to quantitative approaches including Monte Carlo simulation, Bayesian networks, and Markov analysis. The standard''s guidance on technique selection is contextual: the choice should depend on the nature of the risks, data availability, and resources. This is sound as a principle. In practice, it means organizations select techniques based on what their teams already know how to use, what their GRC tools support, and what previous assessments used. The technique selection reflects organizational inertia rather than risk complexity. A financial services firm with a mature risk team and sophisticated GRC tooling will apply quantitative methods. A 60-person SaaS company will use a qualitative likelihood-impact matrix. The framework does not tell either of them when they are under-analyzing.
Example
The human factors consideration in ISO 31010 Clause 6.3.4 illustrates where contextual guidance breaks down in technical security contexts. The clause requires that human factors be considered in risk assessment. A checklist-based assessment of a mobile banking application will document employee training as the primary human factor control. What it will not surface is whether the application''s UI design creates conditions for social engineering, whether notification fatigue in the mobile app leads users to approve illegitimate push requests, or whether the onboarding flow for new devices creates an authenticator enrollment vulnerability. Those are human factors in any reasonable interpretation of the term. They do not appear in checklist-based assessments because the technique does not ask for them.
The distinction between qualitative and quantitative risk assessment matters more than most ISO 31010 implementations acknowledge. Qualitative ratings produce relative rankings. They tell you that risk A is higher than risk B. They do not tell you how much higher, or whether the mitigation investment required to address risk A is proportionate to its actual expected loss value. For investment decisions above a certain threshold, that difference is material. The framework does not specify the threshold.
What risk assessments miss that technical assessments find
Assessment base: Vulnox assessment data, 2024-2025, manufacturing, logistics, financial services, and SaaS environments where ISO 31010 risk registers were reviewed as part of the engagement.
Likelihood ratings systematically disconnected from current threat intelligence
In risk assessments reviewed as part of Vulnox engagements, the most consistent pattern is likelihood ratings produced by governance or compliance teams without access to current threat intelligence data. A manufacturing company''s ISO 31010 assessment rated ransomware likelihood as medium based on the general observation that ransomware was a known threat category. The rating did not incorporate the fact that the company''s industry sector had been the target of three specific ransomware campaigns in the preceding six months, that two of their direct competitors had been hit, or that their remote access infrastructure used the same VPN product that had been exploited in both incidents. The risk rating was defensible as a documented assessment. It was not defensible as a current measurement of their actual exposure.
The client believed their risk register reflected their current exposure. The actual state was that the register reflected their exposure at the time of assessment, calibrated against threat intelligence that was not current. ISO 31010 does not specify how likelihood estimates should be sourced or how frequently they should be updated against real attack data. Organizations that conduct annual assessments and do not refresh likelihood ratings between cycles are operating on a risk picture that is 12 months stale by the time the next assessment runs.
External attack surface entirely absent from risk scope
Across ISO 31010 assessments reviewed in Vulnox engagements, the consistent scoping decision was to treat the organizational network boundary as the risk assessment boundary. Risks associated with external exposure, including subdomain enumeration, exposed development and staging infrastructure, digital certificate transparency data, and passive reconnaissance value of the organization''s public-facing assets, were not included in any risk register reviewed. In one case, a logistics company had a staging environment indexed in Shodan running with default credentials. The ISO 31010 risk register contained a control for default credential management. The control applied to production systems. The scoping decision had excluded staging infrastructure.
The assumption embedded in most ISO 31010 scoping decisions is that risk assessment covers what the organization owns and operates intentionally. The external attack surface includes what attackers can see and enumerate about the organization''s environment whether or not the organization is aware of it. Those are different scopes. An attacker performing passive reconnaissance does not observe the organization''s scoping decisions.
Risk treatment validation absent after mitigation implementation
ISO 31010 Section 7 covers the risk assessment process including risk treatment. The standard describes identifying treatment options, implementing controls, and monitoring residual risk. In practice, the feedback loop between control implementation and risk rating update is broken in most organizations reviewed. Controls are implemented. Risk ratings are not updated to reflect whether the controls achieved their intended effect. In several assessments, risks rated as treated and closed had associated controls that had been implemented but misconfigured, creating a residual exposure that was invisible in the risk register because the rating had been updated based on control deployment rather than control effectiveness validation.
A risk rated as treated is treated in the documentation. Whether the treatment reduced the actual exposure requires testing the control in the production environment. ISO 31010 does not specify that control effectiveness validation should be part of the risk treatment cycle. Most organizations do not perform it.
More rigorous risk documentation correlates with larger gaps between rated and actual risk in some environments
Common belief
Organizations with mature, well-documented ISO 31010 risk assessment programs have more accurate risk pictures because they have invested in systematic methodology and consistent process.
What we found
In engagements where we reviewed formal ISO 31010 risk registers alongside technical assessment findings, the organizations with the most structured and complete risk documentation consistently had the largest gaps between rated risk and observed technical exposure. The hypothesis is not that documentation makes organizations less secure. It is that documentation programs create an internal audience for risk artifacts that is satisfied by documentation quality, which is separate from the question of whether the documentation is accurate.
Documentation maturity and risk accuracy are not the same measurement, and in some environments they are inversely related. Organizations that have invested heavily in ISO 31010 documentation programs tend to have GRC teams whose primary accountability is to the documentation output rather than to the operational security outcome. The GRC team owns the risk register. The security operations team owns the technical controls. The two functions often do not have a structured mechanism for validating that the risk register reflects what the security operations team is actually seeing in the environment. The more sophisticated the documentation program, the more removed the risk register authors tend to be from the technical reality they are rating.
What ISO 31010 assessments consistently do not see
Attack path chaining across individually low-rated risks
ISO 31010 assesses individual risks. Real attack chains combine multiple conditions, each of which might be rated low or medium in isolation, into a path that produces a high-impact outcome. A low-rated misconfiguration in a staging environment combined with a medium-rated insufficient network segmentation control and a low-rated default credential finding creates a path to production data. None of the individual risk ratings is wrong. The risk register does not contain an entry for the combination because the assessment methodology evaluates risks as discrete items. Attackers do not optimize for individual risk ratings. They optimize for reachable high-value targets.
Risks created by remediation activity itself
ISO 31010 assesses existing conditions. It does not systematically account for risks introduced by the remediation activities it recommends. A control deployment that requires elevated access during implementation, a patch that changes system behavior in a way that affects dependent applications, a configuration change made under time pressure that introduces a new misconfiguration while addressing the rated risk. These are common. They are not in scope for an assessment methodology that evaluates risk at a point in time and treats the remediation cycle as outside its scope.
Third-party and supply chain risks below the visibility threshold
ISO 31010 can in principle address supply chain risk. In practice, the visibility into third-party environments is limited to what the third party discloses through questionnaires and certifications. A supplier with a clean ISO 27001 certificate and a completed security questionnaire appears low-risk in the risk register. What is not visible is whether that supplier has unpatched internet-facing infrastructure, exposed employee credentials in breach databases, or subdomain exposure that signals poor security hygiene. The risk rating reflects disclosed information, not observable external state.
ISO 31010 against ISO 27005 and NIST SP 800-30: what each framework actually asks
ISO 27005
ISO 27005 is specifically scoped to information security risk management within an ISO 27001 context. It provides more prescriptive guidance on asset identification, threat cataloging, and vulnerability assessment than ISO 31010, which is a general-purpose risk assessment standard applicable across any domain. ISO 31010 offers broader technique choice. ISO 27005 offers more structured guidance on what the assessment should cover in an information security context. For organizations managing cyber risk specifically, ISO 27005 produces more directly actionable findings because it asks information-security-specific questions that ISO 31010''s general framework does not require.
Organizations using ISO 31010 as their primary risk methodology for cybersecurity are applying a general-purpose framework to a domain-specific problem. The technique catalog is useful. The absence of information-security-specific scoping guidance means organizations define that scope themselves, which is where the most significant gaps tend to appear.
NIST SP 800-30
NIST SP 800-30 is a risk assessment guide specifically for information systems. It provides explicit guidance on threat source characterization, threat event identification, vulnerability identification, and likelihood determination that ISO 31010 leaves to organizational judgment. 800-30''s likelihood determination guidance distinguishes between threat source characteristics, threat capability, and the presence of exploitable vulnerabilities in a way that ISO 31010''s general likelihood guidance does not require. For technical risk assessments where the primary concern is cyber threat, 800-30''s specificity produces more calibrated likelihood ratings than an ISO 31010 qualitative matrix.
Running an ISO 31010 assessment alongside a NIST 800-30 analysis of the same environment will produce different risk ratings for technical threats because the two frameworks calibrate likelihood differently. The divergence is informative. Understanding why the ratings differ tells you more about your actual exposure than either framework alone.
Where ISO 31010 risk assessment practice is heading
Within three years, a significant regulatory enforcement action will cite an organization''s ISO 31010 risk assessment as evidence of negligence rather than due diligence, on the basis that the assessment methodology was not calibrated against current threat intelligence and produced risk ratings that were demonstrably inaccurate at the time of a breach. This will drive frameworks and regulators to require that risk likelihood estimates be sourced from documented threat intelligence rather than expert judgment alone.
Regulators in financial services and healthcare are already moving toward requiring demonstrable, evidence-backed risk management rather than documented process. The gap between documented risk ratings and actual exposure is wide enough in enough organizations that an enforcement action making that gap explicit is structurally likely. The specific trigger will be a breach where post-incident analysis shows the exploited risk was rated low in a recent formal assessment.
Confidence: mediumIf no major regulatory enforcement action cites risk assessment methodology accuracy as a contributing factor in negligence findings by end of 2027, the prediction is wrong. Early signal: look for regulators beginning to require threat-intelligence sourcing for likelihood ratings in sector-specific guidance documents.Continuous risk monitoring platforms that pull real-time technical data into risk ratings will make point-in-time ISO 31010 assessments obsolete for technical risk categories within five years. Organizations will maintain ISO 31010-compliant documentation for regulatory purposes while operating from continuously updated risk dashboards that their GRC documentation does not reflect. This will create a new category of audit gap: the divergence between the formal risk register and the operational risk picture.
The tooling for continuous technical risk monitoring already exists. The regulatory expectation of documented periodic assessments also exists. As continuous monitoring becomes standard practice, organizations will maintain two parallel risk pictures: the regulatory document and the operational dashboard. The divergence between them will create a new compliance problem that neither ISO 31010 nor current audit methodology is designed to address.
Confidence: highIf ISO 31010 publishes a revision or supplementary guidance addressing continuous monitoring integration before the divergence problem becomes a documented audit finding pattern, the community addressed it proactively. If continuous monitoring vendor adoption continues at current trajectory without regulatory framework adaptation, the divergence problem arrives on schedule.
The 31 techniques are not the problem. The calibration is.
ISO 31010''s technique catalog is genuinely useful. Thirty-one methods covering everything from simple checklists to Bayesian networks gives practitioners real options for matching methodology to problem complexity. The framework''s weakness is not the technique list. It is the absence of calibration requirements. Likelihood estimation is the most consequential input to any risk rating and the one most subject to organizational bias. Teams systematically underestimate the likelihood of attacks they have not personally experienced, overestimate the effectiveness of controls they have recently deployed, and rate risks lower when the control owner is present in the assessment room. ISO 31010 does not require that likelihood estimates be sourced from external threat intelligence, validated against industry incident data, or stress-tested by someone whose job is to find the rated risk exploitable. Until calibration requirements are built into the methodology, risk assessments will continue to produce documentation that reflects organizational belief rather than environmental reality.
Counterargument
The counterargument is that requiring threat-intelligence sourcing for likelihood estimates would make ISO 31010 assessments inaccessible to smaller organizations without dedicated threat intelligence capabilities. That is a real constraint. The response is that uncalibrated likelihood estimates are not conservative estimates. They are organizationally biased estimates that tend to understate technical risk. A smaller organization operating on uncalibrated risk ratings is not making safer decisions from a position of acknowledged uncertainty. It is making confident decisions from inaccurate data. That is a worse position.
One thing to do this week
Take three technical risk items from your current ISO 31010 risk register that are rated low or medium likelihood. For each one, find the most recent industry incident report or threat intelligence source that covers that risk category and check whether the likelihood estimate in your register is consistent with what the external data shows. You do not need a full threat intelligence program to do this. You need three searches and a willingness to update the register if the data does not support the rating. If the ratings hold, you have evidence they are calibrated. If they do not hold, you have found the gap before an attacker does.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
vulnerability assessment servicesNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionOWASP Testing Methodologies
OWASP penetration testing methods
Frequently Asked Questions
What are the most common gaps found in ISO 31010 risk assessments?
The most consistent gaps across Vulnox reviews of ISO 31010 risk registers are: likelihood ratings not calibrated against current threat intelligence; external attack surface excluded from scope; and risk treatment validation absent after controls are deployed. Risks rated as treated are updated based on control deployment, not control effectiveness testing. The result is a risk register that accurately documents what was assessed and misses what was not.
How should likelihood ratings be calibrated in an ISO 31010 assessment?
ISO 31010 does not specify how likelihood estimates should be sourced. In practice, organizations default to expert judgment, which produces estimates biased by organizational experience rather than current threat data. Likelihood calibration should incorporate sector-specific incident data, current threat intelligence on active campaigns targeting the industry, and external observations of the organization's own attack surface. A likelihood rating for ransomware that does not incorporate whether the organization's remote access infrastructure matches known exploitation patterns in active campaigns is not a calibrated estimate.
Why does ISO 31010 miss attack path chaining?
ISO 31010 assesses individual risks. Attack chains combine multiple individually low-rated conditions into a path that produces a high-impact outcome. A staging environment with default credentials, insufficient network segmentation, and a misconfigured firewall rule may each be rated low or medium. Together they create a path to production data. The risk register does not contain an entry for the combination. Identifying chained attack paths requires adversarial analysis of how individually rated conditions connect, which is outside the scope of standard ISO 31010 methodology.
What does ISO 31010 miss about external attack surface risk?
Most ISO 31010 assessments treat the organizational network boundary as the risk assessment boundary. Risks from external exposure, including subdomain enumeration, exposed development infrastructure indexed in Shodan, digital certificate transparency data, and passive reconnaissance value of public-facing assets, are not in scope. An attacker performing reconnaissance does not observe the organization's scoping decisions. In Vulnox assessments, externally visible exposure not captured in ISO 31010 risk registers is a consistent finding.
How is ISO 31010 different from ISO 27005 for cybersecurity risk assessment?
ISO 31010 is a general-purpose risk assessment standard applicable across any domain. ISO 27005 is specifically scoped to information security risk management within an ISO 27001 context and provides more prescriptive guidance on asset identification, threat cataloging, and vulnerability assessment. Organizations using ISO 31010 as their primary methodology for cybersecurity are applying a general framework to a domain-specific problem. The technique catalog is useful. The absence of information-security-specific scoping requirements means organizations define that scope themselves, which is where the most significant gaps tend to appear.
How often should ISO 31010 risk assessments be updated?
ISO 31010 does not specify update frequency. The standard requires monitoring and review of risk treatment effectiveness but does not define how frequently risk ratings should be revalidated against current system state or threat intelligence. In environments with active development, a risk rating can become inaccurate within 90 days of assignment if new code or infrastructure is deployed without a mechanism connecting deployment activity to risk register updates. The 178-day average exposure-to-discovery window in Vulnox client environments means that an annual assessment cycle leaves a significant gap between rated and actual risk for most of the year.
What is the strongest argument against requiring threat intelligence sourcing for ISO 31010 likelihood estimates?
The strongest counterargument is that requiring external threat intelligence sourcing would make ISO 31010 assessments inaccessible to smaller organizations without dedicated threat intelligence capabilities. This is a real constraint. The response is that uncalibrated likelihood estimates are not conservatively uncertain estimates. They are organizationally biased estimates that consistently understate technical risk based on experience and familiarity rather than external data. Operating on confident but inaccurate risk ratings is a worse position than acknowledged uncertainty.
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.