ISO 27001 Annex A controls: the 93 controls in 4 themes, grouped the way you will actually implement them

ISO/IEC 27001:2022 Annex A lists 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34). They replaced the 114 controls in 14 clauses of the 2013 edition, and 11 are new. The themes are a filing system, not a work plan. Sorted by the kind of work each needs, the 93 fall into six packages.

This guide covers what Annex A is, what changed from 2013, six work packages and their order, the full list, what Annex A leaves open, and a checklist.

Theme	Annex A numbers	Controls	New in 2022	What it covers
Organisational	5.1 to 5.37	37	3	Policies, roles, assets, access, suppliers, incidents, continuity, legal
People	6.1 to 6.8	8	0	Screening, employment, training, remote work, event reporting
Physical	7.1 to 7.14	14	1	Premises, entry, equipment, media, utilities
Technological	8.1 to 8.34	34	7	Endpoints, authentication, vulnerabilities, backup, logging, networks, development
Total		93	11

What are the ISO 27001 Annex A controls?

Annex A is a reference list of information security controls, each with a number, a title and a short control statement. The numbering, 5.1 to 8.34, follows clauses 5 to 8 of ISO/IEC 27002:2022, which holds the implementation guidance. Auditors cite them as A.5.1 to A.8.34.

It is not a checklist you must complete. Clause 6.1.3 asks you to choose controls that treat your risks and compare them with Annex A so that none is missing. The result is the Statement of Applicability, with a justification for every exclusion. Annex A is not exhaustive, so you can add controls. Justifications are covered in scope and the Statement of Applicability.

What changed from the 2013 Annex A?

The 2013 edition had 114 controls in 14 clauses, A.5 to A.18. The 2022 edition regrouped them into four themes and cut the count to 93, mainly by merging. In BSI’s summary, 58 controls were revised, 24 are merges of older controls and 11 are new.

Certificates against the 2013 edition expired or were withdrawn when the transition period ended on 31 October 2025. Amendment 1:2024 added climate change wording to clauses 4.1 and 4.2 and left Annex A unchanged.

The 11 new controls

Control	Title	Work package
5.7	Threat intelligence	Evidence
5.23	Information security for use of cloud services	Suppliers
5.30	ICT readiness for business continuity	Build
7.4	Physical security monitoring	Record
8.9	Configuration management	Build
8.10	Information deletion	Build
8.11	Data masking	Build
8.12	Data leakage prevention	Build
8.16	Monitoring activities	Build
8.23	Web filtering	Build
8.28	Secure coding	Build

They have no legacy template answer to copy, which is why many Statements of Applicability go vague here. SaaS companies tend to underestimate 5.23: how you choose, use and leave cloud services is most of their infrastructure.

Attributes: a better lens than the themes

ISO/IEC 27002:2022, not ISO 27001, gives every control five attributes: control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities and security domains. In practice, few teams use them. “Every detective control” is a far more useful view than “the physical theme” when you want to know whether you would notice an incident.

In what order should you implement Annex A controls?

The themes tell an auditor where to file a finding, not who does the work, how long it takes or what starts first. Sorted by how a project moves, the 93 fall into six work packages. The counts use the default mapping in the full list below, for a small software or services company.

Work package	What the work is	Controls	Start
1. Record	Write down what already happens, keep records	53	Weeks 2 to 6
2. Decide	Ownership, policy, classification, access rules	5	Weeks 1 to 3
3. Evidence	Recurring activities judged on their history	11	Week 1
4. Build	Engineering and tooling	18	Months 2 to 5
5. Suppliers	Inventory, assess and review third parties	6	Week 1
6. Not applicable	Exclusions with a reason that holds	13 candidates	With the SoA

Packages 3 and 5 start first even though they finish last. That is the whole trick. The month-by-month view is in how long ISO 27001 really takes. For a company with no security function, see ISO 27001 without a security team.

1. Record what you already do

The largest package, and the reason 93 is less frightening than it looks. You already onboard people, remove access when they leave (mostly), take backups and restrict who reaches production. Much of Annex A asks you to record what already happens: a leaver checklist with dates, an access list with a review signature, a backup job with a test result attached. In practice, two weeks of unglamorous documentation clears twenty or more controls.

The trap is a policy that describes an idealised company. If your leaver process is that someone messages the CTO, write that down and improve it, rather than describing an HR workflow you do not have.

2. Decisions only you can make

Few, and they gate everything else. Who owns security (5.2), what the policy commits you to (5.1), where duties are separated (5.3), how you classify information (5.12), the rules for access (5.15). The larger decisions sit in the clauses: scope, risk acceptance criteria and who signs off residual risk.

No consultant or tool can make them. Projects stall because a decision stays open for three months while people write documents around it. A security audit before the programme frames them in weeks.

3. Evidence generators: start these in week one

The package people get wrong, and the mistake is expensive. It holds access reviews (5.18, 8.2), patch records (8.8), restore tests (8.13), logging (8.15), change records (8.32) and training (6.3), among others. Two of the most important are not Annex A controls at all: internal audit and management review, clauses 9.2 and 9.3.

They are judged on whether they have been running for months. In practice auditors expect a history, typically at least three months before Stage 2, and it cannot be manufactured afterwards. So turn them on in week one, before the policies are finished. A quarterly access review that has run twice badly beats one that ran once perfectly the week before the audit.

4. The engineering work

For a software company the real effort sits here, and 17 of the 18 controls are technological. They cover endpoints (8.1), authentication (8.5), configuration (8.9), deletion, masking and leakage prevention (8.10 to 8.12), monitoring (8.16), network segregation and web filtering (8.22, 8.23), cryptography (8.24) and secure development (8.25 to 8.29, 8.31, 8.33). The eighteenth is ICT readiness (5.30).

Eight of the eleven new controls land here. Budget real engineering weeks: no document solves this package, and it competes with your product roadmap.

5. The supplier long tail

Five supplier and cloud controls (5.19 to 5.23) plus outsourced development (8.30) look small. They take the longest calendar time, because every step waits on someone else: inventory, classification, security information, assessment, review cycle. Your vendor list is longer than you think. Start in week one. Under NIS2, the same work covers much of Article 21(2)(d) on supply chain security, as set out in ISO 27001 vs NIS2.

6. The ones you will mark not applicable

If you are cloud-only with no server room, several physical controls do not apply as the standard imagines, or your provider carries them. If you write no software, the development controls fall away. Excluding a control is legitimate. A justification that collapses under one follow-up question is where audits go wrong.

What are the 93 controls in ISO 27001?

Every Annex A control, titled as in ISO/IEC 27002:2022, with a default work package. Treat it as a first draft of your Statement of Applicability, not a verdict: move lines to fit your risk assessment.

ISO/IEC 27001:2022 ANNEX A: 93 CONTROLS BY WORK PACKAGE
D decide  R record  E evidence  B build  S suppliers
+ new in 2022   * often not applicable or carried by a provider

5 ORGANISATIONAL CONTROLS (37)
D   5.1  Policies for information security
D   5.2  Information security roles and responsibilities
D   5.3  Segregation of duties
R   5.4  Management responsibilities
R   5.5  Contact with authorities
R   5.6  Contact with special interest groups
E+  5.7  Threat intelligence
R   5.8  Information security in project management
R   5.9  Inventory of information and other associated assets
R   5.10 Acceptable use of information and other associated assets
R   5.11 Return of assets
D   5.12 Classification of information
R   5.13 Labelling of information
R   5.14 Information transfer
D   5.15 Access control
R   5.16 Identity management
R   5.17 Authentication information
E   5.18 Access rights
S   5.19 Information security in supplier relationships
S   5.20 Addressing information security within supplier agreements
S   5.21 Managing information security in the ICT supply chain
S   5.22 Monitoring, review and change management of supplier services
S+  5.23 Information security for use of cloud services
R   5.24 Information security incident management planning and preparation
R   5.25 Assessment and decision on information security events
R   5.26 Response to information security incidents
E   5.27 Learning from information security incidents
R   5.28 Collection of evidence
R   5.29 Information security during disruption
B+  5.30 ICT readiness for business continuity
R   5.31 Legal, statutory, regulatory and contractual requirements
R   5.32 Intellectual property rights
R   5.33 Protection of records
R   5.34 Privacy and protection of PII
E   5.35 Independent review of information security
E   5.36 Compliance with policies, rules and standards for information security
R   5.37 Documented operating procedures

6 PEOPLE CONTROLS (8)
R   6.1  Screening
R   6.2  Terms and conditions of employment
E   6.3  Information security awareness, education and training
R   6.4  Disciplinary process
R   6.5  Responsibilities after termination or change of employment
R   6.6  Confidentiality or non-disclosure agreements
R   6.7  Remote working
R   6.8  Information security event reporting

7 PHYSICAL CONTROLS (14)
R   7.1  Physical security perimeters
R   7.2  Physical entry
R   7.3  Securing offices, rooms and facilities
R+* 7.4  Physical security monitoring
R   7.5  Protecting against physical and environmental threats
R*  7.6  Working in secure areas
R   7.7  Clear desk and clear screen
R   7.8  Equipment siting and protection
R   7.9  Security of assets off-premises
R   7.10 Storage media
R*  7.11 Supporting utilities
R*  7.12 Cabling security
R   7.13 Equipment maintenance
R   7.14 Secure disposal or re-use of equipment

8 TECHNOLOGICAL CONTROLS (34)
B   8.1  User endpoint devices
E   8.2  Privileged access rights
R   8.3  Information access restriction
R*  8.4  Access to source code
B   8.5  Secure authentication
R   8.6  Capacity management
R   8.7  Protection against malware
E   8.8  Management of technical vulnerabilities
B+  8.9  Configuration management
B+  8.10 Information deletion
B+* 8.11 Data masking
B+  8.12 Data leakage prevention
E   8.13 Information backup
R   8.14 Redundancy of information processing facilities
E   8.15 Logging
B+  8.16 Monitoring activities
R   8.17 Clock synchronization
R   8.18 Use of privileged utility programs
R   8.19 Installation of software on operational systems
R   8.20 Networks security
R   8.21 Security of network services
B   8.22 Segregation of networks
B+  8.23 Web filtering
B   8.24 Use of cryptography
B*  8.25 Secure development life cycle
B*  8.26 Application security requirements
B*  8.27 Secure system architecture and engineering principles
B+* 8.28 Secure coding
B*  8.29 Security testing in development and acceptance
S   8.30 Outsourced development
B*  8.31 Separation of development, test and production environments
E   8.32 Change management
B*  8.33 Test information
R   8.34 Protection of information systems during audit testing

What does Annex A leave open?

Almost every control is written as an outcome, not a standard. That is deliberate: the same list has to fit a three-person startup and a bank. So your Statement of Applicability and your auditor set the bar, not what an attacker would need to get past. Within the letter of the controls:

• Authentication (8.5) asks for secure authentication in line with your access rules. No control requires MFA on every account, and the legacy login everyone still uses is where that difference lives.
• Logging and monitoring (8.15, 8.16) can be met by a documented set-up and a review routine. A log nobody reads is a storage cost, not a control.
• Backup (8.13) is met by backups that run and are tested. A job that reported success is not a system restored end to end under time pressure.
• Vulnerability management (8.8) is measured against your own patch policy. If you wrote quarterly, a critical flaw left in production for eleven weeks is inside your own policy.
• Supplier security (5.19 to 5.22) is met by assessments and periodic reviews on file. Nothing in Annex A requires you to test whether the supplier does what the questionnaire says.

None of that makes the standard useless. It makes it a floor. Run two passes: “does this satisfy the control”, which gets you certified, and “would this stop someone”, which gets you secure. Write down where the answers diverge. That list is short, uncomfortable and worth more than the certificate.

Closing the gap means evidence read from the systems themselves: MFA status from the identity provider, patch age from endpoint tools, restore results from the backup platform. A person reviews what drifts. That is how the CloudSoul platform works, as an automated platform with human-in-the-loop expertise. The full programme is on the ISO 27001 page.

ISO 27001 Annex A checklist

• Build the Statement of Applicability on the 93 controls of the 2022 edition, not the old 114.
• Justify every exclusion so that it survives one follow-up question.
• Switch on access reviews, patch records, restore tests, logging and the supplier inventory in week one.
• Close the open decisions: owner, policy, classification, access rules, scope, risk acceptance.
• Give the new controls, especially 5.23, 8.9 and 8.28, specific answers, not template text.
• Run the second pass: would each control stop someone, and where not, write it down.

Sources

• ISO/IEC 27001:2022, Information security management systems, Requirements, clause 6.1.3 and Annex A, ISO.
• ISO/IEC 27001:2022/Amd 1:2024, Climate action changes, ISO.
• ISO/IEC 27002:2022, Information security controls, clauses 4 to 8 (themes, attributes, control titles), ISO.
• IAF MD 26:2023, Transition requirements for ISO/IEC 27001:2022, IAF.
• BSI, ISO/IEC 27001:2022: what’s changed (114 to 93 controls; 24 merged, 58 revised, 11 new), BSI.

Frequently asked questions