ISO 27001 Annex A: 93 controls in four themes

Annex A is the catalog of security controls that accompanies ISO 27001. The main body of the standard, Clauses 4 to 10, sets out how to run an information security management system: the context, leadership, risk treatment, operation, and continual improvement. Annex A sits alongside those clauses as a reference list of concrete controls. Clause 6.1.3 is the hinge between the two. It requires you to compare the controls you have chosen against Annex A to confirm you have not missed anything obvious, and to record the result in a Statement of Applicability. So the clauses tell you how to manage security, and Annex A gives you a checklist to test your control selection against.

This distinction matters to a regulated company because it changes what the certificate actually proves. ISO 27001 does not certify that you implemented all 93 controls. It certifies that you run a working management system and that your choice of controls follows from your own risk assessment. A bank, a hospital, and a SaaS vendor can all be certified with very different control sets, because their risks differ. Understanding Annex A correctly, as a catalog you draw from rather than a list of mandatory obligations, is the difference between a security program that holds up under audit and a folder of documents that does not match reality.

This is part of our security program overview. We guide control selection and rollout through governance, risk, and compliance.

What Annex A is, and how it relates to the clauses

Annex A is a normative list of reference controls. It names each control and states its objective in a single line. The detailed guidance on how to implement each control lives in the companion standard ISO/IEC 27002:2022.² When you design a control you work from both: Annex A tells you the control exists and what it is for, and ISO 27002 explains how to put it in place and what to watch out for. The certificate, though, is issued against ISO 27001, and Annex A is part of that standard.

The relationship to the main clauses is precise rather than decorative. Clause 6.1 covers risk assessment and risk treatment. After you identify risks and decide how to treat them, Clause 6.1.3 requires you to produce a Statement of Applicability that lists the necessary controls, justifies their inclusion, records whether they are implemented, and justifies any Annex A controls you have excluded. Annex A is the benchmark you compare your selection against in that step. It exists to stop you from overlooking a whole category of risk, not to dictate that every control applies to you.

This is why people who treat Annex A as a list of requirements get the standard backwards. Nothing in ISO 27001 says you must implement all 93 controls. The standard says you must consider them, select the ones that treat your risks, and explain the rest. A control can be excluded entirely, as long as you can defend why it does not apply. That is what keeps an ISMS proportionate to the organization instead of forcing a ten-person SaaS firm to implement the same physical security controls as a data center operator.

The 2022 revision: 93 controls in four themes

The 2013 version of the standard organized 114 controls across 14 domains. The 2022 revision consolidated and modernized them into 93 controls grouped under four themes.¹ No control category was abandoned; many were merged, a handful were updated, and eleven new controls were added to reflect risks that barely existed in 2013. The reorganization makes the catalog easier to reason about and closer to how security teams actually think about their attack surface.

The four themes replace the older 14-domain structure but keep the same goal: to cover the full surface of information security, not only the technical part. Most teams instinctively reach for the technological controls first, yet many real incidents start with a person, a supplier, or an unguarded door. Grouping the controls this way is a reminder that the organizational and people themes carry as much weight as the 34 technological controls that dominate most security conversations.

The five attributes and the eleven new controls

Alongside the four themes, ISO/IEC 27002:2022 tags every control with five attributes so you can filter and view the catalog from different angles.² The attributes are control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (the five NIST functions: identify, protect, detect, respond, recover), operational capabilities (such as governance, asset management, or identity and access management), and security domains (governance and ecosystem, protection, defence, resilience). These attributes are optional. They do not change which controls exist, but they let a team map Annex A onto other frameworks they already use, such as the NIST Cybersecurity Framework.

The 2022 revision also introduced eleven new controls that did not exist in 2013. They reflect how attack surfaces and operations have shifted over the past decade. They are: threat intelligence (A.5.7), information security for use of cloud services (A.5.23), ICT readiness for business continuity (A.5.30), physical security monitoring (A.7.4), configuration management (A.8.9), information deletion (A.8.10), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23), and secure coding (A.8.28).

• Threat intelligence (A.5.7) expects you to collect and use information about threats relevant to your organization, rather than reacting blind.
• Cloud services security (A.5.23) recognizes that most companies now run critical workloads on third-party platforms and need controls for acquiring, using, and exiting them.
• Data leakage prevention (A.8.12) and data masking (A.8.11) address the exfiltration and exposure of sensitive data, which barely featured in the 2013 catalog.
• Secure coding (A.8.28) brings application security into the core standard, which connects directly to DevSecOps practices.
• Monitoring activities (A.8.16) and web filtering (A.8.23) reflect the move toward continuous detection rather than periodic review.

How controls are selected through risk

The choice of controls follows directly from the risk assessment, and the direction is fixed: controls follow risk, never the other way around. For each risk you have identified and decided to treat, you ask which Annex A controls reduce it and which of those you will implement. If a control does not reduce any risk you face, you exclude it and record why. This is how Annex A connects abstract risks to concrete measures instead of leaving security at the level of good intentions.

1. 01
   Assess your risks

   Identify what the organization is exposed to, how likely each scenario is, and how badly it would hurt. This is the foundation everything else rests on.
2. 02
   Decide risk treatment

   For each risk, decide whether to treat, accept, transfer, or avoid it. Treatment usually means applying one or more controls.
3. 03
   Map risks to Annex A controls

   For each risk you are treating, identify which Annex A controls reduce it. Compare your selection against the full catalog to catch gaps.
4. 04
   Decide applicability

   Confirm which controls you implement, which you exclude, and the justification for each decision.
5. 05
   Document in the SoA

   Record every control, its applicability, its implementation status, and its justification in the Statement of Applicability.

Supplier and cloud risk is a common place where this mapping goes thin. Several organizational controls deal with the security of the relationships and platforms you depend on, so vendor risk management is not a separate exercise bolted on later. It is part of selecting and justifying the right controls from the start. The same applies to the new threat intelligence and cloud controls: they only earn their place in your control set if a real risk points to them.

Sound risk management gives every control a reason to exist and gives every exclusion a defensible explanation.

Recording the choice in the Statement of Applicability

The Statement of Applicability is the document that makes your control selection auditable. For every control in Annex A it records whether the control applies, whether it is implemented, and the justification.¹ It is the bridge between the risk assessment and the controls, and ISO 27001 requires it explicitly under Clause 6.1.3. You cannot certify an ISMS without one. We cover the document in depth in our guide to the Statement of Applicability.

Exclusion is allowed and often misunderstood. Because Annex A is a catalog rather than a list of obligations, a control can be marked as not applicable, as long as the justification is sound. A secure coding control may genuinely not apply to a company that develops nothing in-house. The exclusion is fine. The missing or hand-waved justification is what fails an audit. Sound risk management is what gives each exclusion a reason that survives scrutiny.

How implementation is evidenced

Selecting a control and documenting it is only half the job. An auditor wants evidence that the control operates in practice, not just that it appears in the SoA. A control marked as implemented should point to artefacts that show it working: the access control policy plus the actual access reviews, the secure coding standard plus code review records and pipeline gates, the threat intelligence control plus the feeds you consume and the decisions they informed. Evidence is what separates a control that exists from a control that is only described.

The strongest evidence is generated as a by-product of running the control, not assembled the week before the audit. Logs from monitoring activities, tickets from incident handling, completion records from security awareness training, and change records from configuration management all accumulate naturally when the controls are genuinely in use. When evidence has to be manufactured at the last minute, it usually means the control is not really operating, and experienced auditors recognize the pattern. For technical controls in particular, independent testing such as a penetration test can demonstrate that a control such as access management or network segmentation actually holds.

How Raptoric helps

We connect your risks to the right Annex A controls, build a Statement of Applicability that holds up under audit, and help you produce the evidence that shows each control actually operates, through governance, risk, and compliance. The wider path to the certificate is covered in our ISO 27001 certification guide. Book a scoping call.