Annex A is the reference list of information security controls in ISO/IEC 27001. In the current 2022 edition it holds 93 controls in four themes: organizational, people, physical and technological. You do not implement all of them by default. You use the list to check your own risk treatment plan, then record what you chose, and why, in a Statement of Applicability (SoA). This guide walks through the structure, the controls, the changes from 2013, and the selection process, so you can go into an audit or a customer security review with a clear picture.
TL;DR
- Annex A is a catalog of 93 controls (2022 edition), down from 114 in the 2013 edition, grouped into organizational (37), people (8), physical (14) and technological (34).
- It is a reference for comparison, not a mandatory checklist: your risk assessment decides which controls you need.
- Clauses 4 to 10 are mandatory management system requirements; Annex A controls are what you select to treat risk inside that system.
- The SoA is the document that lists every control, whether it applies, why, and its implementation status.
- ISO/IEC 27002 explains how to implement each control; certification is only against ISO/IEC 27001.
Table of Contents
- What ISO 27001 Annex A actually is
- The four themes and 93 controls
- What changed from the 2013 edition
- How to choose which controls apply to you
- The Statement of Applicability
- ISO 27002 and Annex A: what is the difference?
- Implementing and monitoring controls day to day
- Why Annex A matters for security questionnaires
- Our perspective
- Put your controls to work with Skypher
- FAQ
- Sources
What ISO 27001 Annex A actually is
ISO 27001 has two halves. The main body, clauses 4 to 10, describes how to build and run an information security management system (ISMS). Annex A sits behind it as a normative list of controls, which are the safeguards you can apply to the risks you find.
The most common misreading is that Annex A is a checklist of 93 things every certified company does. ISO's own auditing guidance says otherwise. Clause 6.1.3 c) asks you to compare the controls you determined as necessary with Annex A and verify that none were omitted, which makes Annex A a comparison reference rather than a mandatory list. Your risk assessment drives the control set. Annex A is the safety net that keeps you from forgetting something.
The annex also has a practical role in how others see you. Because it is a shared vocabulary, customers, auditors and partners can read "we meet control 8.24" or "we have implemented 5.15" and know what you mean. That is why so many security questionnaires are organized around it, a point we return to below.
Annex A versus clauses 4 to 10
Clauses 4 to 10 cover context, leadership, planning, support, operation, performance evaluation and improvement. Every certified organization must meet them in full. Annex A controls, by contrast, are selected based on risk assessment and need not all be implemented.
A simple way to hold the two together:
- Clauses 4 to 10 tell you how to run the management system (the process).
- Clause 6.1.2 asks you to assess information security risks.
- Clause 6.1.3 asks you to choose risk treatments and determine the controls you need.
- Annex A is the list you compare those controls against.
The four themes and 93 controls
The 2022 edition lists 93 controls in four themes. Earlier editions used 14 domains with numbering such as A.9 and A.12. The new structure is simpler and the numbering now runs 5 to 8.
| Theme | Control numbers | Count | What it covers |
|---|---|---|---|
| Organizational | 5.1 to 5.37 | 37 | Policies, roles, asset management, access control, supplier relationships, incident management, compliance |
| People | 6.1 to 6.8 | 8 | Screening, terms of employment, awareness and training, disciplinary process, remote working, event reporting |
| Physical | 7.1 to 7.14 | 14 | Secure areas, entry controls, equipment siting and maintenance, secure disposal |
| Technological | 8.1 to 8.34 | 34 | Endpoint security, privileged access, logging, cryptography, secure development, network security, data masking |
The counts and numbering are confirmed in this theme-by-theme control reference.
Organizational controls (5.1 to 5.37)
This is the largest theme and the one most security questionnaires lean on. It covers information security policies, roles and responsibilities, segregation of duties, threat intelligence, asset inventory and acceptable use, information classification, access control and identity management, supplier security (5.19 to 5.23, including cloud services), incident management (5.24 to 5.28), business continuity, legal and regulatory compliance, and independent review.
If you answer vendor questionnaires, expect most of your questions to map here: "Do you have an incident response plan?" is 5.24 to 5.27, and "How do you manage subprocessors?" is 5.19 to 5.22.
People controls (6.1 to 6.8)
These eight controls deal with the human side: background screening, employment terms, security awareness and training, a disciplinary process, responsibilities after termination, confidentiality agreements, remote working and reporting of security events. They are short, but auditors often test them with evidence such as training records and signed agreements.
Physical controls (7.1 to 7.14)
Physical perimeters, entry controls, securing offices and rooms, monitoring, protection against environmental threats, clear desk and clear screen, equipment siting, security of assets off premises, storage media, utilities, cabling, equipment maintenance and secure disposal. A cloud-first company can often scope many of these to its offices and rely on its hosting providers for data centers, but the decision still needs to be recorded and justified.
Technological controls (8.1 to 8.34)
The technical safeguards: user endpoint devices, privileged access rights, information access restriction, secure authentication, capacity management, malware protection, vulnerability management, configuration management, information deletion, data masking, data leakage prevention, backup, redundancy, logging, monitoring, clock synchronization, network security, web filtering, cryptography, secure development lifecycle, application security requirements, secure coding, security testing, outsourced development, separation of environments and change management.
What changed from the 2013 edition
The 2013 edition had 114 controls in 14 domains. The 2022 revision consolidated overlapping controls to reach 93 and added 11 new ones, reflecting cloud services, secure coding and modern threat conditions. Among the additions are threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23) and secure coding (8.28).
The transition is already behind us. The new standard was published on October 25, 2022, and certifications to the 2013 edition expired or had to be withdrawn by October 31, 2025. If a vendor or customer still quotes A.9 or A.12 numbering in a questionnaire, they are using the old structure, and you will need to map between the two when you answer.
How to choose which controls apply to you
Selection is a risk-driven process, not a shopping exercise. Here is the sequence we recommend.
- Define scope. Decide which products, locations, teams and systems the ISMS covers. Exclusions later must trace back to this scope.
- Assess risks. Identify assets, threats and vulnerabilities, then rate likelihood and impact under clause 6.1.2.
- Choose treatment options. For each risk above your acceptance threshold, decide whether to reduce, avoid, transfer or accept it.
- Determine the necessary controls. Under clause 6.1.3, pick the controls that deliver the treatment. These can come from Annex A or from elsewhere, and organizations may supplement Annex A with other sources such as NIST 800-53 or PCI DSS when needed.
- Compare against Annex A. Check that you have not overlooked a control that your risks actually call for.
- Write the SoA. Record every Annex A control, its applicability, justification and status.
- Get risk owner approval of the treatment plan and residual risks.
A SaaS company with no physical data center, for example, may treat most of the 7.x controls as partly inherited from its cloud providers. A company building software will almost certainly need 8.25 to 8.31 on secure development. Your risk register, not a template, decides.
The Statement of Applicability
The SoA is a mandatory document. It states which controls apply to your scope and which do not, with justifications, implementation status and the supporting measures, documents and processes. Auditors typically begin here because it is the map to everything else.
A workable SoA row has five fields:
| Field | Example |
|---|---|
| Control | 8.24 Use of cryptography |
| Applicable | Yes |
| Justification | Customer data in transit and at rest in the production environment |
| Status | Implemented |
| Evidence | Encryption policy, key management procedure, TLS configuration records |
Three habits keep the SoA credible:
- Justify exclusions carefully. A valid exclusion traces back to assets, technologies or environments that are explicitly out of scope, not to the fact that a control is inconvenient.
- Treat it as a living document. As risks and your environment change, the SoA must be updated to reflect the current security context.
- Never copy someone else's. Reusing another organization's SoA, or last cycle's, without revisiting risks is one of the fastest ways to create inconsistencies and nonconformities.
Keeping the SoA current is easier when someone is watching your cloud environments, assets and threat landscape continuously. Many growing companies bring in managed cybersecurity and compliance support for that ongoing work, and a clear overview of what cybersecurity compliance services cover helps you decide how much to run in-house.
ISO 27002 and Annex A: what is the difference?
Annex A gives you the "what": a concise list of control titles and short statements. ISO/IEC 27002 gives you the "how". ISO 27001 is a normative, certifiable standard, while ISO 27002 is an informative companion with purpose, guidance and best practice for each control.
The 2022 edition of ISO/IEC 27002 also gives each control attributes: control type, information security properties, cybersecurity concepts, operational capabilities and security domains. These are not certification requirements, but they help with mapping and gap analysis. Certification is always against ISO/IEC 27001, not 27002.
Practical rule: use Annex A to decide and document, use 27002 to implement and write procedures.
Implementing and monitoring controls day to day
Selecting a control is the easy part. Operating it with evidence is where audits are won or lost. We suggest four habits:
- Assign an owner to every applicable control. A named person, not a team alias, who can answer questions and produce evidence.
- Write down how the control works in a policy or procedure, using ISO 27002 guidance as your outline.
- Collect evidence as you go: logs, tickets, training records, review minutes. Reconstructing a year of evidence a week before the audit is painful.
- Review on a schedule. Internal audits and management reviews (clauses 9.2 and 9.3) are where you test whether controls still work and whether the SoA still matches reality.
Why Annex A matters for security questionnaires
Once you hold or pursue certification, Annex A becomes the language of your sales cycle. Prospects send questionnaires that map to its controls, and your answers about access control, supplier management, encryption, incident response and secure development all come from the same documentation: your SoA, policies and evidence.
The companies that handle this well keep one accurate source of truth and reuse it. A few things that help:
- Keep your policies and the SoA in a versioned knowledge base so answers stay consistent between questionnaires.
- Tag your answers with the Annex A control they correspond to, so a question phrased in 2013 numbering still finds the right 2022 answer.
- Share your certificate, scope and summary documents through a customer-facing trust page so common requests are answered before they arrive.
We go deeper on how ISO 27001 affects security compliance in tech, on turning the 93 controls into an audit-ready SoA with NIST mapping, and on how to pick between ISO 27001 and SOC 2 in separate guides.
Our perspective
Annex A looks like a compliance exercise, but we see it as a knowledge management problem. Every team that has answered a hundred security questionnaires knows the same facts get typed again and again: how access is reviewed, how incidents are handled, where data is encrypted. Those facts are Annex A controls in plain language.
That is why we built Skypher around a knowledge base that holds your policies, your SoA and your past answers, with document versioning so that what you send always reflects what is current. Our retrieval AI drafts answers from your own content and gives each one a confidence score, so your reviewers spend their time on the answers that need a human eye, not on retyping the ones that do not.
Our advice is to treat the SoA as a living source for sales and security together. When it changes, your questionnaire answers should change with it, and your customers should see the update in your Trust Center.
Gaspard
Put your controls to work with Skypher
Once your controls are documented, the next bottleneck is usually the stream of customer questionnaires that ask about them. Skypher's Questionnaire Automation Tool reads questionnaires in any format, answers from your own knowledge base and connects to the third-party risk platforms and tools your team already uses, including Slack, Microsoft Teams, Confluence, Notion, Google Drive and SharePoint. Teams collaborate in real time, and answers carry a confidence score so reviewers know where to focus.
If you want buyers to find your certificate, scope and security documents without asking, our customizable Trust Center puts them in one place. For plans and a walkthrough, see our pricing page.
FAQ
What is Annex A in ISO 27001?
Annex A is the normative annex of ISO/IEC 27001 that lists the information security controls you compare your risk treatment plan against. The 2022 edition has 93 controls in four themes. You select the ones your risk assessment shows you need and record the decision in your Statement of Applicability.
How many controls are in ISO 27001 Annex A?
There are 93 in the 2022 edition: 37 organizational, 8 people, 14 physical and 34 technological. The 2013 edition had 114 controls in 14 domains. Certificates to the 2013 edition are no longer valid after the transition period ended on October 31, 2025.
Do I have to implement every Annex A control?
No. Annex A is a reference you compare against, and the controls you implement follow from your risk assessment and scope. You must, however, justify every exclusion in the SoA. The management system requirements in clauses 4 to 10, by contrast, apply in full.
What is the difference between ISO 27002 and Annex A?
Annex A is the short list of controls inside ISO 27001. ISO 27002 is a separate guidance standard that explains the purpose and implementation of each control. You certify against 27001 only, and use 27002 to help you implement.
Sources
- ISO/IEC JTC 1/SC 27/WG 1 Auditing Practices Note on Annex A
- ISO 27001:2022 Annex A Explained & Simplified, ISMS.online
- ISO 27001 Controls: All 93 Annex A Controls by Theme, Ironfang
- ISO 27001 Annex A Controls: Who Owns What, Motadata
- Comparing Annex A in ISO/IEC 27001:2013 vs. 2022
- ISO/IEC 27001 Transition: What You Should Know, SGS
- ISMS ISO 27001 Statement of Applicability
- How SMEs Can Write a Clear ISO 27001 Statement of Applicability
- ISO 27001 SoA & Risk Register: Common Mistakes Explained, NQA
- Understanding the difference between ISO 27001 and ISO/IEC 27002
- ISO 27001 Annex A Controls: All 93 Controls Explained