ISO 27001:2022 Mapping: Why Your Statement of Applicability is Probably Failing (and How to Fix It)

1. Introduction: The Silent Killer of Compliance Audits

In my years as a Lead Auditor, I have witnessed more certification dreams die at the hands of sloppy spreadsheets than sophisticated cyberattacks. It is a striking irony of our industry: organizations will spend millions on high-end firewalls and zero-trust architecture, only to fail their audit because of poor paperwork—specifically, flawed control mapping.

The Statement of Applicability (SoA) is the single most important document in your entire Information Security Management System (ISMS). Required by ISO 27001 clause 6.1.3, it is the absolute roadmap for the audit. If your SoA is weak, misaligned, or poorly justified, it doesn't just reflect a documentation error; it signals to the auditor that you don’t truly understand your own risk environment. To a Lead Auditor, a messy SoA is an invitation to dig deeper, effectively opening the floodgates for further findings across your technical controls.

2. Takeaway 1: The End of the Mapping Maze (The 1:1 Revolution)

The 2022 update to the standard introduced a long-overdue "Mapping Revolution." Previously, auditors and compliance managers spent days performing mental gymnastics to map ISO 27001’s Annex A requirements to the detailed implementation guidance in ISO 27002.

The mapping maze is officially dead. In the 2022 version, there is a perfect 1:1 numbering alignment. Control A.5.1 (Policies for information security) in the certification standard is now identical to control 5.1 in the ISO 27002 guidance standard. This follows through the entire set of 93 controls:

• A.6.3 Awareness & training ↔ 6.3
• A.7.2 Physical entry controls ↔ 7.2
• A.8.24 Use of cryptography ↔ 8.24

This alignment is a massive efficiency gain. It shifts the SoA process from a grueling "mapping exercise" to a streamlined "verification exercise." For the organization, it reduces implementation errors; for me, the auditor, it allows for significantly faster audit planning. When the numbers match perfectly, we spend less time navigating your documentation and more time verifying your security.

3. Takeaway 2: The Myth of Missing Controls

A pervasive misconception currently haunting the halls of compliance departments is that the reduction from 114 to 93 controls means the standard has been "watered down." This is a dangerous myth.

Controls were consolidated, not deleted. The coverage of the 2022 version remains entirely intact. However, many organizations are struggling with a psychological "change resistance" during this transition. Moving from 14 granular categories to 4 broader domains requires a shift in how you visualize security. This resistance often leads to the most common audit errors I see today.

⚠ Warning: Common Auditor and Implementer Mistakes Do not fall into the trap of using old ISO 27002:2013 numbering, searching for "missing" controls that have actually been merged, or assuming a control is gone just because its name changed. If you—or your internal auditor—are still looking for the 2013 structure, you are auditing a ghost.

Sticking to the old structure isn't just a technical error; it’s a sign of a stagnant ISMS that hasn't adapted to the modern threat landscape.

4. Takeaway 3: The "Four Pillars" of Modern Information Security

The 2022 update simplified the Annex A structure into four intuitive domains. This is a strategic masterstroke for engaging non-technical stakeholders. It is much easier to explain security ownership when it is divided into these "Four Pillars":

• Organizational Controls (A.5.1 – A.5.37): These focus on your internal policies, roles, and administrative framework.
• People Controls (A.6.1 – A.6.8): This addresses the human element, from the moment of hire through training and offboarding.
• Physical Controls (A.7.1 – A.7.14): This covers the security of your sites, equipment, and tangible entry points.
• Technological Controls (A.8.1 – A.8.34): This is where your technical implementations, like cryptography and network security, reside.

By organizing your SoA around these domains, you make the ISMS intuitive for business owners who previously viewed ISO 27001 as a "black box" of IT requirements.

5. Takeaway 4: Justification is the New Implementation

If there is one thing that triggers a "scorched earth" approach from an auditor, it is the use of lazy justifications. Simply writing "Implemented" in your SoA is not just poor practice—it is an audit failure. As auditors, we are now trained to challenge the logic of both inclusion and exclusion.

A high-quality entry must define the risk addressed and point directly to the artifacts that prove the control exists.

The Contrast in Quality:

• Poor SoA Entry:
• Control: A.8.2 (Privileged access rights)
• Applicable: Yes
• Justification: Implemented.
• Auditor’s View: This is a red flag. I will now scrutinize every single control because I suspect your "implementation" is merely aspirational.
• Good Practice Entry (Audit-Ready):
• Control: A.8.2
• Applicable: Yes
• Justification: Privileged access required for system administration to mitigate unauthorized configuration changes.
• Implementation Reference: Access Control Policy, IAM System, Privileged Access Review Records.
• Auditor’s View: This is defensible. You have identified the risk and pointed me to the evidence before I even asked for it.

6. Takeaway 5: The "Defensible Exclusion" Litmus Test

Every single one of the 93 controls must be accounted for. While you can exclude controls, those exclusions must be "risk-based." You cannot exclude a control simply because it is difficult or expensive to implement. This is what I call a "convenience exclusion," and it will not survive a Lead Auditor’s scrutiny.

The Litmus Test: Valid vs. Invalid Exclusions

• Invalid Exclusion: Excluding Backup (A.8.11) or Malware Protection (A.8.7) with the justification "Not required" or "Not applicable to our business."
• Result: This is almost always a Major Non-conformity. These are fundamental security requirements for almost any modern business.
• Valid Exclusion: Excluding Cryptography (A.8.24) with the justification "No sensitive data processed or stored within the defined ISMS scope."
• Result: This is only defensible if your defined audit scope and risk assessment explicitly support the claim that no sensitive data exists in the environment.

If you cannot provide a logical, risk-based reason for why a control doesn't apply, you are better off marking it as applicable and working toward implementation rather than trying to defend the indefensible.

7. Conclusion: From Static Document to Living Strategy

The Statement of Applicability is not a static checklist to be dusted off once a year for the auditor’s arrival. It is a living reflection of your ISMS maturity. A well-mapped SoA facilitates faster audit planning, ensures your risk treatment is aligned with reality, and gives your leadership team a clear view of the organization's defensive posture.

As you look at your current SoA, ask yourself the hard question: Is this document a legitimate shield that would withstand the scrutiny of a Lead Auditor, or is it just a "convenient" list designed to hide your organization’s hidden risks? If it's the latter, the audit will find you out—and by then, it's too late to fix the paperwork.

Share This Article

Found this useful? Share it with your network: