Reviewed October 2026. Applies to: ISO/IEC 27001:2022, with Amendment 1:2024.
At a glance
| Theme | Numbers | Controls | What it covers |
|---|---|---|---|
| Organisational | 5.1 to 5.37 | 37 | Policies, roles, assets, access, suppliers, cloud, incidents, continuity, legal and compliance |
| People | 6.1 to 6.8 | 8 | Screening, employment terms, training, discipline, leaving, confidentiality, remote working, reporting |
| Physical | 7.1 to 7.14 | 14 | Premises, entry, monitoring, environmental threats, equipment, media, utilities, disposal |
| Technological | 8.1 to 8.34 | 34 | Devices, access, authentication, malware, vulnerabilities, configuration, logging, networks, cryptography, development |
| Total | 93 |
Annex A is part of ISO/IEC 27001 itself and is normative, but it is a reference list, not a list of things every organisation must do. Which controls you apply follows from your risk assessment, and the Statement of Applicability records the result.
How Annex A is used
The controls come in at risk treatment (clause 6.1.3). Once you have assessed your risks and chosen how to treat each one, you decide which controls the treatment needs. Those controls can come from anywhere: Annex A, another framework, a contract or your own design.
You then compare your list with Annex A. The point is to catch a control you need but missed, not to adopt all 93. The standard says plainly that Annex A is not exhaustive, so you can add controls of your own.
The numbering matches ISO/IEC 27002:2022, which gives each control a fuller treatment: its purpose, guidance on putting it in place and its attributes. ISO/IEC 27002 is guidance; certification is against ISO/IEC 27001. People often write A.5.1 for an Annex A control so it is not confused with clause 5.1 of the main text.
The clauses of the standard (4 to 10) are different: they are requirements, and none of them can be left out. The requirements guide covers them.
Attributes from ISO/IEC 27002
ISO/IEC 27002:2022 tags each control with attributes, written in the standard as hashtags. They let you sort and filter the 93 controls into views that suit you: every detective control, say, or everything that supports availability. There are five attribute types.
| Attribute type | Values |
|---|---|
| Control type | Preventive, detective, corrective |
| Information security properties | Confidentiality, integrity, availability |
| Cybersecurity concepts | Identify, protect, detect, respond, recover |
| Operational capabilities | A longer list, such as governance, asset management, identity and access management, threat and vulnerability management, and information security assurance |
| Security domains | Governance and ecosystem, protection, defence, resilience |
Attributes are an aid, not a requirement. ISO/IEC 27001 does not ask you to use them, and Annex A of ISO/IEC 27001 does not include them. An informative annex of ISO/IEC 27002 explains how to use them.
Organisational controls (5.1 to 5.37)
The largest theme: how security is directed, owned and run across the organisation, including suppliers, incidents, continuity and legal duties.
| Control | What it is for | External evidence |
|---|---|---|
| 5.1 Policies for information security | Give management's security direction in writing, as a top-level policy and topic policies that people know about and that stay current. | |
| 5.2 Information security roles and responsibilities | Make sure every security task has someone named to do it. | |
| 5.3 Segregation of duties | Split conflicting tasks between people so no one person can misuse a process, or hide misuse, alone. | |
| 5.4 Management responsibilities | Managers expect secure working from their staff and contractors, and hold them to it. | |
| 5.5 Contact with authorities | Know which authorities to contact, such as regulators and law enforcement, and how to reach them. | |
| 5.6 Contact with special interest groups | Stay in touch with security forums and professional groups to learn and share. | |
| 5.7 Threat intelligence | Gather information about the threats that matter to you and use it in decisions. | |
| 5.8 Information security in project management | Consider security in every project, from start to finish, whatever the project is about. | |
| 5.9 Inventory of information and other associated assets | Know what information and assets you have, and who owns each one. | Partial |
| 5.10 Acceptable use of information and other associated assets | Tell people how information and equipment may be used and handled. | |
| 5.11 Return of assets | Get equipment and information back when someone leaves or a contract ends. | |
| 5.12 Classification of information | Sort information into levels by how much protection it needs. | |
| 5.13 Labelling of information | Mark information with its level so people handle it correctly. | |
| 5.14 Information transfer | Protect information when it moves, inside the organisation or to others: by email, file transfer, physical media or conversation. | Partial |
| 5.15 Access control | Decide who may reach which information and systems, physically and logically, and on what grounds. | |
| 5.16 Identity management | Manage each identity, for people and for systems, from creation to removal. | |
| 5.17 Authentication information | Issue, protect and reset passwords, keys and other secrets safely, and tell users how to look after them. | |
| 5.18 Access rights | Give people the access their role needs, check it regularly, and take it away when it is no longer needed. | |
| 5.19 Information security in supplier relationships | Manage the risks that come with using suppliers and their products. | |
| 5.20 Addressing information security within supplier agreements | Write the security each supplier must provide into your agreement with them. | |
| 5.21 Managing information security in the ICT supply chain | Deal with risks further along the technology supply chain, such as a supplier's own suppliers and components. | |
| 5.22 Monitoring, review and change management of supplier services | Keep an eye on how suppliers perform on security, and manage changes to what they deliver. | |
| 5.23 Information security for use of cloud services | Treat each cloud service as a life cycle: choose it with security in mind, run it safely, and plan how to leave it. | |
| 5.24 Information security incident management planning and preparation | Prepare for incidents before they happen: who does what, how, and who is told. | |
| 5.25 Assessment and decision on information security events | Triage reported events to tell real incidents from noise. | |
| 5.26 Response to information security incidents | When an incident happens, contain it and recover by following a written plan. | |
| 5.27 Learning from information security incidents | Review incidents afterwards and change controls so they are less likely to happen again. | |
| 5.28 Collection of evidence | Gather and keep evidence about incidents in a way that will stand up later, including in legal or disciplinary action. | |
| 5.29 Information security during disruption | Keep information protected during a disruption, not only in normal operation. | |
| 5.30 ICT readiness for business continuity | Make sure IT can be restored in time to meet business continuity objectives, and test that it can. | |
| 5.31 Legal, statutory, regulatory and contractual requirements | Know the laws, regulations and contracts that affect security, and how you meet them. | |
| 5.32 Intellectual property rights | Respect intellectual property and licences, including software licences. | |
| 5.33 Protection of records | Keep records intact, available and confidential for as long as they must be kept. | |
| 5.34 Privacy and protection of PII | Meet privacy law and contractual duties for personal data. | |
| 5.35 Independent review of information security | Have people outside the work check how security is managed, on a schedule and after major change. | |
| 5.36 Compliance with policies, rules and standards for information security | Check regularly that people and systems follow the organisation's own security rules. | |
| 5.37 Documented operating procedures | Keep written runbooks for operating systems and services where the people who need them can find them. |
People controls (6.1 to 6.8)
How people join, work and leave: checks, contracts, training and the duty to report.
| Control | What it is for | External evidence |
|---|---|---|
| 6.1 Screening | Check people's backgrounds before they join, and later where needed, in proportion to the role and within the law. | |
| 6.2 Terms and conditions of employment | Put security obligations, on both sides, into the terms people are employed on. | |
| 6.3 Information security awareness, education and training | Give people the security awareness and training their role needs, and refresh it. | |
| 6.4 Disciplinary process | Have a known, fair process for dealing with breaches of security policy. | |
| 6.5 Responsibilities after termination or change of employment | Make clear which security duties continue after someone leaves or changes role. | |
| 6.6 Confidentiality or non-disclosure agreements | Use confidentiality agreements that match what needs protecting, and keep them under review. | |
| 6.7 Remote working | Keep information safe when people work from home or on the move. | |
| 6.8 Information security event reporting | Give people a simple, quick way to report anything suspicious. |
Physical controls (7.1 to 7.14)
Premises, equipment and media. A remote-first organisation still has equipment in homes and on the move, and usually relies on a supplier's data centre, so these rarely all fall away.
| Control | What it is for | External evidence |
|---|---|---|
| 7.1 Physical security perimeters | Draw clear physical boundaries around places that hold information or equipment worth protecting. | |
| 7.2 Physical entry | Control who can get into secure areas, and how. | |
| 7.3 Securing offices, rooms and facilities | Make offices and rooms hard to enter, or see into, without permission. | |
| 7.4 Physical security monitoring | Watch premises for unauthorised entry, for example with alarms or cameras. | |
| 7.5 Protecting against physical and environmental threats | Guard against fire, flood, power surges and other physical hazards, natural or deliberate. | |
| 7.6 Working in secure areas | Set rules for how people work inside secure areas. | |
| 7.7 Clear desk and clear screen | Stop unattended papers, media and screens from exposing information. | |
| 7.8 Equipment siting and protection | Put equipment where it is safe from damage, interference and prying eyes. | |
| 7.9 Security of assets off-premises | Look after laptops, phones and other assets taken outside the office. | |
| 7.10 Storage media | Handle USB drives, disks and other media safely from purchase to disposal. | |
| 7.11 Supporting utilities | Keep power, cooling and other utilities from failing in ways that take systems down. | |
| 7.12 Cabling security | Run and protect cabling so it cannot easily be cut, tapped or disrupted. | |
| 7.13 Equipment maintenance | Service equipment properly, including when someone else does the work. | |
| 7.14 Secure disposal or re-use of equipment | Make sure nothing sensitive is left on equipment that is reused, sold or scrapped. |
Technological controls (8.1 to 8.34)
The technical measures: devices, access, configuration, monitoring, networks, cryptography and software development. Most of the controls an external check can support are here.
| Control | What it is for | External evidence |
|---|---|---|
| 8.1 User endpoint devices | Secure the laptops, phones and other devices people use, and the information on them. | |
| 8.2 Privileged access rights | Give administrator rights sparingly, to named people, and keep track of them. | |
| 8.3 Information access restriction | Make systems enforce the access rules you have decided on. | |
| 8.4 Access to source code | Control who can read and change your code and the tooling around it. | |
| 8.5 Secure authentication | Use sign-in methods strong enough for what they protect, such as multi-factor authentication. | |
| 8.6 Capacity management | Make sure systems have the capacity they need now and will need later. | |
| 8.7 Protection against malware | Stop malicious software getting in or running, with tools and with staff who know what to watch for. | |
| 8.8 Management of technical vulnerabilities | Learn about weaknesses in the software and systems you run, judge how exposed you are, and fix or mitigate in time. | Partial |
| 8.9 Configuration management | Decide what a secure set-up looks like for each kind of system, apply it, and spot drift. | Partial |
| 8.10 Information deletion | Remove information from systems and media once it is no longer needed, rather than keeping it indefinitely. | |
| 8.11 Data masking | Hide or replace sensitive values, such as personal data, where the real values are not needed. | |
| 8.12 Data leakage prevention | Spot and block sensitive information leaving by routes it should not. | |
| 8.13 Information backup | Back up what you would need to recover, and prove regularly that restores work. | |
| 8.14 Redundancy of information processing facilities | Avoid single points of failure where an outage would be unacceptable. | |
| 8.15 Logging | Keep logs of what happens on systems, protect them from tampering, and look at them. | |
| 8.16 Monitoring activities | Watch systems and networks for signs that something is wrong, and follow up what you find. | Partial |
| 8.17 Clock synchronization | Keep every system on the same trusted time so logs from different systems line up. | |
| 8.18 Use of privileged utility programs | Keep tools that can get round normal security controls in few hands, and watch their use. | |
| 8.19 Installation of software on operational systems | Control what software goes onto live systems, and who installs it. | |
| 8.20 Networks security | Protect the networks and network equipment that carry your information, and keep them under management. | Partial |
| 8.21 Security of network services | Know what security each network service should provide, whoever runs it, and check that it does. | Partial |
| 8.22 Segregation of networks | Split networks into separate zones so a problem in one part does not spread freely. | |
| 8.23 Web filtering | Limit which outside websites can be reached from your systems, to cut exposure to harmful sites. | |
| 8.24 Use of cryptography | Decide where and how encryption is used and how keys are handled, then apply those rules. | Partial |
| 8.25 Secure development life cycle | Build security into every stage of developing software and systems. | |
| 8.26 Application security requirements | Work out what security an application needs before you build or buy it. | Partial |
| 8.27 Secure system architecture and engineering principles | Design systems on agreed secure engineering principles, such as defence in depth. | |
| 8.28 Secure coding | Write code in ways that avoid common classes of vulnerability. | |
| 8.29 Security testing in development and acceptance | Test that security works as intended before software goes live. | |
| 8.30 Outsourced development | Stay in charge of the security of development work others do for you. | |
| 8.31 Separation of development, test and production environments | Keep development and test work apart from live systems and data. | |
| 8.32 Change management | Plan, approve and track changes to systems so they do not create new problems. | |
| 8.33 Test information | Use test data that does not expose real sensitive information, and look after it. | |
| 8.34 Protection of information systems during audit testing | Agree audit and assurance testing on live systems in advance so it does not disrupt them. |
Controls an external check can support
An automated external check looks at what anyone on the internet can see: DNS, email authentication, TLS, HTTP headers, the technologies a site reveals, certificate transparency logs and, for a domain you have verified, which of a fixed list of services answer. For nine controls that gives part of the technical picture. It never gives the whole of a control, because every control also needs decisions, owners and records that only the organisation can provide.
| Control | What an external check can show | What the organisation still needs |
|---|---|---|
| 5.9 Inventory of information and other associated assets | Hostnames found in certificate transparency logs and technologies seen on public sites, to compare with your inventory | The inventory itself, an owner for each asset, internal and non-public assets, and how the list is kept current |
| 5.14 Information transfer | SPF, DKIM and DMARC on sending domains, and TLS on web endpoints | Transfer rules and agreements, rules for file sharing, removable media and conversation, and staff who know them |
| 8.8 Management of technical vulnerabilities | End-of-life software and version disclosure on public sites, exposed services on verified domains, and a recheck once fixed | A vulnerability process, sources of vulnerability information, fix timescales by risk, internal systems and endpoints, and patch records |
| 8.9 Configuration management | Public configuration such as HTTP security headers, cookie flags, HSTS, DNSSEC and CAA, and when it changes | Documented secure baselines for each kind of system, change control, and the configuration of everything not public |
| 8.16 Monitoring activities | Scheduled rechecks of verified domains, with a notice when something changes | What is monitored inside (logs, networks, endpoints), who reviews alerts, and how an anomaly becomes an incident |
| 8.20 Networks security | Whether 21 fixed ports, such as databases, remote desktop, SSH, SMB and the Docker API, accept connections on a verified domain | Network design, firewall rules and their reviews, and the controls inside the network |
| 8.21 Security of network services | How DNS, email and web services present themselves, whether you or a provider runs them | Security requirements for each service, agreements with providers, and monitoring of service levels |
| 8.24 Use of cryptography | TLS protocol versions, cipher suites, certificate validity and expiry, and HSTS | Cryptography rules, key management, and encryption of data at rest and inside the network |
| 8.26 Application security requirements | HTTP security headers, Content Security Policy, cookie security and clickjacking protection on public pages | Security requirements specified and approved for each application, and everything a header check cannot see, such as authentication and input handling |
Evidence for Annex A controls
Ironfang can check
- Dated results for the public configuration behind 5.9, 5.14, 8.8, 8.9, 8.16, 8.20, 8.21, 8.24 and 8.26, from the External Security Check
- Findings with evidence, severity and a fix, and a recheck that shows when a finding was resolved
- A history per domain, and notices when monitored configuration changes
The organisation must establish
- The risk assessment and the decision to apply each control
- Policies, procedures and the owner of each control
- Everything not visible from the internet: internal systems, endpoints, people and premises
- Records of review, training, incidents, audits and management decisions
A clean external result is a useful record, not proof that a control is effective, and not evidence of conformity on its own. Treat it as one input to the evidence an auditor will want to see.
- Subdomain finder Find a domain's subdomains in public certificate transparency logs.
- Email security checker Check MX, SPF, DMARC and DKIM together, and the protection of a domain that sends no mail.
- End-of-life software checker See whether a site advertises software versions that no longer receive security fixes.
- HTTP security headers checker Check a site's HSTS, CSP, framing, content-type, referrer and permissions headers.
- SSL/TLS checker Check a site's HTTPS, certificate, expiry, TLS versions and weak cipher suites.
- Exposed services checker Check your domain for databases, remote desktop and other services open to the internet, once it is verified.
The Statement of Applicability
The Statement of Applicability (SoA) is a document that clause 6.1.3 requires. It records your decisions about controls, in four parts:
- The controls you need, whether from Annex A or elsewhere.
- Why each of them is included.
- Whether each one is in place yet.
- For every Annex A control you leave out, why.
So the SoA covers all 93 Annex A controls, plus any controls of your own. It is where the risk assessment meets the controls: each included control should trace back to a risk, a legal or contractual requirement, or a business decision. Expect an auditor to read it early and to test the controls it says are in place.
What an SoA usually holds
| Column | What goes in it |
|---|---|
| Control | Number and title, such as 8.24 Use of cryptography |
| Applicable | Yes or no |
| Reason | The risks, legal duties or contracts behind it, or why it is excluded |
| Status | Implemented, partly implemented or planned |
| How | The policy, procedure or tool that delivers it |
| Owner | The person accountable for it |
| Evidence | Where the records are kept |
Example rows
| Control | Applicable | Reason | Status |
|---|---|---|---|
| 5.23 Information security for use of cloud services | Yes | Production runs on a public cloud provider (risks R4, R11) | Implemented |
| 8.24 Use of cryptography | Yes | Customer data in transit and at rest (R2); contract terms with customers | Partly implemented: a legacy API host still accepts TLS 1.0 |
| 7.4 Physical security monitoring | Yes | A small office holds network equipment (R15) | Planned |
| 8.30 Outsourced development | No | No development is outsourced; to be reviewed if that changes | Not applicable |
Keeping it useful
- Give it a version number, an owner and an approval, and update it when the risk assessment changes.
- Keep it consistent with the risk treatment plan. A control marked planned in the SoA should have an action, an owner and a date in the plan.
- Give every exclusion a reason that would satisfy a sceptical reader. "Not relevant" is not a reason; "no development is outsourced" is.
- Point the evidence column at real records. For controls with an external, technical side, dated check results can be part of that evidence; the gap analysis guide covers collecting it.
Producing the SoA is a step in the requirements of ISO/IEC 27001, which the overview puts in the context of certification.
Sources
Checked on the review date above. Standards and schemes change; the source is the authority.