ISO 27001 Annex A controls, explained

Annex A of ISO 27001:2022 lists 93 reference controls in four themes. You are not required to implement all of them. You are required to decide about all of them, in writing, and defend the decisions in your Statement of Applicability.

Last reviewed 2026-08-16Written by Jacob Masse, TrazTech Inc.

Annex A of ISO/IEC 27001:2022 contains 93 controls, grouped into four themes: 37 organizational controls, 8 people controls, 14 physical controls and 34 technological controls. The 2013 edition had 114 controls in 14 domains, and the renumbering is the change most people notice first. Nothing was really deleted. Controls were merged, a handful were added, and the grouping was rebuilt around who owns the control rather than which chapter it lived in.

The important thing about Annex A is what it is not. It is not a checklist of mandatory requirements. The auditable requirements of ISO 27001 sit in clauses 4 through 10, and clause 6.1.3 is the one that governs Annex A: you determine the controls necessary to treat your risks, then compare that set against Annex A to confirm you have not missed something obvious. Annex A is the completeness check on your own thinking, and the output of that check is the Statement of Applicability.

The four themes and what sits in each

The companion standard, ISO/IEC 27002:2022, holds the implementation guidance for the same 93 controls and tags each one with attributes: control type, which of confidentiality, integrity and availability it protects, the cybersecurity concept it maps to, its operational capability and its security domain. Those attributes are a filtering aid, not a requirement. Buy 27002 if you are implementing. Buying only 27001 and trying to work out from a one-sentence control title what an auditor expects is a false economy of a few hundred dollars.

A.5, organizational controls

This is the largest theme and the one that fails first, because most of it is management work rather than engineering work. It opens with information security policies, roles and responsibilities, segregation of duties, management responsibilities, contact with authorities and with special interest groups, threat intelligence, and information security in project management.

Asset management follows: an inventory of information and other associated assets, acceptable use, return of assets on exit, and the classification, labelling and transfer of information. The inventory control is the one that quietly determines how much work the rest of the project is, because a scope you cannot enumerate is a scope you cannot secure.

Then access control at the policy level: the access control rules themselves, identity management, management of authentication information, and access rights with their provisioning and revocation. The technical implementation of those rules lives in A.8, which is a distinction auditors care about and readiness projects frequently blur.

Supplier security takes five controls covering information security in supplier relationships, what goes into supplier agreements, security through the information and communications technology supply chain, ongoing monitoring and review of supplier services, and information security for use of cloud services. If you run on a public cloud and use a dozen software services, this group is where most of your real risk sits and where most Statements of Applicability are thinnest.

The rest of A.5 covers incident management from planning through assessment, response, learning and collection of evidence; continuity of information security during disruption together with readiness of technology for business continuity; and a compliance block covering legal, statutory, regulatory and contractual requirements, intellectual property, protection of records, privacy and protection of personally identifiable information, independent review of information security, compliance with your own policies, and documented operating procedures.

A.6, people controls

Eight controls, and unusually for Annex A they are close to a complete list in themselves: screening of candidates, terms and conditions of employment, awareness education and training, a disciplinary process, responsibilities that survive termination or change of employment, confidentiality or non-disclosure agreements, remote working, and reporting of information security events.

These are cheap to implement and are among the most commonly failed at stage 2, because the evidence is per person and per hire. An auditor samples five employees and asks for the screening record, the signed agreement and the training completion for each. One missing record in a sample of five is a finding, and it is not a finding you can fix on the day.

A.7, physical controls

Fourteen controls covering physical security perimeters, entry control, securing offices and facilities, physical security monitoring, protection against physical and environmental threats, working in secure areas, clear desk and clear screen, equipment siting and protection, security of assets off-premises, storage media, supporting utilities, cabling security, equipment maintenance, and secure disposal or re-use of equipment.

Fully remote and cloud-hosted organizations assume this whole theme is excludable. It mostly is not, and the reasoning matters more than the outcome. Clear desk and clear screen, security of assets off-premises, storage media handling and secure disposal all apply to a laptop on a kitchen table in Winnipeg. What genuinely goes away is the office perimeter, and the data centre perimeter does not go away either. It moves to your cloud provider and is managed through the supplier and cloud controls in A.5, evidenced by the provider's own certifications rather than by your own guard log.

A.8, technological controls

The largest technical block, and roughly three groups. Access and endpoint enforcement: user endpoint devices, privileged access rights, information access restriction, access to source code, secure authentication. Operations: capacity management, protection against malware, management of technical vulnerabilities, configuration management, information deletion, data masking, data leakage prevention, backup, redundancy, logging, monitoring activities, clock synchronization, use of privileged utility programs, installation of software on operational systems, network security, security of network services, segregation of networks, web filtering, and use of cryptography.

The last ten are the secure development set: secure development life cycle, application security requirements, secure system architecture and engineering principles, secure coding, security testing in development and acceptance, outsourced development, separation of development, test and production environments, change management, test information, and protection of information systems during audit testing.

Two of these controls pull in outside work every time. Management of technical vulnerabilities and security testing in development and acceptance together are why nearly every certified organization holds a recent independent penetration test. The standard never uses the words penetration test, so you can technically satisfy the controls with scanning and internal testing. Auditors read a scan report and an independent test differently, and so do your customers.

The eleven controls that were new in 2022

Eleven controls had no direct predecessor in the 2013 edition, and they are where a certificate carried over from the old version usually has gaps: threat intelligence, information security for use of cloud services, readiness of technology for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding.

The transition period for organizations still certified against the 2013 edition ran to 31 October 2025 and has closed. If you are looking at a certificate that references ISO/IEC 27001:2013, it is not current, and the gap between the two editions is not a paperwork exercise. Configuration management, information deletion and monitoring activities in particular tend to expose real missing practice rather than missing documents.

How the Statement of Applicability works

The Statement of Applicability is required by clause 6.1.3 and it is the single document that ties the risk work to the controls. For every one of the 93 Annex A controls it records four things: whether the control is necessary, the justification for including it, whether it is currently implemented, and the justification for any exclusion. Controls you have determined necessary that are not in Annex A belong there too, because Annex A is a reference set rather than an exhaustive one.

Two practical rules follow from that and they are worth more than any template. First, the justification for including a control should point at a risk or an obligation, not at the control title restated as a sentence. Second, the Statement of Applicability is a living document under change control, and the version an auditor reads at stage 2 has to match what is actually running. A Statement of Applicability that says a control is implemented when it was approved but never turned on is a nonconformity with your own management system, which is worse than an honest partial state.

Which controls actually get excluded

Exclusion is legitimate and expected. What is not legitimate is excluding a control because implementing it is inconvenient, and the test an auditor applies is whether the exclusion follows from the risk assessment and the scope rather than from the budget.

Two exclusions worth avoiding regardless of how defensible they look: cryptography, because almost everything moves over an encrypted channel and the control also covers key management, which is where the real risk is; and screening, which is sometimes dropped citing employment law when what the law actually restricts is the type of check, not the practice of vetting. In both cases a modified implementation described honestly reads far better than an exclusion.

Turning the list into a project

Do not start by reading the 93 controls and grading yourself against them. That produces a spreadsheet nobody uses and a project shaped by the annex instead of by your risks. Start with scope, then the asset and information inventory, then the risk assessment, and only then walk Annex A as the completeness check clause 6.1.3 asks for. The controls that come out of that walk are the ones you can defend.

Budget for the gap work rather than the paperwork. The costs that move most between organizations are logging and monitoring, vulnerability management, and supplier review, and all three are covered on the ISO 27001 cost page in Canadian dollars. If you want someone to run the walk with you, our consultant guide covers how to pick one and, more importantly, why that firm cannot also be your certification body. The certification process page covers what happens once the controls are in place.

Common questions