ISO 27001:2022 Annex A Controls: All 93 Across 4 Themes, and What Changed from 2013

What Annex A is, and how ISO 27001 relates to ISO 27002

Annex A is part of ISO/IEC 27001:2022 itself: a reference set of information security controls. It is normative, which means it is the list you are expected to check your own set against. How to implement each control is not covered there. That guidance lives in a separate standard, ISO/IEC 27002:2022, which is guidance rather than a certification requirement.

The distinction drives the order of work. First, risk assessment and risk treatment determine which controls your organization needs; see how to run an ISMS risk assessment. Second, you compare that set against Annex A to confirm nothing was missed. Only then does 27002 become useful, as a source of implementation approaches and examples.

What changed from the 2013 edition: 114 to 93, 14 domains to 4 themes

The 2013 Annex A had 114 controls across 14 domains. The 2022 edition has 93 across 4 themes. The count dropped because overlapping controls were merged, not because the expectations were relaxed. With coarser grouping, each individual control now covers more ground.

The 11 new controls track how work and technology actually changed over the last decade: cloud, remote work, log monitoring and day-to-day engineering practice. They are 5.7 threat intelligence, 5.23 information security for use of cloud services, 5.30 ICT readiness for business continuity, 7.4 physical security monitoring, 8.9 configuration management, 8.10 information deletion, 8.11 data masking, 8.12 data leakage prevention, 8.16 monitoring activities, 8.23 web filtering and 8.28 secure coding. For a company that builds or runs SaaS, most of these already exist in some form. The work is usually describing an existing practice as a control rather than inventing one.

The other change is attributes. Each 2022 control carries five: control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities, and security domains. They exist so you can re-sort and analyse the control set from a different angle. Using them is not itself a requirement.

Organizational controls (5.1 to 5.37)

At 37 items this is the largest theme, spanning policy, roles, supplier management, incident handling and legal compliance. Much of what was spread across several 2013 domains now sits here. It is also the theme that generates the most documentation; for the full picture see required ISMS documents.

People controls (6.1 to 6.8)

Eight controls covering the employment lifecycle. The count is small, but these overlap with employment terms, onboarding and offboarding, so IT cannot own them alone. Remote working now being a control of its own is where practice most often differs from the 2013 edition.

Physical controls (7.1 to 7.14)

Entry management, equipment, storage media and disposal. Even a company with no server room of its own still has office entry, laptops leaving the building, and returns and disposal to account for. Which items apply depends heavily on how you drew your scope.

Technological controls (8.1 to 8.34)

Thirty-four controls, the second largest theme, holding 7 of the 11 new ones. Access control, cryptography, logging, networks and the development life cycle are covered here, and for an engineering organization most of it overlaps with rules you already run.

Using Annex A in the Statement of Applicability

All 93 controls converge in the Statement of Applicability required by clause 6.1.3 d). It is usually built as a 93-row table, with each row carrying the following.

1. Control number and name, with every one of the 93 present as a row
2. Whether the control is applicable
3. Justification for inclusion: which risk treatment led to it, or which legal, contractual or internal requirement did
4. Justification for exclusion, stated in terms of your activities rather than convenience
5. Implementation status, with a pointer to the document or record that evidences it

What auditors tend to probe is whether you can move in both directions between the risk treatment plan and the SoA. A control chosen in treatment but marked not applicable, or marked applicable with no document or record behind it, stands out quickly. Exclusions written as a bare "not applicable" are weak; say why the activity does not occur in your organization.

Whether a control can be excluded follows from the risk assessment. A company that writes no software of its own may reasonably exclude development controls, but if development is outsourced then 8.30 outsourced development comes back into play. The test is not "we do not use it" but "this activity does not occur in our scope".

Controls smaller IT companies often start with

Priority properly comes out of your risk assessment, and there is no universal ordering. That said, as a general pattern, IT companies up to around 100 staff tend to start in the following areas, largely because existing practice already supplies most of the implementation.

• 5.15 / 5.18 / 8.2 access rights and privileged access — starts with a SaaS account inventory and ties into joiner and leaver processes
• 5.9 / 5.10 asset inventory and acceptable use — without knowing what you protect, other controls have no basis to cite
• 5.23 information security for use of cloud services — write down how SaaS is selected, contracted and exited
• 8.8 management of technical vulnerabilities — define the path from detection to patching for dependencies and operating systems
• 8.15 / 8.16 logging and monitoring — begin by deciding who looks at the logs you already collect, and when
• 6.3 awareness, education and training — shape it so an annual record actually exists
• 5.24 to 5.27 incident management — build a reporting path that captures minor events too

Conversely, the heavier early lifts tend to be new controls that may imply tooling, such as 8.11 data masking and 8.12 data leakage prevention. How far these need to go varies sharply with the data you hold, so decide from the risk assessment. For the overall route to certification, see how ISO 27001 certification works.

Managing 93 controls with tooling

The list itself is fine in a spreadsheet. The cost appears when you maintain the links between risks, controls, the SoA, documents and records. Tracing by eye which SoA rows and which documents a single updated risk touches stops being realistic once there are 93 controls in play.

Holding those links in a tool makes the ripple of an update traceable and makes empty justification fields visible. If you first want to see how much of the 93 you can currently explain, start from the ISMS readiness self-check.

This article is for general information only and does not guarantee any audit outcome or certification. Schemes and costs change, so confirm the latest details with certification bodies.