Why your ISO 27001:2022 gap analysis is broken before it starts
Geert WarmenbolApril 29, 2026
Key takeaways
61% of organizations that used their ISO 27001 implementation consultant to also run their gap analysis had at least one critical control marked compliant that failed independent technical validation (Vulnox assessment data, 2024).
ISO 27001:2022 reduced Annex A from 114 to 93 controls but added 11 new ones — organizations that haven't updated their Statement of Applicability since 2013 are operating with a document that doesn't map to the standard they're certified against.
A.8.8 (management of technical vulnerabilities) requires a documented, measured patching SLA — 32% of certified organizations Vulnox assessed could not produce evidence of meeting their own stated SLA in the 12 months prior to audit (Vulnox assessment data, 2024).
A.5.7 (threat intelligence) was added in 2022 and is already one of the top three surveillance audit findings — most organizations list it as applicable in their SoA but have no operationalized process behind it.
The average time between a control being marked compliant in a gap analysis and that control failing in a real incident is 14 months, based on post-incident reviews Vulnox has conducted for clients who held valid certifications at the time of breach.
TL;DR
ISO 27001:2022 gap analyses fail for a specific, predictable reason: the firm assessing your gaps usually has a financial interest in what they find. When the same vendor runs your gap analysis and sells you remediation services, compliant-looking gaps are worth more to them than honest ones. The 2022 revision made this worse by adding controls that require operational evidence, not just documentation. If your gap analysis produced no findings that surprised your IT team, it wasn't a gap analysis — it was a sales pitch.
The call that should have been a red flag
A 200-person SaaS company based in Amsterdam closes their ISO 27001:2022 certification in Q3. Clean surveillance audit. Their CISO sends the certificate to three enterprise prospects the same week. Six months later, Vulnox is brought in after a credential stuffing attack compromises 1,400 customer accounts. During the post-incident review, we pull their gap analysis. It was written by the same consultancy that sold them the remediation roadmap and charged for implementation support. A.8.8 — vulnerability management — is marked fully compliant. Their actual patching data shows 47 open critical CVEs at the time of the attack, the oldest 214 days. The control was compliant on paper because the consultant helped them write an SLA they never operationalized. Nobody checked.
The attack didn't happen because the company was negligent in the usual sense. It happened because they outsourced the judgment about their own gaps to someone who was paid not to find them.
The myth: certification means the gap analysis was honest
The myth
The reality
What clients say when the real gaps surface
'Our consultant told us our vulnerability management process was compliant. We had a written SLA and a documented procedure.'
Root cause:A.8.8 requires documented, measured adherence to the SLA — not just a written one. The distinction matters enormously. Having a policy that says critical vulnerabilities will be patched within 30 days is not the same as producing 12 months of evidence that they were. Consultants who assess this control by reviewing the policy document rather than pulling patch cadence data are not assessing it. They are reading a piece of paper and calling it done.
'We listed all 93 Annex A controls as applicable because we weren't sure what to exclude.'
Root cause:This is the single most common SoA failure we see, and it is almost always the result of a consultant who did not push back. Listing all controls as applicable without exclusion rationale does not demonstrate a comprehensive risk-based approach — it demonstrates that nobody performed one. ISO 27001:2022 explicitly requires that exclusions be documented with justification. A surveillance auditor who knows what they are doing will treat a zero-exclusion SoA as evidence of a process failure, not thoroughness.
'We updated to ISO 27001:2022 but our consultant just mapped our existing controls to the new Annex A. We assumed that was sufficient.'
Root cause:The 2022 revision didn't just renumber controls — it added 11 new controls, including A.5.7 (threat intelligence), A.5.23 (information security for use of cloud services), and A.8.16 (monitoring activities). A mapping exercise that takes existing controls and finds the nearest equivalent in the new Annex A will systematically miss these additions. We have reviewed gap analyses that completed a 2013-to-2022 transition and never mentioned A.5.7 once. The control was listed as applicable in the SoA. There was no evidence it existed operationally.
What the assessment data actually shows
Assessment base: Vulnox gap analysis and post-incident review data, 2023-2024, across 47 ISO 27001 certified organizations in the SaaS, fintech, and professional services sectors.
The SoA is wrong in 73% of cases
Of 47 certified organizations we assessed, 34 had a Statement of Applicability that did not accurately reflect their current environment. The most common failure: controls listed as applicable with no operational evidence, and controls that should have been listed as applicable after cloud migration but weren't because the SoA hadn't been reviewed since initial certification.
The SoA is the document a surveillance auditor uses to structure their review. If it doesn't reflect reality, the audit is reviewing a fictional environment. Organizations treat the SoA as a one-time artifact when the standard requires it to be a living document that tracks with the actual risk environment.
A.5.7 threat intelligence is implemented on paper only
Of the organizations that listed A.5.7 as applicable — every organization certified after October 2022 is supposed to — 28 out of 31 could not demonstrate an operationalized threat intelligence process. The typical implementation: a subscription to a threat feed that nobody reads, combined with a policy document that describes a process that doesn't run.
A.5.7 is not a documentation control. It requires that threat intelligence be actively collected, analyzed, and used to inform risk treatment decisions. An RSS feed pointed at a shared mailbox is not a threat intelligence program. This control is going to produce surveillance audit failures at scale over the next 18 months as certification bodies start treating it seriously.
Gap analyses from implementation consultants miss technical controls at 3x the rate of independent assessments
When we compare our findings against existing gap analyses in the same client environment, the gap analyses produced by the client's implementation consultant miss technical control failures at roughly three times the rate we find them. The gap is not random — it concentrates in controls that require technical access to validate: A.8.8 (patching), A.8.20 (penetration testing), A.8.9 (configuration management).
The conflict of interest is real and it is measurable. Consultants who assess gaps they will later be paid to remediate produce assessments that find the remediable. Technical control failures that require operational changes rather than documentation projects are systematically underreported.
How the vendor trap produces compliant-looking failures
The mechanism is not corruption. It is selection pressure operating on every decision a consultant makes during an assessment. A consultant running a gap analysis for a client they want to retain does not consciously decide to miss things. They make dozens of small judgment calls — how deep to go on a control, whether to pull actual technical data or accept the client's description, whether a partial implementation counts as a finding — and on every one of those calls, the path of least resistance is also the path that produces a passable result. Over an engagement, those micro-decisions accumulate into an assessment that looks thorough and consistently arrives at manageable conclusions.
Example
Take A.8.9, configuration management. The standard requires that configurations of hardware, software, and networks be managed. An implementation consultant can assess this by reviewing the client's configuration management policy, asking whether a CMDB exists, and accepting a demonstration of one system as representative. Or they can pull a sample of 20 production instances, compare running configurations against the documented baseline, and count the deviations. The first approach takes two hours and finds nothing. The second approach takes two days and almost always finds something. Consultants who are billing for implementation work after the gap analysis choose the first approach, not because they are dishonest, but because the engagement structure doesn't reward depth.
This is why technical gap analysis requires people who have no downstream stake in the findings. The assessment methodology needs to include mandatory technical sampling — not policy review — for any control in Annex A that can be technically validated. For ISO 27001:2022, that is roughly 40 of the 93 controls in Annex A.
More findings in a gap analysis is not a quality signal
Common belief
A gap analysis that produces 40 findings is more thorough than one that produces 15. Organizations use finding count as a proxy for assessment quality and sometimes prefer consultants who produce more detailed reports.
What we found
In our post-incident reviews, we have never found that the breach vector was a documentation gap. Every incident we have reviewed involved a failed technical control — unpatched system, misconfigured access, unmonitored path. In 9 of the last 11 post-incident reviews where the organization held a valid ISO 27001 certificate, the relevant technical control had been marked compliant or not assessed in the existing gap analysis.
Finding count tells you almost nothing about assessment quality because it is trivially easy to inflate. Documentation gaps — missing policy, outdated procedure, incomplete records — are easy to find in volume and cheap to remediate. A consultant can generate 60 documentation findings in a week and never touch a technical control. Those 60 findings justify a substantial remediation engagement, produce a satisfying closure rate, and leave the organization's actual security posture untouched. The controls that matter — patching SLA adherence, penetration test coverage, access review completeness, change management evidence — require technical depth to assess honestly and produce findings that are harder to remediate. They appear less often in vendor-produced gap analyses not because organizations are stronger there, but because the assessment didn't reach them.
Independent gap analysis vs implementation consultant gap analysis: what you actually get
Implementation consultant gap analysis
Assessment is scoped to what the consultant can observe without specialist technical access. Controls are assessed by reviewing policy and process documentation and accepting client-provided evidence. Technical controls are validated by demonstration, not by independent sampling. Findings concentrate in documentation and process gaps. The SoA is usually reviewed but not technically validated. Timeline is typically 2-4 weeks.
You get a gap analysis that will support your certification effort and find the gaps that are easiest to address. You do not get an honest view of whether your technical controls work. For organizations whose goal is to achieve and maintain certification, this is often sufficient. For organizations whose goal is to understand their actual security posture before a customer audit or an incident, it is not.
Independent technical gap analysis
Assessment includes independent technical sampling for controls that can be technically validated. Patch cadence data is pulled and compared against documented SLA. Configuration baselines are sampled against running state. Access reviews are tested against actual access logs. Penetration test scope is assessed against system inventory. Findings include technical control failures that the organization's existing processes missed. Timeline is typically 4-8 weeks depending on environment size.
You get findings that surprise the IT team. That is not a problem — it is the point. An assessment that produces no findings your people didn't already know about was not an assessment; it was a document review. The value of an independent gap analysis is exactly proportional to the number of things it finds that your existing processes missed. If that number is zero, something went wrong.
The ISO 27001:2022 gaps that almost no one catches before audit
A.5.7 threat intelligence operationalization
Organizations list this control as applicable and point to a threat feed subscription. Auditors in the first wave of surveillance audits (2023-2024) largely accepted this. The next wave won't. A.5.7 requires that threat intelligence be collected, analyzed, and used to inform risk treatment decisions — with evidence of that process. A feed nobody reads is not evidence. Organizations that haven't built an actual process behind this control before their next surveillance audit are going to have a problem.
SoA currency after infrastructure changes
Organizations update their SoA for initial certification and don't touch it again until the next audit cycle. Every cloud migration, every new SaaS tool, every acquired subsidiary changes the control environment. The SoA should be a living document triggered by change management events, not a certification artifact that gets reviewed annually. We have assessed environments where the SoA was 18 months old and the infrastructure it described bore no relationship to what was running.
A.8.16 monitoring activities — the new control nobody operationalized
A.8.16 was added in the 2022 revision and requires that networks, systems, and applications be monitored and anomalies reported. Most organizations have a SIEM. Most SIEMs are not configured to detect the specific anomalies the control requires. Listing a SIEM in the SoA as evidence of A.8.16 compliance is like listing a fire extinguisher as evidence of a fire safety program. The control requires that monitoring produce actionable output that someone reviews. Evidence of that review — tickets, escalations, documented decisions — is what the auditor needs to see.
Supply chain control gaps (A.5.19, A.5.20, A.5.21)
The 2022 revision added three supply chain controls that most organizations implement as a vendor questionnaire program. A questionnaire sent to suppliers is not evidence of information security requirements being established in agreements (A.5.19) or of supplier service delivery being monitored (A.5.21). A 40-person fintech with 60 SaaS tools in their stack, no formal supplier register, and a single annual questionnaire cycle is structurally non-compliant with A.5.19 through A.5.21 regardless of what their SoA says. This is a surveillance audit failure waiting to happen across a large portion of certified SMBs.
Penetration testing scope vs actual attack surface (A.8.20)
A.8.20 requires penetration testing of systems. Most organizations run an annual penetration test and mark this control compliant. The gap: the test scope is usually defined by the organization, not by the actual attack surface. Shadow IT, recently acquired systems, and cloud workloads added since the last test are systematically excluded because nobody updated the scope. We have reviewed penetration test reports where the tested scope covered 30% of the systems that would be reachable from outside. The control was marked compliant. The remaining 70% was not tested.
What is going to break in the next 24 months
A.5.7 will become the most common surveillance audit finding category by Q3 2026.
Certification bodies are now 18-24 months into auditing organizations certified against the 2022 standard. The first cycle accepted thin implementations. The second cycle is tightening. A.5.7 is the control with the largest gap between how it is documented and how it is operationalized. It is also a control where thin implementation is visually obvious to an auditor who asks the right questions: name the threat intelligence source, describe the analysis process, show me the last risk treatment decision that was informed by threat intelligence output. Most organizations cannot answer all three.
Confidence: highPublished certification body surveillance audit finding reports for ISO 27001:2022 show A.5.7 outside the top five findings categories in Q3-Q4 2026.Within 36 months, a significant data breach will be publicly attributed to a certified organization where the breached control was marked compliant in the most recent gap analysis. This will accelerate regulatory pressure on certification body audit methodology.
The structural conditions for this are already present. Certification bodies audit documentation and process. They do not technically validate controls. A growing proportion of certified organizations have gap analyses produced by vendors with conflicts of interest. The probability that a breach occurs in this population, at a control marked compliant, is high — we have already seen this pattern in post-incident reviews that didn't generate public attention. A breach large enough to produce regulatory scrutiny will raise the question of what gap analysis actually means.
Confidence: mediumNo publicly reported breach in a certified ISO 27001:2022 organization is attributed to a control marked compliant in an independent post-incident review through 2027.
The certification model is producing a false sense of security at scale — and the industry knows it
ISO 27001 certification has drifted from a meaningful security signal to a procurement checkbox. That drift was predictable and the industry created it. Certification bodies compete on price and pass rates. Implementation consultants compete on engagement volume. Neither is structurally incentivized to produce hard findings. The result is a market where certification is achievable without meaningful security improvement, and where organizations that complete the process believe they are safer than they are. I have sat in post-incident calls with CISOs who were genuinely shocked that a certified environment had been breached. That shock is the product of a system that told them certification meant something it doesn't.
Counterargument
The counterargument — that ISO 27001 still produces better-documented, more consistently managed security programs than no framework at all — is true and worth taking seriously. Organizations with zero formal security program that go through ISO 27001 certification almost always end up with better controls than they started with. The framework forces documentation, risk assessment, and management review that many organizations were avoiding. That is real value. But it is not the value being sold. The value being sold is security assurance — the ability to tell customers 'we are certified' and have that mean something about actual risk. That claim has become increasingly hollow, and the industry is not fixing it because fixing it would reduce billable engagements.
One thing to do before your next gap analysis
Pull your current SoA and identify every control marked applicable. For each of the following five controls — A.8.8, A.5.7, A.8.16, A.5.19, A.8.20 — find the operational evidence that supports the marking: not the policy document, not the procedure, the actual evidence of the control running. Patch cadence data. Threat intelligence process output. Monitoring alert logs. Supplier agreement clauses. Penetration test scope document. If you cannot produce operational evidence for any of these in 30 minutes, your gap analysis has a gap. That is the finding to take to whoever approved your last assessment — and the question to ask is why it wasn't in the report.
Further Reading
Gap Analysis
ISO 27001 gap analysis servicesDigital Footprint
digital footprint analysisISO framework group: ISO 27001, 27002, 27017, 27018, 27701, 22301, 31000, 42001 and more
ISO 27001:2022 gap analysisISO 27001 Official Standard
ISO 27001 official standardHow to Conduct a Gap Assessment
guide to gap assessmentNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guide
Frequently Asked Questions
How do I know if my ISO 27001:2022 gap analysis was done by a vendor with a conflict of interest?
The clearest signal: the same firm that ran your gap analysis also sold you a remediation roadmap or implementation support. A second signal is finding distribution — if 80% or more of findings are documentation gaps (missing policies, outdated procedures) with no technical control findings, the assessment did not technically validate controls. Ask for the methodology: did the assessor pull actual patch cadence data for A.8.8, or did they review the patching policy? Independent technical gap analyses produce findings that surprise the IT team. If nothing surprised anyone, the assessment did not go deep enough.
What does ISO 27001:2022 A.5.7 threat intelligence actually require?
A.5.7 requires that threat intelligence relevant to the organization be collected, analyzed, and used to inform risk treatment decisions — with evidence of that process. A subscription to a threat feed satisfies none of this without evidence of analysis and use. At a minimum, organizations need a documented process for collecting intelligence from named sources, an analysis step that produces output, and records showing that output was used in at least one risk treatment decision. Surveillance auditors who ask the right questions — name your sources, describe your analysis process, show me the last decision it informed — will distinguish between a real program and a feed subscription.
Why do organizations with valid ISO 27001 certification still get breached?
Because certification validates documented process, not technical control effectiveness. A certification body auditor reviews internal audit records, management review evidence, and risk treatment documentation. They do not run technical tests. An organization can hold a valid certificate while running unpatched systems, misconfigured access controls, and unmonitored network paths — as long as the documentation describes a different environment. In Vulnox post-incident reviews of certified organizations, the breach vector was a failed technical control in every case, and that control had been marked compliant or not assessed in the most recent gap analysis.
What should I check first in an ISO 27001:2022 Statement of Applicability audit?
Start with controls added in the 2022 revision: A.5.7 (threat intelligence), A.5.23 (cloud services), A.8.16 (monitoring), and the supply chain trio A.5.19-A.5.21. If these controls are listed as applicable but you cannot find operational evidence behind each — actual process output, not just a policy — the SoA is decorative. Also check whether the SoA has been updated since any significant infrastructure change: cloud migration, SaaS tool additions, acquisitions. An SoA last reviewed at initial certification is almost always inaccurate within 12 months.
How often should an ISO 27001 gap analysis be repeated?
The standard requires continual improvement, which most organizations interpret as an annual internal audit. That is the minimum. In practice, a gap analysis should be triggered by three events: significant infrastructure change (cloud migration, major new system), a security incident or near-miss, and 12 months prior to a surveillance audit. Waiting for the audit cycle means arriving at surveillance with gaps that accumulated since the last review. Organizations that run gap analyses only on the certification calendar are assessing a fictional snapshot of their environment.
What is the difference between an ISO 27001 internal audit and a gap analysis?
An internal audit verifies that your ISMS is operating as documented — it checks compliance with your own procedures. A gap analysis compares your actual security posture against the requirements of the standard itself. These are different activities that find different things. An internal audit can pass everything and still miss a gap, because it is designed to verify process conformance, not to find places where your documented process doesn't meet the standard. Organizations that substitute internal audits for pre-certification or pre-surveillance gap analyses consistently arrive at external audit with gaps their internal audit missed.
What are the most common ISO 27001:2022 surveillance audit failures?
Based on Vulnox assessment data and post-audit reviews: (1) A.5.7 threat intelligence listed as applicable with no operationalized process behind it; (2) SoA not updated after infrastructure changes; (3) A.8.8 patching SLA documented but not evidenced — the policy exists, the data showing adherence does not; (4) A.8.16 monitoring activities where a SIEM is present but no evidence of reviewed alerts exists; (5) Supply chain controls A.5.19-A.5.21 implemented as annual questionnaires with no contractual requirements or ongoing monitoring.
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.