ISO 27001 controls: the 93 Annex A controls explained

The enterprise security questionnaire asks which ISO 27001 controls you have in place, and procurement wants the answer by Friday. You have a policy folder and a hunch. This guide is for founders and security leads at 25–250-person firms. It explains what the 93 Annex A controls are, which ones you actually need, and how to prove the choice to a buyer or an auditor.

Annex A looks like a 93-item to-do list. It is a reference catalogue, and reading it as a catalogue is what keeps the work in proportion to your business.

What are the ISO 27001 Annex A controls?

The ISO 27001 Annex A controls are a reference catalogue of 93 information security controls, published as an annex to ISO/IEC 27001:2022. Each control is a safeguard that treats a risk, from access control to backup. The main clauses tell you how to run security as a management system; Annex A lists the safeguards that system can draw on.

A control can take several forms. Some are policies, some are processes, some are technical settings and some are physical measures such as door access. Many real controls combine all four: a joiners-and-leavers process is a written rule, an HR workflow and an identity-provider configuration at the same time.

Form is one way to classify a control. Function is another: ISO/IEC 27002 tags every control as preventive, detective or corrective, depending on when it acts on a risk.

Annex A gives each control a name and a short statement of purpose. It does not tell you how to implement it. That guidance sits in a companion standard, ISO/IEC 27002:2022, which explains each control in depth.

The distinction matters when you buy or read anything about ISO 27001. You certify against ISO/IEC 27001. ISO/IEC 27002 is guidance you may use, but no auditor certifies you against it.

Annex A also plays a specific role inside the standard. Under Clause 6.1, you decide how to treat each risk and which controls that treatment needs. You then hold your selection against Annex A as a completeness check, to catch anything you missed. The controls themselves can come from anywhere.

How many controls are in ISO 27001:2022?

ISO 27001:2022 contains 93 Annex A controls, grouped into four themes: 37 organisational, 8 people, 14 physical and 34 technological controls. The 2013 edition listed 114 controls across 14 clauses. Most of the reduction came from merging overlapping controls rather than dropping requirements, so the security ground covered is broadly the same.

The theme tells you roughly who will run each control day to day:

The split is uneven for a reason. Organisational controls cover governance, suppliers, incidents and compliance, which touch every function. Physical controls shrink quickly for a cloud-hosted firm with one office, because the data centre's physical security belongs to your provider.

Do you have to implement all 93 ISO 27001 controls?

No. ISO 27001 requires you to select controls through risk treatment under Clause 6.1.3, then check that selection against all 93 Annex A controls so nothing is missed. Each control is either included, with a reason, or excluded, with a reason. Those decisions, and how far implementation has got, live in your Statement of Applicability.

The order of work matters more than most firms expect. Start from your assessed risks, decide the treatment for each one, and derive the controls that treatment demands. Only then run the Annex A sweep.

Firms that start from Annex A instead tend to build controls no risk asked for. A 30-person software company does not need the same physical perimeter controls as a firm running its own server room.

The Statement of Applicability (SoA) is the record of those decisions. Keep it to one disciplined table with four columns:

• Control: the Annex A reference and name, plus any controls you added from other sources.
• Included or excluded: a clear decision for every one of the 93.
• Justification: the business reason, in a sentence.
• Implementation status: honest progress, including "partially implemented" where that is true.

Exclusions need a reason grounded in the business. "We do no software development, so the secure coding controls do not apply" is a justification. "N/A" is not, and unexplained exclusions are a common audit finding.

An SoA that marks all 93 controls applicable isn't a risk decision. It's the absence of one.

You can also add controls that Annex A does not contain. A firm that handles card payments might add PCI DSS requirements; a cloud-native firm might add CIS Benchmark configurations. Clause 6.1.3 allows controls from any source, so record the extra ones in the SoA alongside the Annex A set. The plan to put the included controls in place is then tracked under Clause 8.3.

What changed in the ISO 27001:2022 controls?

ISO 27001:2022 cut Annex A from 114 controls in 14 clauses to 93 controls in 4 themes. According to IAF MD 26, the accreditation forum's transition rules for ISO/IEC 27001:2022, 11 controls are new, 24 were merged from existing controls and 58 were updated. The management-system clauses changed far less.

The transition window has closed. IAF MD 26 required certification bodies to move every certified client to the 2022 edition by 31 October 2025. All certifications against ISO 27001:2013 expired or were withdrawn at the end of that period.

A supplier certificate that still cites ISO 27001:2013 no longer certifies anything.

The 11 new controls reflect how organisations now work: cloud services, threat intelligence, configuration as code and data leaving through more routes than before.

For most modern firms, several of these were already happening without being written down. Engineering teams usually configure infrastructure as code, run some form of monitoring and review code. The new controls ask you to define, own and evidence that work.

What are ISO 27001 control attributes?

Control attributes are five tags that ISO/IEC 27002:2022 gives every control, so you can sort the 93 controls in different ways for different audiences. They cover control type, information security properties, cybersecurity concepts, operational capabilities and security domains. Attributes are informative only: an auditor will not test them or expect you to use them.

Each attribute answers a different question about the same control:

The cybersecurity concepts come from ISO/IEC TS 27110, a framework for cybersecurity concepts. If your engineers already think in identify, protect, detect, respond and recover, this attribute lets you hand them the controls in their own language.

Treat attributes as a spreadsheet column, not a project. Add them to your control register and filter as needed. Filtering for detective controls tells your on-call team which controls they effectively run, and a security-domain view gives the board a one-page summary.

What are preventive, detective and corrective controls?

Preventive, detective and corrective are the three control types ISO/IEC 27002:2022 uses to describe when a control acts on a risk. Preventive controls stop an incident before it happens, detective controls spot it while it happens, and corrective controls limit the damage and restore normal operation afterwards.

Each type has a clear example in Annex A:

Some controls carry more than one type. A.8.16 Monitoring activities is tagged both detective and corrective, because spotting anomalous behaviour only matters if it triggers a response.

A balanced control set needs all three. Prevention fails eventually, and your detective and corrective controls decide how much that failure costs.

If you have studied other frameworks, you may know a fourth type, directive, for controls such as policies that tell people what to do. ISO/IEC 27002 has no directive category. It tags A.5.1 Policies for information security as preventive.

What is the full ISO 27001 controls list?

The full ISO 27001 controls list runs from A.5.1 to A.8.34: 37 organisational, 8 people, 14 physical and 34 technological controls. The tables below group them by theme, with a short note on what each one is for. Every control links to a GRCMANA guide covering its requirements, implementation and the evidence auditors sample.

Organisational controls (A.5)

Organisational controls set direction, assign responsibility and manage suppliers, incidents and legal obligations. They are the controls most likely to cross team boundaries.

People controls (A.6)

People controls cover the employment life cycle, from screening before someone joins to their duties after they leave.

Physical controls (A.7)

Physical controls protect premises, equipment and media. For cloud-hosted firms, many are partly met by your providers' own certifications.

Technological controls (A.8)

Technological controls cover endpoints, access, networks, monitoring and the software development life cycle. They are where engineering teams will recognise most of their existing practice.

Who should own the ISO 27001 controls?

Every ISO 27001 control you include needs a named owner: a person, not a team, accountable for running the control and producing its evidence. The four themes give a sensible first cut. Technological controls usually sit with engineering or IT, people controls with HR, and physical controls with whoever runs your premises.

Organisational controls need more thought, because they cross functions. A workable split for a firm of 25–250 people looks like this:

• Supplier controls (A.5.19 to A.5.23): operations or procurement, with the security lead setting the standard.
• Incident controls (A.5.24 to A.5.28): the security lead, with engineering on call for response.
• Legal and privacy controls (A.5.31 to A.5.34): whoever owns contracts and data protection.
• Governance controls (A.5.1 to A.5.4, A.5.35 and A.5.36): leadership, because they set direction and check it is followed.

A control owned by "IT" is a control owned by nobody.

Ownership is also where the work gets lighter. Most technological controls already leave a trail in systems you run: your identity provider records access reviews, your CI pipeline records code review and testing, and your ticketing system records changes. When each owner knows which system produces their evidence, the audit sample and the next security questionnaire are answered from the same current records.

For more on the documents each control may need, see our guide to ISO 27001 mandatory documents. To plan the build in phases, start with the ISO 27001 implementation roadmap, or browse the ISO 27001 hub.

Frequently asked questions