---
title: "ISO 27001 controls: the 93 Annex A controls explained"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-controls
published: 2023-08-25
updated: 2026-10-08
author: "Harry West"
framework: "ISO 27001"
control: "Guide ISO 27001 Annex A controls"
journeyStage: fundamentals
---

# ISO 27001 controls: the 93 Annex A controls explained

## Key takeaways

ISO 27001:2022 Annex A lists 93 controls in four themes: organisational, people, physical and technological. You do not implement all of them by default. You select controls through risk treatment, check the selection against Annex A, and record every inclusion and exclusion, with reasons, in your Statement of Applicability.

- **Control count** — Annex A holds 93 controls: 37 organisational, 8 people, 14 physical and 34 technological. The 2013 edition had 114 controls spread across 14 clauses.
- **Selection rule** — Controls are chosen to treat assessed risks, then checked against all 93 so nothing is missed. An exclusion needs a one-sentence business reason, never a bare "N/A".
- **2022 changes** — IAF MD 26 counts 11 new controls, 24 merged and 58 updated. Every certificate issued against ISO 27001:2013 expired or was withdrawn after 31 October 2025.
- **Control attributes** — ISO/IEC 27002:2022 tags each control with five attributes, such as control type and cybersecurity concept. They help you sort and report on controls, and auditors do not test them.

**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](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities), 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:

| Theme | Annex A section | Controls | Usual home in a 25–250-person firm |
| --- | --- | --- | --- |
| Organisational | A.5 | 37 | Shared across leadership, security, operations, legal and procurement |
| People | A.6 | 8 | HR, with legal for contracts and confidentiality |
| Physical | A.7 | 14 | Whoever runs the office, plus your hosting providers' assurances |
| Technological | A.8 | 34 | Engineering and IT |

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](https://www.grcmana.io/vault/iso-27001/clause-8-3-information-security-risk-treatment).

## 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](https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf), 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.

| New control | What it adds |
| --- | --- |
| [A.5.7 Threat intelligence](https://www.grcmana.io/vault/iso-27001/annex-a-5-7-threat-intelligence) | Collecting and using information about threats relevant to you |
| [A.5.23 Information security for use of cloud services](https://www.grcmana.io/vault/iso-27001/annex-a-5-23-information-security-for-use-of-cloud-services) | Managing security across the life of each cloud service you use |
| [A.5.30 ICT readiness for business continuity](https://www.grcmana.io/vault/iso-27001/annex-a-5-30-ict-readiness-for-business-continuity) | Making sure technology can recover in line with continuity goals |
| [A.7.4 Physical security monitoring](https://www.grcmana.io/vault/iso-27001/annex-a-7-4-physical-security-monitoring) | Watching premises for unauthorised physical access |
| [A.8.9 Configuration management](https://www.grcmana.io/vault/iso-27001/annex-a-8-9-configuration-management) | Defining, applying and monitoring secure configurations |
| [A.8.10 Information deletion](https://www.grcmana.io/vault/iso-27001/annex-a-8-10-information-deletion) | Deleting information once it is no longer needed |
| [A.8.11 Data masking](https://www.grcmana.io/vault/iso-27001/annex-a-8-11-data-masking) | Hiding sensitive data, especially personal data, where full values are not needed |
| [A.8.12 Data leakage prevention](https://www.grcmana.io/vault/iso-27001/annex-a-8-12-data-leakage-prevention) | Detecting and stopping unauthorised data leaving the organisation |
| [A.8.16 Monitoring activities](https://www.grcmana.io/vault/iso-27001/annex-a-8-16-monitoring-activities) | Watching systems for anomalous behaviour and acting on it |
| [A.8.23 Web filtering](https://www.grcmana.io/vault/iso-27001/annex-a-8-23-web-filtering) | Controlling access to external websites to reduce exposure |
| [A.8.28 Secure coding](https://www.grcmana.io/vault/iso-27001/annex-a-8-28-secure-coding) | Applying secure coding principles in software development |

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:

| Attribute | Values | Useful for |
| --- | --- | --- |
| Control type | Preventive, detective, corrective | Checking you do not rely only on prevention |
| Information security properties | Confidentiality, integrity, availability | Linking controls to what customers' contracts promise |
| Cybersecurity concepts | Identify, protect, detect, respond, recover | Talking to teams who think in incident lifecycle terms |
| Operational capabilities | Practitioner areas such as governance, asset management, and identity and access management | Routing controls to the team that will run them |
| Security domains | Governance and ecosystem, protection, defence, resilience | Summarising coverage for the board |

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:

| Control type | What it does | When it acts | Annex A example |
| --- | --- | --- | --- |
| Preventive | Stops an incident from happening | Before | [A.8.5 Secure authentication](https://www.grcmana.io/vault/iso-27001/annex-a-8-5-secure-authentication) |
| Detective | Spots an incident or anomaly as it happens | During | [A.8.16 Monitoring activities](https://www.grcmana.io/vault/iso-27001/annex-a-8-16-monitoring-activities) |
| Corrective | Limits the damage and restores normal operation | After | [A.8.13 Information backup](https://www.grcmana.io/vault/iso-27001/annex-a-8-13-information-backup) |

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.

| Control | What it is for |
| --- | --- |
| [A.5.1 Policies for information security](https://www.grcmana.io/vault/iso-27001/annex-a-5-1-information-security-policy) | Approved, communicated security policies |
| [A.5.2 Information security roles and responsibilities](https://www.grcmana.io/vault/iso-27001/annex-a-5-2-information-security-roles-and-responsibilities) | Clear security duties for named roles |
| [A.5.3 Segregation of duties](https://www.grcmana.io/vault/iso-27001/annex-a-5-3-segregation-of-duties) | No single person controls a risky task end to end |
| [A.5.4 Management responsibilities](https://www.grcmana.io/vault/iso-27001/annex-a-5-4-management-responsibilities) | Managers require staff to follow security rules |
| [A.5.5 Contact with authorities](https://www.grcmana.io/vault/iso-27001/annex-a-5-5-contact-with-authorities) | Knowing who to call, such as regulators or the police |
| [A.5.6 Contact with special interest groups](https://www.grcmana.io/vault/iso-27001/annex-a-5-6-contact-with-special-interest-groups) | Staying connected to security communities |
| [A.5.7 Threat intelligence](https://www.grcmana.io/vault/iso-27001/annex-a-5-7-threat-intelligence) | Using threat information to inform decisions |
| [A.5.8 Information security in project management](https://www.grcmana.io/vault/iso-27001/annex-a-5-8-information-security-in-project-management) | Building security into projects from the start |
| [A.5.9 Inventory of information and other associated assets](https://www.grcmana.io/vault/iso-27001/annex-a-5-9-inventory-of-information-and-other-associated-assets) | An owned register of information and assets |
| [A.5.10 Acceptable use of information and other associated assets](https://www.grcmana.io/vault/iso-27001/annex-a-5-10-acceptable-use-of-information-and-other-associated-assets) | Rules for how staff use information and equipment |
| [A.5.11 Return of assets](https://www.grcmana.io/vault/iso-27001/annex-a-5-11-return-of-assets) | Getting assets back when people leave |
| [A.5.12 Classification of information](https://www.grcmana.io/vault/iso-27001/annex-a-5-12-classification-of-information) | Grading information by sensitivity |
| [A.5.13 Labelling of information](https://www.grcmana.io/vault/iso-27001/annex-a-5-13-labelling-of-information) | Marking information with its classification |
| [A.5.14 Information transfer](https://www.grcmana.io/vault/iso-27001/annex-a-5-14-information-transfer) | Protecting information when it is shared |
| [A.5.15 Access control](https://www.grcmana.io/vault/iso-27001/annex-a-5-15-access-control) | Rules for who may access what |
| [A.5.16 Identity management](https://www.grcmana.io/vault/iso-27001/annex-a-5-16-identity-management) | Managing identities through their life |
| [A.5.17 Authentication information](https://www.grcmana.io/vault/iso-27001/annex-a-5-17-authentication-information) | Handling passwords and other secrets safely |
| [A.5.18 Access rights](https://www.grcmana.io/vault/iso-27001/annex-a-5-18-access-rights) | Granting, reviewing and removing access |
| [A.5.19 Information security in supplier relationships](https://www.grcmana.io/vault/iso-27001/annex-a-5-19-information-security-in-supplier-relationships) | Managing risk from suppliers |
| [A.5.20 Addressing information security within supplier agreements](https://www.grcmana.io/vault/iso-27001/annex-a-5-20-addressing-information-security-within-supplier-agreements) | Security terms in supplier contracts |
| [A.5.21 Managing information security in the ICT supply chain](https://www.grcmana.io/vault/iso-27001/annex-a-5-21-information-security-in-the-supply-chain) | Risk further down the technology supply chain |
| [A.5.22 Monitoring, review and change management of supplier services](https://www.grcmana.io/vault/iso-27001/annex-a-5-22-change-management-of-supplier-services) | Keeping track of how suppliers perform and change |
| [A.5.23 Information security for use of cloud services](https://www.grcmana.io/vault/iso-27001/annex-a-5-23-information-security-for-use-of-cloud-services) | Securing cloud services from adoption to exit |
| [A.5.24 Information security incident management planning and preparation](https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation) | Being ready to handle incidents |
| [A.5.25 Assessment and decision on information security events](https://www.grcmana.io/vault/iso-27001/annex-a-5-25-assessment-and-decision-on-information-security-events) | Deciding which events are incidents |
| [A.5.26 Response to information security incidents](https://www.grcmana.io/vault/iso-27001/annex-a-5-26-response-to-information-security-incidents) | Responding to incidents in a planned way |
| [A.5.27 Learning from information security incidents](https://www.grcmana.io/vault/iso-27001/annex-a-5-27-learning-from-information-security-incidents) | Feeding incident lessons back into controls |
| [A.5.28 Collection of evidence](https://www.grcmana.io/vault/iso-27001/annex-a-5-28-collection-of-evidence) | Preserving evidence that may be needed later |
| [A.5.29 Information security during disruption](https://www.grcmana.io/vault/iso-27001/annex-a-5-29-information-security-during-disruption) | Keeping security in place during a crisis |
| [A.5.30 ICT readiness for business continuity](https://www.grcmana.io/vault/iso-27001/annex-a-5-30-ict-readiness-for-business-continuity) | Technology recovery that meets continuity needs |
| [A.5.31 Legal, statutory, regulatory and contractual requirements](https://www.grcmana.io/vault/iso-27001/annex-a-5-31-legal-statutory-regulatory-and-contractual-requirements) | Knowing and meeting your obligations |
| [A.5.32 Intellectual property rights](https://www.grcmana.io/vault/iso-27001/annex-a-5-32-intellectual-property-rights) | Respecting licences and IP |
| [A.5.33 Protection of records](https://www.grcmana.io/vault/iso-27001/annex-a-5-33-protection-of-records) | Keeping records safe and retrievable |
| [A.5.34 Privacy and protection of PII](https://www.grcmana.io/vault/iso-27001/annex-a-5-34-privacy-and-protection-of-pii) | Protecting personal data as law requires |
| [A.5.35 Independent review of information security](https://www.grcmana.io/vault/iso-27001/annex-a-5-35-independent-review-of-information-security) | Periodic independent checks on your approach |
| [A.5.36 Compliance with policies, rules and standards for information security](https://www.grcmana.io/vault/iso-27001/annex-a-5-36-compliance-with-policies-rules-and-standards-for-information-security) | Checking that policies are actually followed |
| [A.5.37 Documented operating procedures](https://www.grcmana.io/vault/iso-27001/annex-a-5-37-documented-operating-procedures) | Written procedures for key operations |

### People controls (A.6)

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

| Control | What it is for |
| --- | --- |
| [A.6.1 Screening](https://www.grcmana.io/vault/iso-27001/annex-a-6-1-screening) | Proportionate background checks |
| [A.6.2 Terms and conditions of employment](https://www.grcmana.io/vault/iso-27001/annex-a-6-2-terms-and-conditions-of-employment) | Security duties written into contracts |
| [A.6.3 Information security awareness, education and training](https://www.grcmana.io/vault/iso-27001/annex-a-6-3-information-security-awareness-education-and-training) | Training that fits each role |
| [A.6.4 Disciplinary process](https://www.grcmana.io/vault/iso-27001/annex-a-6-4-disciplinary-process) | A known process for security breaches by staff |
| [A.6.5 Responsibilities after termination or change of employment](https://www.grcmana.io/vault/iso-27001/annex-a-6-5-responsibilities-after-termination-or-change-of-employment) | Duties that continue after someone leaves |
| [A.6.6 Confidentiality or non-disclosure agreements](https://www.grcmana.io/vault/iso-27001/annex-a-6-6-confidentiality-or-non-disclosure-agreements) | NDAs that match your needs |
| [A.6.7 Remote working](https://www.grcmana.io/vault/iso-27001/annex-a-6-7-remote-working) | Securing work done away from the office |
| [A.6.8 Information security event reporting](https://www.grcmana.io/vault/iso-27001/annex-a-6-8-information-security-event-reporting) | An easy way for anyone to report concerns |

### Physical controls (A.7)

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

| Control | What it is for |
| --- | --- |
| [A.7.1 Physical security perimeters](https://www.grcmana.io/vault/iso-27001/annex-a-7-1-physical-security-perimeters) | Defined boundaries around sensitive areas |
| [A.7.2 Physical entry](https://www.grcmana.io/vault/iso-27001/annex-a-7-2-physical-entry) | Controlling who gets in |
| [A.7.3 Securing offices, rooms and facilities](https://www.grcmana.io/vault/iso-27001/annex-a-7-3-securing-offices-rooms-and-facilities) | Protecting the spaces where work happens |
| [A.7.4 Physical security monitoring](https://www.grcmana.io/vault/iso-27001/annex-a-7-4-physical-security-monitoring) | Watching premises for intrusion |
| [A.7.5 Protecting against physical and environmental threats](https://www.grcmana.io/vault/iso-27001/annex-a-7-5-protecting-against-physical-and-environmental-threats) | Fire, flood and other environmental risks |
| [A.7.6 Working in secure areas](https://www.grcmana.io/vault/iso-27001/annex-a-7-6-working-in-secure-areas) | Rules for work inside secure areas |
| [A.7.7 Clear desk and clear screen](https://www.grcmana.io/vault/iso-27001/annex-a-7-7-clear-desk-and-clear-screen) | Nothing sensitive left on desks or screens |
| [A.7.8 Equipment siting and protection](https://www.grcmana.io/vault/iso-27001/annex-a-7-8-equipment-siting-and-protection) | Placing equipment where it is safe |
| [A.7.9 Security of assets off-premises](https://www.grcmana.io/vault/iso-27001/annex-a-7-9-security-of-assets-off-premises) | Protecting laptops and devices on the move |
| [A.7.10 Storage media](https://www.grcmana.io/vault/iso-27001/annex-a-7-10-storage-media) | Handling drives and media safely |
| [A.7.11 Supporting utilities](https://www.grcmana.io/vault/iso-27001/annex-a-7-11-supporting-utilities) | Power and other services equipment depends on |
| [A.7.12 Cabling security](https://www.grcmana.io/vault/iso-27001/annex-a-7-12-cabling-security) | Protecting power and network cabling |
| [A.7.13 Equipment maintenance](https://www.grcmana.io/vault/iso-27001/annex-a-7-13-equipment-maintenance) | Maintaining equipment so it stays reliable |
| [A.7.14 Secure disposal or re-use of equipment](https://www.grcmana.io/vault/iso-27001/annex-a-7-14-secure-disposal-or-re-use-of-equipment) | Wiping data before disposal or reuse |

### 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.

| Control | What it is for |
| --- | --- |
| [A.8.1 User endpoint devices](https://www.grcmana.io/vault/iso-27001/annex-a-8-1-user-endpoint-devices) | Securing laptops and phones |
| [A.8.2 Privileged access rights](https://www.grcmana.io/vault/iso-27001/annex-a-8-2-privileged-access-rights) | Restricting and watching admin access |
| [A.8.3 Information access restriction](https://www.grcmana.io/vault/iso-27001/annex-a-8-3-information-access-restriction) | Enforcing access rules in systems |
| [A.8.4 Access to source code](https://www.grcmana.io/vault/iso-27001/annex-a-8-4-access-to-source-code) | Protecting code repositories |
| [A.8.5 Secure authentication](https://www.grcmana.io/vault/iso-27001/annex-a-8-5-secure-authentication) | Strong sign-in, such as multi-factor authentication |
| [A.8.6 Capacity management](https://www.grcmana.io/vault/iso-27001/annex-a-8-6-capacity-management) | Enough capacity for current and future demand |
| [A.8.7 Protection against malware](https://www.grcmana.io/vault/iso-27001/annex-a-8-7-protection-against-malware) | Preventing and detecting malicious software |
| [A.8.8 Management of technical vulnerabilities](https://www.grcmana.io/vault/iso-27001/annex-a-8-8-management-of-technical-vulnerabilities) | Finding and fixing vulnerabilities |
| [A.8.9 Configuration management](https://www.grcmana.io/vault/iso-27001/annex-a-8-9-configuration-management) | Secure, consistent configurations |
| [A.8.10 Information deletion](https://www.grcmana.io/vault/iso-27001/annex-a-8-10-information-deletion) | Deleting data you no longer need |
| [A.8.11 Data masking](https://www.grcmana.io/vault/iso-27001/annex-a-8-11-data-masking) | Hiding sensitive values where not needed |
| [A.8.12 Data leakage prevention](https://www.grcmana.io/vault/iso-27001/annex-a-8-12-data-leakage-prevention) | Stopping data leaving without authority |
| [A.8.13 Information backup](https://www.grcmana.io/vault/iso-27001/annex-a-8-13-information-backup) | Backups that are tested and restorable |
| [A.8.14 Redundancy of information processing facilities](https://www.grcmana.io/vault/iso-27001/annex-a-8-14-redundancy-of-information-processing-facilities) | Enough redundancy to stay available |
| [A.8.15 Logging](https://www.grcmana.io/vault/iso-27001/annex-a-8-15-logging) | Recording and protecting activity logs |
| [A.8.16 Monitoring activities](https://www.grcmana.io/vault/iso-27001/annex-a-8-16-monitoring-activities) | Spotting anomalous behaviour |
| [A.8.17 Clock synchronization](https://www.grcmana.io/vault/iso-27001/annex-a-8-17-clock-synchronisation) | Consistent time across systems |
| [A.8.18 Use of privileged utility programs](https://www.grcmana.io/vault/iso-27001/annex-a-8-18-use-of-privileged-utility-programs) | Restricting tools that can bypass controls |
| [A.8.19 Installation of software on operational systems](https://www.grcmana.io/vault/iso-27001/annex-a-8-19-installation-of-software-on-operational-systems) | Controlling what software gets installed |
| [A.8.20 Networks security](https://www.grcmana.io/vault/iso-27001/annex-a-8-20-network-security) | Securing and managing networks |
| [A.8.21 Security of network services](https://www.grcmana.io/vault/iso-27001/annex-a-8-21-security-of-network-services) | Security requirements for network services |
| [A.8.22 Segregation of networks](https://www.grcmana.io/vault/iso-27001/annex-a-8-22-segregation-of-networks) | Separating networks by trust level |
| [A.8.23 Web filtering](https://www.grcmana.io/vault/iso-27001/annex-a-8-23-web-filtering) | Limiting access to risky websites |
| [A.8.24 Use of cryptography](https://www.grcmana.io/vault/iso-27001/annex-a-8-24-use-of-cryptography) | Encryption rules and key management |
| [A.8.25 Secure development life cycle](https://www.grcmana.io/vault/iso-27001/annex-a-8-25-secure-development-life-cycle) | Security built into how software is made |
| [A.8.26 Application security requirements](https://www.grcmana.io/vault/iso-27001/annex-a-8-26-application-security-requirements) | Defining security needs for applications |
| [A.8.27 Secure system architecture and engineering principles](https://www.grcmana.io/vault/iso-27001/annex-a-8-27-secure-system-architecture-and-engineering-principles) | Principles for designing secure systems |
| [A.8.28 Secure coding](https://www.grcmana.io/vault/iso-27001/annex-a-8-28-secure-coding) | Writing code that avoids common flaws |
| [A.8.29 Security testing in development and acceptance](https://www.grcmana.io/vault/iso-27001/annex-a-8-29-security-testing-in-development-and-acceptance) | Testing security before release |
| [A.8.30 Outsourced development](https://www.grcmana.io/vault/iso-27001/annex-a-8-30-outsourced-development) | Overseeing development done by others |
| [A.8.31 Separation of development, test and production environments](https://www.grcmana.io/vault/iso-27001/annex-a-8-31-separation-of-development-test-and-production-environments) | Keeping environments apart |
| [A.8.32 Change management](https://www.grcmana.io/vault/iso-27001/annex-a-8-32-change-management) | Controlled changes to systems |
| [A.8.33 Test information](https://www.grcmana.io/vault/iso-27001/annex-a-8-33-test-information) | Protecting data used in testing |
| [A.8.34 Protection of information systems during audit testing](https://www.grcmana.io/vault/iso-27001/annex-a-8-34-protection-of-information-systems-during-audit-testing) | Making audits safe for live systems |

## 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](https://www.grcmana.io/vault/iso-27001/documents). To plan the build in phases, start with the [ISO 27001 implementation roadmap](https://www.grcmana.io/vault/iso-27001/implementation), or browse the [ISO 27001 hub](https://www.grcmana.io/vault/iso-27001).

## Frequently asked questions

### What is the difference between ISO 27001 Annex A and ISO 27002?

ISO 27001 Annex A names each control and states its purpose in a sentence or two. ISO/IEC 27002:2022 is a separate guidance standard that explains how each of the same 93 controls can be implemented and adds the five attributes. You certify against ISO 27001; ISO 27002 is optional reading that helps you implement.

### Can the Annex A controls be mapped to Cyber Essentials or SOC 2?

Yes, and mapping saves real effort. The five technical controls in the [NCSC's Cyber Essentials scheme](https://www.ncsc.gov.uk/cyberessentials/overview) (firewalls, secure configuration, security update management, user access control and malware protection) sit mostly inside the Annex A technological theme. SOC 2 criteria overlap widely too, so one well-run control set can produce evidence for several attestations.

### Do auditors test every Annex A control at certification?

No. Auditors sample. They usually trace a few risks from assessment through to the controls and SoA lines that treat them, test a selection of included controls, and probe exclusions for a defensible reason. Expect to be asked to justify any control you have excluded.

### How often should the Statement of Applicability be updated?

Update the SoA whenever your risks change: after a significant incident, a restructure, a new platform or a new service line. Review it at least once a year as part of management review, so the status column reflects reality rather than the week of certification.