ISO 27001 vs ISO 27002: what the distinction actually means for your audit evidence
Sienna VanceApril 29, 2026
Key takeaways
ISO 27001 defines what your ISMS must do and is the certifiable standard. ISO 27002 defines how to implement the 93 Annex A controls. Conflating them produces certification that does not survive a technical audit or regulatory inquiry.
Organizations can achieve ISO 27001 certification without following ISO 27002 guidance -- and many do. The result is an ISMS with valid documentation and controls that have never been implemented to the standard ISO 27002 describes.
The Statement of Applicability is the document regulators and surveillance auditors focus on. In Vulnox assessments, it is also the document most likely to be out of date in certified environments -- often reflecting the environment at initial certification, not the one that exists now.
ISO 27001 certification does not produce GDPR compliance evidence. The two frameworks address different questions, and regulators under Article 58 GDPR do not treat ISO 27001 certification as a substitute for data processing records or accountability documentation.
Three Annex A controls fail implementation validation most consistently: A.8.8 (technical vulnerability management), A.5.7 (threat intelligence, added in 2022), and A.8.23 (web filtering) -- all marked complete in documentation against evidence that does not meet ISO 27002 guidance.
TL;DR
ISO 27001 and ISO 27002 are not alternatives and they are not redundant. One is the auditable requirement. The other is the implementation guide that makes those requirements real. Organizations that skip ISO 27002 and implement Annex A controls based on their own interpretation end up with certification that looks correct on paper and falls apart when someone asks for implementation evidence. The distinction matters most when something goes wrong.
The certification that held until someone asked how the controls were implemented
A 120-person financial services firm in Singapore had held ISO 27001 certification for three years. Surveillance audits had passed without significant findings. When their largest institutional client conducted a vendor security assessment, they requested the Statement of Applicability along with implementation evidence for the ten controls most relevant to data handling. The SoA was the one produced for initial certification. Three of the controls listed as applicable had implementation notes referencing systems that no longer existed. A.8.8 was listed as implemented with a reference to a patching policy -- no evidence of SLA adherence, no exception log, no scan outputs. A.5.7 threat intelligence was listed as not applicable with the justification that the organization did not operate in a high-threat sector. The client put the contract on hold pending remediation. The ISO 27001 certificate was valid. The implementation it was supposed to represent was not.
This is not a failure of ISO 27001 as a framework. It is a failure to understand what ISO 27001 actually certifies. The standard audits your ISMS structure and your documented processes. It does not validate that your controls work the way ISO 27002 describes them working. Those are different questions, and the difference is invisible until someone asks the second one.
What each standard actually covers
ISO 27001:2022 is organized in two parts. Clauses 4 through 10 define the management system requirements: how the ISMS is governed, how risks are assessed, how objectives are set, how performance is monitored, how nonconformities are handled. This is the certifiable portion. An auditor assessing ISO 27001 compliance spends most of their time here -- reviewing management review records, risk assessment methodology, internal audit outputs, and the documented ISMS scope.
Annex A of ISO 27001 lists 93 controls across four categories: organizational, people, physical, and technological. The standard requires organizations to produce a Statement of Applicability that identifies which controls apply to their environment, which are implemented, and the justification for any exclusions. What ISO 27001 does not do is explain how those controls should be implemented. It states what needs to exist. The how is in ISO 27002.
ISO 27002:2022 maps directly to Annex A. For each of the 93 controls, it provides purpose, implementation guidance, and in many cases other information on the rationale and related controls. It is not a certifiable standard -- you cannot be audited against ISO 27002. But for an organization trying to implement A.8.8 (management of technical vulnerabilities) in a way that would satisfy a technically competent auditor or a regulator, ISO 27002 is where the specificity lives: documented patching timelines, exception processes, evidence requirements, remediation prioritization based on risk.
Example
Consider A.8.8 under both standards. ISO 27001 Annex A states that information about technical vulnerabilities of information systems in use shall be obtained in a timely fashion. That is the requirement. ISO 27002 on the same control describes a patching SLA differentiated by risk rating, a process for evaluating patches before deployment, an exception process with risk acceptance documentation, and evidence that the patching process is operating as documented. An organization that implements A.8.8 by deploying a scanner and running monthly scans has met a plausible interpretation of the ISO 27001 requirement. It has not met the implementation standard ISO 27002 describes. The distinction appears when an auditor asks for the patching SLA and the exception log.
The 2022 revision of both standards reorganized the control structure significantly. ISO 27001:2013 used 114 controls across 14 domains. ISO 27001:2022 uses 93 controls across four categories. Organizations certified against the 2013 version had until October 2025 to transition. The reorganization is not cosmetic -- several controls were merged, new controls were added (including A.5.7 threat intelligence and A.8.23 web filtering), and the attribute tagging system in ISO 27002:2022 allows controls to be filtered by concept, operational capability, and security domain. Organizations that migrated their SoA from 2013 to 2022 by mapping old controls to new ones without reviewing implementation against the updated ISO 27002 guidance have a structural gap in their documentation.
What assessments of ISO 27001 certified environments actually show
Assessment base: Vulnox ISO 27001 gap analysis engagements, 2024, across financial services, SaaS, and professional services clients in Europe and Southeast Asia
SoA currency
In Vulnox assessments of ISO 27001 certified environments, the Statement of Applicability is the document most likely to reflect a past state of the organization rather than the current one. New cloud services, acquired entities, deprecated systems, and changes to data processing activities accumulate between certification cycles without triggering SoA updates. Surveillance audits typically verify that an SoA exists and that it covers the declared scope -- they do not cross-reference it against the current asset inventory or data flow maps.
An SoA that does not reflect the current environment cannot justify the current control selection. Controls marked as not applicable based on a previous environment profile may be applicable now. Controls listed as implemented may reference systems that no longer exist in the form described. The certificate is valid. The assurance it is supposed to provide is not.
Technical control implementation gaps against ISO 27002 guidance
The controls with the largest gap between documented status and implementation quality in certified environments are consistently in the technological category. A.8.8 (vulnerability management) is marked implemented based on scanner deployment rather than demonstrated SLA adherence. A.5.7 (threat intelligence) is either marked not applicable or implemented by subscribing to a threat feed with no evidence of review or integration into risk assessment. A.8.23 (web filtering) is marked applicable with a firewall rule as the implementation evidence, without addressing the content categorization the control describes.
These are not obscure controls. They are among the controls most likely to be tested during a vendor security assessment or a regulatory inquiry. The gap between ISO 27001 certification and ISO 27002 implementation quality is most visible here because these controls have specific, falsifiable implementation criteria.
Management review evidence
ISO 27001 Clause 9.3 requires management review of the ISMS at planned intervals. In many certified environments, management review records exist -- meeting minutes, dated and signed. What they rarely contain is evidence that the review produced decisions: changes to the risk treatment plan, updates to the SoA, resource allocations responding to identified weaknesses. Auditors checking for Clause 9.3 compliance verify that meetings occurred. A technically competent review would ask whether the ISMS changed as a result of them.
Management review that produces records without decisions is a compliance artifact, not a functioning governance process. The difference matters when something goes wrong and a regulator or insurer asks for evidence that senior management was meaningfully engaged in information security oversight.
Why the organizations with older certifications often have weaker implementations
Common belief
An organization that has held ISO 27001 certification for five or more years has a more mature ISMS than one that certified recently.
What we found
In Vulnox gap analysis engagements preceding ISO 27001 recertification, organizations transitioning from 2013 to 2022 certification showed the widest gaps in the newly added controls: A.5.7 (threat intelligence), A.8.9 (configuration management), A.8.10 (information deletion), and A.8.23 (web filtering). These controls did not exist in the 2013 standard, which meant there was no prior implementation to carry forward. They were frequently marked as not applicable in transition SoAs to avoid the implementation work.
Certification age is not a proxy for implementation quality. Organizations that certified under ISO 27001:2013 and maintained surveillance audits through to 2025 often have ISMS documentation that reflects the environment at initial certification, updated incrementally through audit findings rather than through systematic review. The 2022 revision required transition, but many organizations transitioned by mapping old controls to new ones rather than reassessing implementation against the updated ISO 27002:2022 guidance.
Recently certified organizations, by contrast, often completed a structured gap analysis against ISO 27001:2022 and ISO 27002:2022 simultaneously, producing control implementations that reflect current guidance. Their SoA is more likely to be current because the certification process forced them to build it from scratch against the 2022 control set.
The counterintuitive pattern in assessments: long-certified organizations often have strong process documentation and weak technical control implementation. Recently certified organizations often have the reverse.
ISO 27001 and ISO 27002 side by side on the questions that matter operationally
What does each standard require for vulnerability management?
ISO 27001 Annex A requires that technical vulnerability information be obtained and acted on. ISO 27002 specifies a patching SLA differentiated by risk rating, an exception process, evidence of SLA adherence, and a remediation prioritization methodology. One is a requirement. The other is what satisfying that requirement looks like.
An organization implementing A.8.8 based on ISO 27001 alone will typically deploy a scanner and write a patching policy. An organization implementing against ISO 27002 guidance will have a documented SLA (e.g., critical vulnerabilities patched within 72 hours, high within 14 days), an exception log with risk acceptance signatures, and scan output demonstrating adherence. The first passes most surveillance audits. The second passes a vendor assessment by a security-mature client.
How does each standard address threat intelligence?
A.5.7 was introduced in ISO 27001:2022. The control requires that information relating to information security threats be collected and analyzed. ISO 27002 on A.5.7 describes sources of threat intelligence, integration into risk assessment, and the process for acting on threat intelligence findings. ISO 27001 alone gives organizations enough room to mark the control implemented by subscribing to a vendor threat feed.
A.5.7 is the control most frequently marked not applicable or implemented with minimal evidence in transition SoAs. The ISO 27002 guidance makes it difficult to mark as genuinely implemented without a documented process for reviewing threat intelligence and integrating findings into the risk assessment cycle. Organizations that skip the ISO 27002 guidance here have a control that will fail scrutiny if a breach occurs and a post-incident review asks how the organization was monitoring the threat environment.
What evidence does each standard produce for a GDPR regulator?
ISO 27001 produces ISMS documentation: risk assessments, SoA, management review records, internal audit outputs. ISO 27002 produces control implementation evidence: configurations, process records, testing outputs. GDPR regulators under Article 58 inquiries ask for processing activity records, data flow documentation, and evidence of appropriate technical measures. Neither standard directly produces this, but ISO 27002 implementation evidence is closer to what a regulator characterizes as appropriate technical measures.
ISO 27001 certification is relevant as background evidence of an information security program. It is not a substitute for GDPR accountability documentation. Organizations that cite ISO 27001 certification in response to a GDPR inquiry will be asked for the underlying control evidence -- at which point the quality of ISO 27002 implementation becomes the determinative factor.
What neither standard addresses that regulators and assessors will ask about
Data residency and cross-border transfer controls
ISO 27001 and ISO 27002 address information security, not data protection law. Neither standard contains controls specific to data residency obligations, cross-border transfer mechanisms under GDPR Chapter V, or the equivalent provisions under Thailand PDPA or Singapore PDPA. Organizations operating across jurisdictions with ISO 27001 certification may have no ISMS controls addressing where data is processed or stored, because the standard does not require them. This gap appears in vendor assessments conducted by clients subject to data localization requirements and in regulatory inquiries following a cross-border data incident.
Third-party and supply chain risk beyond initial assessment
ISO 27001 Clause 8.1 and Annex A A.5.19 through A.5.23 address supplier relationships and supply chain security. The implementation gap is almost always in ongoing monitoring rather than initial due diligence. Organizations conduct supplier assessments at onboarding, document the results in their ISMS, and then conduct annual questionnaire reviews. What ISO 27002 describes for A.5.19 includes monitoring supplier performance against agreed security requirements and acting on findings. In practice the monitoring process produces questionnaire responses that are filed, not security assurance that is validated. The SoA marks the control implemented. The control is not functioning as described.
Incident response testing and tabletop exercises
ISO 27001 Annex A A.5.26 and A.5.24 address information security incident management. They require documented procedures for detection, reporting, assessment, response, and learning from incidents. What they do not require, and what ISO 27002 guidance does not strongly emphasize, is that these procedures be tested under realistic conditions before an incident occurs. In Vulnox assessments, incident response plans exist in virtually every ISO 27001 certified environment. In most, they have not been exercised against a scenario resembling an actual attack. The plan covers the process. It does not establish whether the process works.
Where the ISO 27001 and ISO 27002 relationship is heading
Within three years, ISO 27001 surveillance audits will begin requiring implementation evidence against ISO 27002 guidance for a defined subset of high-risk controls, driven by pressure from certification bodies responding to high-profile breaches at certified organizations. The current distinction between 'certification standard' and 'implementation guidance' will narrow in practice even if it remains formally intact.
Certification bodies are aware that ISO 27001 certification is appearing in breach disclosures. Several high-profile incidents at ISO 27001 certified organizations have prompted questions about what the certification actually demonstrates. The reputational risk to the certification ecosystem creates incentive for accreditation bodies to strengthen audit methodology. The most likely mechanism is a change to audit guidance rather than a change to the standard itself -- which would require a full revision cycle.
Confidence: mediumWatch for IAF (International Accreditation Forum) or ISO/IEC JTC 1/SC 27 guidance documents between 2026 and 2028 that specify implementation evidence requirements for named Annex A controls. If no such guidance emerges and audit methodology remains unchanged, the prediction is wrong.The gap between ISO 27001 certification and regulatory evidence requirements will produce a new category of compliance failure: organizations that pass certification audits and fail regulatory inquiries on the same ISMS documentation. This will be most visible in Southeast Asia as PDPA enforcement in Thailand and Singapore matures.
Thailand PDPA enforcement began in 2022. Singapore PDPA enforcement has accelerated. Both regulators have authority to request evidence of appropriate security measures, and neither treats ISO 27001 certification as a complete response. As enforcement activity increases and organizations discover that their certification documentation does not satisfy data protection inquiries, the gap between ISO 27001 and regulatory evidence standards will become a documented compliance failure mode rather than a theoretical risk.
Confidence: highMonitor PDPC (Singapore) and PDPC (Thailand) enforcement decisions from 2026 onward. If published decisions begin citing ISO 27001 certification as partial but insufficient evidence of appropriate measures, the prediction is confirmed. If regulators begin treating certification as dispositive, it is wrong.
The question organizations should be asking but are not
Most organizations approaching ISO 27001 certification are asking the wrong question. They ask: what do we need to document to get certified? The question that produces an ISMS with actual value is: what evidence would we need to produce if we had a breach, a regulatory inquiry, or a client security assessment tomorrow, and does our ISMS generate that evidence as a byproduct of normal operation?
ISO 27002 is the guide to building an ISMS that answers the second question. It is detailed, occasionally tedious, and operationally demanding. Most organizations skip it or treat it as optional commentary on a certifiable standard. The ones that implement against it rather than around it end up with control evidence that holds up when someone looks closely. The ones that do not end up with the Singapore fintech situation described at the start of this article: a valid certificate and nothing behind it.
The counterargument is that ISO 27002 guidance exceeds what most small and mid-market organizations can operationally sustain, and that demanding full implementation creates compliance programs so resource-intensive that organizations abandon them entirely in favor of nothing. That is a real concern and it is worth taking seriously.
Counterargument
The risk of setting ISO 27002 implementation as the standard is that it creates a ceiling most organizations cannot reach, and organizations that cannot reach it may conclude that any partial implementation is not worth pursuing. A partial ISMS implemented against ISO 27001 alone is better than no ISMS. The goal of the framework ecosystem is adoption, not perfection. ISO 27002 as mandatory implementation guidance would reduce certification rates without necessarily producing better security outcomes across the full population of organizations.
One thing to do this week
Pull your Statement of Applicability and identify the last time it was substantively reviewed -- not the date on the document, but the last time someone compared it against your current asset inventory, data processing activities, and technology stack. If that review has not happened in the past 12 months, the SoA is describing an ISMS you no longer have. Pick three controls in the technological category -- A.8.8, A.5.7, and one other -- and ask whether the implementation evidence you hold would satisfy the ISO 27002 guidance for that control or just the ISO 27001 requirement. The gap between those two answers is your actual compliance risk.
Further Reading
ISO
ISO framework questionnaireDigital Footprint
digital footprint analysisISO framework group: ISO 27001, 27002, 27017, 27018, 27701, 22301, 31000, 42001 and more
ISO 27001 vs ISO 27002 differencesISO 27001 Official Standard
ISO 27001 official standardISO 27001 Compliance Guide 2025
ISO 27001 compliance guideOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
What is the practical difference between ISO 27001 and ISO 27002 for a compliance team?
ISO 27001 is the certifiable standard -- it defines the requirements for an ISMS and is what your auditor assesses against. ISO 27002 is implementation guidance -- it describes how to apply the 93 controls listed in Annex A of ISO 27001. You can be certified to ISO 27001 without following ISO 27002, but your Statement of Applicability will lack the control implementation detail auditors increasingly expect. The practical problem: ISO 27001 tells you that A.8.8 (management of technical vulnerabilities) must be addressed. ISO 27002 tells you what a credible patching SLA, exception process, and evidence trail actually look like. Without the second, the first produces documentation that does not hold up under scrutiny.
Can you get ISO 27001 certified without implementing ISO 27002 controls?
Yes, and many organizations do. ISO 27001 certification requires demonstrating a functioning ISMS against Clauses 4 through 10 and justifying your control selections in the Statement of Applicability. It does not require following ISO 27002 guidance. The consequence is that organizations certified this way often have an ISMS that satisfies the structural requirements of ISO 27001 while implementing controls in ways that would not survive a technical audit or a regulator asking for specific evidence. In Vulnox assessments, the most common finding in ISO 27001 certified environments is a valid SoA paired with controls that have never been validated against the implementation guidance in ISO 27002.
What does an ISO 27001 auditor actually ask for that most organizations are not prepared to provide?
Three things come up consistently. First, evidence that the SoA is current -- not the version from initial certification, but one reviewed and updated after material changes to the environment. Second, implementation evidence for technical controls, specifically A.8.8 (vulnerability management): a documented patching SLA, evidence of adherence to it, and a process for exceptions with risk acceptance. Third, evidence that management review meetings produced decisions, not just minutes. Auditors increasingly distinguish between documented processes and operating processes. The gap between them is where most certification renewals encounter difficulty.
How often should an ISO 27001 Statement of Applicability be updated?
ISO 27001 requires the SoA to reflect the current control selection and justification for inclusions and exclusions. In practice it should be reviewed whenever the organization makes material changes: new services, new data processing activities, significant infrastructure changes, or changes to the threat environment. In Vulnox assessments of ISO 27001 certified environments, the SoA is the document most likely to be out of date. Certification surveillance audits often pass with a stale SoA because the auditor is checking that one exists -- a full recertification audit or a regulatory inquiry is where the gap becomes visible.
What is the relationship between ISO 27001 and GDPR evidence requirements?
ISO 27001 certification does not demonstrate GDPR compliance, and regulators under Article 58 GDPR do not treat it as equivalent. What ISO 27001 certification does produce -- if the ISMS is implemented seriously -- is a documented risk management process, a record of control decisions, and evidence of management accountability, all of which are relevant to demonstrating compliance with Article 5(2) GDPR (accountability principle). The gap is that ISO 27001 does not require data flow documentation, processing activity records, or data subject rights procedures. An organization can hold a valid ISO 27001 certificate and still have no credible response to a GDPR subject access request inquiry.
Which ISO 27001 Annex A controls are most commonly implemented incorrectly?
A.8.8 (management of technical vulnerabilities) fails most often because organizations interpret it as deploying a scanner, not as maintaining a documented patching SLA with evidence of adherence. A.5.7 (threat intelligence) was added in the 2022 revision and is rarely implemented beyond subscribing to a threat feed that nobody reviews. A.8.23 (web filtering) is frequently marked applicable with a firewall rule as evidence, without addressing the content categories the control actually requires. A.6.7 (remote working) is marked complete based on a policy document rather than validated technical controls for remote access security.
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.