ISO 27001 Controls: Why Annex A’s 93 Aren’t a Checklist

Annex A of ISO/IEC 27001:2022 is the reference set of 93 information security controls, and your next step after scoping is a risk assessment followed by a mapped Statement of Applicability. ISO/IEC 27002 supplies the implementation detail behind each control, while the SoA is the document that proves you chose the right ones for your actual risks. Start by scoping your ISMS, then run a risk assessment and map the necessary controls back to Annex A.

TL;DR:

• Build the Statement of Applicability from a scoped asset inventory and risk assessment; document each Annex A inclusion, exclusion, owner, status, and evidence reference.
• The 2022 edition lists 93 controls, including 11 new ones; compare necessary treatments against all controls, but do not adopt every control by default.
• Add custom or borrowed controls when Annex A misses a specific industry or technical risk, and document their source and rationale in the SoA.
• Auditors test operating controls, so retain dated access reviews, alert reports, training records, vulnerability fixes, incident files, and penetration test results.

Table of Contents

• What Annex A is and why it matters for an ISMS
• What changed in ISO/IEC 27001:2026 and the new controls to know
• The four control categories and what they cover
• Selecting Annex A controls and building a defensible SoA
• Mapping risks to controls: practical patterns for audit readiness
• What auditors look for beyond documentation
• How an integrated provider supports Annex A implementation
• Prioritize controls that reduce real business risk
• How we can help with your ISO 27001 project
• FAQ
• Sources

What Annex A is and why it matters for an ISMS

Annex A is not a standalone standard. It is the control reference embedded inside ISO/IEC 27001:2022, the certifiable standard that sets requirements for an information security management system (ISMS) built on a risk-based approach. Annex A exists so that once you have identified your risks, you have a structured list to check against, confirming you have not missed an obvious safeguard.

Clause 6.1.3 is where Annex A earns its weight. It requires you to compare the controls you determine necessary through risk treatment against the Annex A list, specifically to verify that no necessary control has been overlooked. This is a comparison exercise, not a shopping list: you are not obligated to adopt every control, and you are not limited to only those 93 if your risk picture calls for something else.

That comparison produces the Statement of Applicability, a mandatory document that records which controls you have included, which you have excluded, and why. Auditors treat the SoA as the map of your entire control environment, so it needs to tie every included control to a risk treatment decision and every exclusion to a documented justification.

A few things the SoA must capture:

• Every Annex A control, marked as included or excluded, with a stated reason
• The risk treatment decision that drove each inclusion
• Implementation status and a reference to supporting evidence
• Any custom controls or controls borrowed from other frameworks

Treated this way, Annex A becomes a verification tool rather than a compliance checklist, which is exactly how the auditing practice note on the SoA frames it: blind adoption of every control creates a false sense of security instead of real protection.

What changed in ISO/IEC 27001:2026 and the new controls to know

The 2022 revision cut the Annex A list from 114 controls to 93, not by removing protections but by merging overlapping ones and tightening the language. Compared with the 2013 edition, 11 controls are new, 24 were merged, and 58 were updated, and the whole list now carries a different internal structure.

Each control also gained a set of attributes (control type, security properties, cybersecurity concepts, operational capabilities, and security domains) and a short "purpose" statement that replaces the old grouped objectives. This makes it easier to query controls by theme, useful when you need to show an auditor how a single control supports multiple risk areas at once.

The 11 new controls commonly cited include:

• Threat intelligence, formalizing the gathering and analysis of attack indicators
• Information security for cloud services, addressing shared-responsibility gaps
• ICT readiness for business continuity, separate from general continuity planning
• Physical security monitoring, covering surveillance of premises
• Configuration management, standardizing secure baselines
• Information deletion, governing secure disposal of data no longer needed
• Data masking, protecting sensitive fields in non-production environments
• Data leakage prevention, a dedicated control for outbound data loss
• Monitoring activities, broadening logging beyond isolated event types
• Web filtering, restricting access to malicious or inappropriate sites
• Secure coding, embedding security practices into development lifecycles

Annex A now contains fewer controls than the previous version due to consolidation and merging, maintaining the overall scope, as explained in IAF transition guidance.

Transition guidance for certification bodies puts real weight on verifying that organizations have actually implemented these controls, not just documented them. Auditors moving through transition audits are told to confirm evidence of operation, a theme that carries through every later audit cycle.

The four control categories and what they cover

Annex A groups its 93 controls into four categories: organizational, people, physical, and technological. Knowing the shape of each category helps you spot gaps faster than scanning a flat list of 93 items.

1. Organizational controls (the largest group, around 37 controls) cover governance and process, including policies for information security, roles and responsibilities, supplier relationships, and incident management procedures. A practical example is maintaining an approved supplier security policy that requires vendors to disclose their own control environment before onboarding.
2. People controls (8 controls) address the human element: screening before employment, terms and conditions of employment, disciplinary processes, and security awareness training. An implementation example is running mandatory phishing-simulation training each quarter and logging completion rates as evidence.
3. Physical controls (14 controls) cover the protection of premises and equipment, including secure areas, equipment maintenance, clear desk and clear screen rules, and protection against environmental threats. A workable example is badge-access logging for server rooms paired with a quarterly review of who retains access.
4. Technological controls (34 controls) are the ones most security teams recognize first: access control, cryptography, malware protection, logging and monitoring, network security, and secure development. An example implementation is enforcing multifactor authentication on all privileged accounts and reviewing access logs monthly.

ISO/IEC 27002 expands every one of these titles into implementation guidance, including sample policies and control attributes, and is the document most teams keep open alongside Annex A while building out their SoA. It is not itself certifiable, but it is the practical companion that turns a control title like "access control" into an actual procedure you can hand to an administrator.

Selecting Annex A controls and building a defensible SoA

Control selection follows a sequence, and skipping steps is the most common reason an SoA falls apart under audit scrutiny.

1. Define your ISMS scope. Decide which business units, locations, and systems fall inside the boundary; everything outside it does not need controls documented.
2. Build an asset inventory. List the information assets, systems, and data flows inside scope, since risk assessment without an inventory is guesswork.
3. Run the risk assessment. Identify threats and vulnerabilities against each asset and score likelihood and impact using a consistent methodology.
4. Choose a risk treatment option. For each risk, decide to modify, retain, avoid, or share it, and for modification, identify the control that addresses it.
5. Map to Annex A. Compare your chosen controls against the full Annex A list per Clause 6.1.3, confirming nothing necessary was missed.
6. Document exclusions with reasons. Any Annex A control you are not implementing needs a specific justification tied to your risk assessment, not a blanket statement.
7. Populate the SoA fully. Record control status, the owner responsible, and a reference to the evidence that will demonstrate operation.

Our implementation steps guide walks through this sequence in more depth if you are building a project plan from scratch.

When Annex A does not address a sector-specific or technical risk precisely enough, you are expected to add custom controls or pull language from another framework, then record that source in the SoA alongside your internal control reference. The SC 27 interpretation guidance notes this is a normal and expected practice rather than a deviation from the standard.

Pro Tip: Keep a single owner per control in your SoA; shared ownership is the fastest way for evidence collection to stall before an audit.

Mapping risks to controls: practical patterns for audit readiness

Mapping is where theory turns into a document an auditor can actually follow. A few common risk-to-control patterns illustrate the pattern:

• Data loss maps to access control restrictions and a data leakage prevention control, often paired with encryption at rest and in transit.
• Cloud misconfiguration maps to the cloud services control introduced in the 2022 revision, combined with configuration management and continuous monitoring.
• Privileged account misuse maps to privileged access management, logging of administrative actions, and periodic access review.

A minimal traceability structure keeps these mappings auditable instead of scattered across spreadsheets and emails:

For cloud-specific control selection, our cloud governance guide covers governance patterns across major providers in more detail, and for organizations in regulated sectors managing cloud vendors, this HIPAA-compliant cloud provider guide walks through vendor evaluation criteria worth folding into your control selection.

Legal, contractual, and sectoral requirements should feed directly into this table. If a client contract mandates specific encryption standards or a regulator requires breach notification within a set window, those obligations become inputs to your risk treatment column, not an afterthought layered on top of it.

What auditors look for beyond documentation

Auditors reviewing Annex A controls want to see that controls operate, not just that a policy document describes them. Recent IAF transition guidance for ISO/IEC 27006-1:2024 makes this explicit: audits should move beyond document review and test technological controls directly.

Evidence types that come up repeatedly during audits include:

• Access review logs showing periodic verification of who holds which permissions
• Monitoring and alerting reports demonstrating active log review, not just log collection
• Security awareness training completion records with dates and attendance
• Vulnerability scan results paired with remediation timelines
• Incident handling records showing detection, response, and lessons learned
• Penetration test reports from the most recent testing cycle

Auditors are shifting toward testing operational evidence rather than relying on document-only reviews, a change reflected in current IAF transition documentation. That shift means a control with a well-written policy but no log history behind it is weaker evidence than a thinner policy backed by six months of consistent review records.

To package evidence efficiently for surveillance and recertification audits, keep a running folder per control that maps directly to your SoA row, updated on a fixed cadence rather than compiled under deadline pressure. Tracking corrective actions from internal audits in the same system closes the loop auditors expect to see between finding and remediation.

How an integrated provider supports Annex A implementation

Implementing Annex A controls touches nearly every part of an IT environment, which is why fragmented vendor relationships slow so many ISO 27001 projects down. We built our cybersecurity, cloud, and compliance services to work from the same evidence base, so the access logs our threat detection team reviews are the same records that populate your SoA.

A typical engagement follows the same sequence outlined above: an initial assessment to confirm scope and identify gaps against Annex A, a mapping exercise that ties each necessary control to a specific service (threat detection for monitoring controls, cloud governance for the cloud services control, managed IT for configuration management), implementation support for the controls you lack in-house capacity to build, and ongoing monitoring that generates the evidence auditors request at surveillance audits.

Because compliance, cloud management, and threat detection sit under a single engagement, evidence collection does not depend on reconciling exports from multiple unrelated vendors. Access reviews, vulnerability scan results, and incident records accumulate in one place from day one, which is the detail that tends to save the most time when a recertification audit lands on the calendar.

Prioritize controls that reduce real business risk

The biggest mistake we see in ISO 27001 projects is treating Annex A as a checklist to clear rather than a tool for reducing actual exposure. Ninety three controls implemented badly protect nothing; a smaller set implemented well, with evidence trails intact, gives an auditor and your own leadership something they can trust. Rank controls by the risk they close and the evidence you can realistically sustain, not by how quickly you can mark them complete.

— Nick - Sr. Executive

How we can help with your ISO 27001 project

Scoping an ISMS and mapping 93 controls against your actual risk environment is a heavier lift alone than with a team that has done the mapping before. We bring cybersecurity, cloud governance, and compliance assessment together under one engagement, so the evidence your monitoring generates is the same evidence that populates your Statement of Applicability.

A scoped readiness assessment is the fastest way to find out where your current controls stand against Annex A before an auditor does it for you. That assessment typically surfaces:

• Gaps between your current controls and the 93 in Annex A
• Evidence weaknesses auditors are most likely to flag
• A realistic sequence for closing gaps before a certification audit

If you are planning a certification timeline, our services page outlines the compliance and risk engagements available, and our certification cost guide is a useful companion when you are budgeting the project alongside the technical work. Reach out through our services page to schedule a readiness assessment.

FAQ

What are the 93 controls of ISO 27001?

The 93 controls are the full Annex A reference list in ISO/IEC 27001:2022, organized into organizational, people, physical, and technological categories. You select the controls relevant to your risk assessment rather than implementing all 93 by default.

What are the 11 new controls in ISO 27001?

The 2022 revision added 11 controls covering areas such as threat intelligence, cloud services security, ICT readiness for business continuity, configuration management, data masking, data leakage prevention, and secure coding, among others. These were introduced to address gaps the 2013 edition did not explicitly cover.

What are the four categories under Annex A?

Annex A organizes controls into four categories: organizational, people, physical, and technological. This replaced the longer list of 14 domains used in the 2013 edition, consolidating related objectives under fewer, broader groupings.

What are the mandatory controls of ISO 27001?

There are no universally mandatory Annex A controls; instead, the Statement of Applicability is the mandatory document, and it must justify every inclusion and exclusion based on your risk treatment decisions. The SoA auditing practice note confirms this risk-based approach rather than a fixed control checklist.

How do I know if a custom control is acceptable to an auditor?

Custom controls are acceptable when Annex A does not address a specific risk precisely enough, provided you document the control, its purpose, and the risk it treats in your SoA. Auditors expect this to happen in sector-specific or technical cases rather than as a way to avoid standard Annex A controls.

Sources

• ISO/IEC JTC 1/SC 27 WG1 auditing practice note — SoA
• IAF MD 26 transition requirements for ISO/IEC 27001:2022

Recommended

• Certify Faster: 10 ISO 27001 Implementation Steps for US Teams
• Real US ISO 27001 Certification Costs: Five Steps to a Firm Budget
• Enterprise incident response checklist: 2026 guide