ISO 27001 Annex A Controls: The Full List of All 93 Controls

Last updated July 2026. ISO/IEC 27001:2022 Annex A contains 93 controls, grouped into four themes: 37 organizational controls (A.5), 8 people controls (A.6), 14 physical controls (A.7) and 34 technological controls (A.8). The 2013 version had 114 controls across 14 domains, so the count fell while 11 genuinely new controls were added. Annex A is a reference set, not a mandatory checklist: your risk assessment decides which controls apply, and your Statement of Applicability records that decision.

That is the short answer. Below is the complete list of all 93 controls with their official numbers and names, the 11 that are new in the 2022 revision, how the controls relate to the clauses that are actually mandatory, and what an auditor will ask you to produce for each one.

How many controls are in ISO 27001?

There are 93 controls in Annex A of ISO/IEC 27001:2022. The previous 2013 edition listed 114 controls in 14 domains; the 2022 revision merged 57 of them into 24 consolidated controls, kept 58 largely unchanged, and added 11 new ones. The restructure into four themes was about making the set easier to work with, not about lowering the bar. Since the transition deadline of 31 October 2025 has passed, every valid ISO 27001 certificate is now issued against the 2022 standard, so the 93-control set is the only one that matters for a new certification or a surveillance audit.

The full ISO 27001 Annex A controls list

A.5 Organizational controls (37)

A.6 People controls (8)

A.7 Physical controls (14)

A.8 Technological controls (34)

What are the 11 new controls in ISO 27001:2022?

Eleven controls appear in the 2022 Annex A that had no equivalent in 2013. They exist because the threat landscape moved: cloud became the default, ransomware made deletion and backup posture a board topic, and supply chain compromise turned software development into a security control area. These are the ones most likely to produce a nonconformity in a first 2022 audit, because they are the ones most teams never wrote a policy for.

A.5.30 and A.8.16 catch people out more than the rest. Both require you to show something operating rather than something documented. For A.5.30 the certification body wants evidence that recovery of your ICT services has actually been exercised against a stated recovery time objective, and for A.8.16 it wants evidence that anomalies in your systems get detected and looked at. Teams that already monitor the availability of their customer-facing services from outside their own network have half of that evidence generating itself, which is a good deal easier than reconstructing it the week before a stage 2 audit.

ISO 27001 controls and clauses: what is actually mandatory

This is the distinction that trips up most first-time readers. The mandatory part of ISO 27001 is clauses 4 through 10, not Annex A. Clauses 4 to 10 define the management system itself: context, leadership, planning and risk assessment, support, operation, performance evaluation and improvement. You cannot exclude any of them. Annex A is a catalog of controls you draw from when your risk treatment plan says you need one.

Do you have to implement all 93 ISO 27001 controls?

No. You have to consider all 93 and justify any you exclude. Annex A is a reference set, and the Statement of Applicability is where you record, control by control, whether it applies, why, and what implements it. A company with no data center of its own will legitimately exclude several physical controls; a company that writes no software will exclude parts of A.8.25 to A.8.31. What auditors object to is not exclusion, it is exclusion without a documented reason tied back to the risk assessment.

In practice most organizations end up applying somewhere between 70 and 90 of the 93. The controls almost nobody escapes are the access control set (A.5.15 to A.5.18, A.8.2 to A.8.5), logging and monitoring (A.8.15, A.8.16), backup (A.8.13), supplier security (A.5.19 to A.5.22) and incident management (A.5.24 to A.5.28).

How the Statement of Applicability decides which controls apply

The Statement of Applicability, usually just called the SoA, is a required output of clause 6.1.3. For each of the 93 controls it records four things: whether the control is applicable, the justification for that decision, whether it is currently implemented, and what implements it. It is the document a certification body reads first, because it is the map between your risk assessment and everything they are about to test.

The common failure is an SoA that says every control is applicable and implemented, with a one-line justification copied across all 93 rows. Auditors read that as a document written to pass a review rather than to run a security program, and they will pick rows at random and ask for the evidence. A defensible SoA has different justifications for different controls because the risks behind them are different.

What evidence do auditors ask for per control?

For every applicable control, an ISO 27001 auditor wants to see that it is defined, operating and monitored. In practice that means three artifacts: the policy or procedure that defines the control, a record showing it ran during the audit period, and evidence that someone reviews it. An access control claim needs the policy, an actual access review from a recent quarter with the reviewer named, and the tickets showing what was revoked. A claim about A.8.32 change management needs the process, a sample of real change records with approvals, and evidence that emergency changes got reviewed after the fact.

A.6.3 awareness training is the one that catches people out, because the policy is easy and the records are not. An auditor will ask which employees completed security awareness training during the period, when each of them completed it, and how quickly new hires were covered after their start date. Teams that track this in a spreadsheet of forwarded confirmation emails usually cannot answer the second and third questions, which is why the training itself tends to get moved into a system that records completion per employee well before the first certification audit.

The point auditors keep making is that a control implemented last week and a control operating all year look identical in a policy document and completely different in the evidence. Stage 2 audits test operating effectiveness over a period, so evidence has to exist across that period, not on the day you were asked.

Turning the controls list into an audit-ready ISMS

Reading the list is the easy part. The work is mapping each applicable control to the systems and processes that actually satisfy it, then keeping the evidence current between audits. That is where spreadsheets fail: a control matrix maintained by hand goes stale within weeks, and nobody notices that an access review was skipped in the second quarter until an auditor asks for it in the fourth.

ISO 27001 software handles the mapping and the evidence together. It crosswalks your existing controls to the Annex A set, generates and maintains the Statement of Applicability, tracks the risk treatment plan to close, and pulls evidence read-only from your cloud, identity and ticketing systems so each control carries proof it was operating. Gaps surface as they open rather than at the audit. If you also run SOC 2, the overlap is large enough that most of the evidence is shared, which is the argument covered in ISO 27001 vs SOC 2.

One boundary worth repeating: no platform certifies you. Software gets your controls mapped, your SoA defensible and your evidence current, and it shortens the calendar considerably, which is the subject of our breakdown of the ISO 27001 certification timeline. The certificate itself is issued by an accredited certification body after a stage 1 documentation review and a stage 2 audit. Annex A tells you what to build. The auditor decides whether you built it.