If you are working through an ISO 27001 implementation, Annex A is the section that will occupy most of your practical effort. It is a reference set of 93 information security controls — organised across four themes — that your organisation must review, assess, and either apply or formally justify excluding. Understanding what Annex A is, how it connects to ISO 27002, and how auditors scrutinise it in practice is essential before you start building your Information Security Management System (ISMS). This guide walks UK IT managers and compliance leads through everything you need to know.
What Is Annex A in ISO 27001?
ISO 27001:2022 is the internationally recognised standard for information security management. The main body of the standard sets out the requirements for establishing, implementing, maintaining, and continually improving an ISMS — things like leadership commitment, risk assessment, and management review. Annex A sits alongside this as a normative reference: a structured catalogue of security controls that organisations should consider when treating their identified risks.
The 2022 version of the standard introduced a significant restructure. The previous 2013 edition contained 114 controls across 14 clauses. ISO 27001:2022 reduced this to 93 controls across 4 themes, merging some controls, renaming others, and adding 11 new controls that reflect modern threats — particularly around cloud services and supply chain security. Organisations that have not yet transitioned from the 2013 edition should prioritise doing so, as the 2022 version is now the current standard against which new certifications are assessed.
It is important to understand that Annex A does not require you to implement every one of the 93 controls. It requires you to consider each one in the context of your risk assessment and document your decisions. Controls that are not relevant to your organisation can be excluded — but you must justify every exclusion in your Statement of Applicability.
How Annex A Links to ISO 27002
Annex A lists the controls by name and number only — it gives you the what but not the how. ISO 27002:2022 is the companion guidance document that expands on each control in detail. For each Annex A control, ISO 27002 provides a purpose statement, implementation guidance, and additional information about how organisations can put the control into practice.
ISO 27002 is not a certifiable standard — you cannot get certified against it. It is purely a support document. Organisations implementing ISO 27001 are strongly advised to use ISO 27002 as a practical reference when designing their controls, writing policies, and building evidence for auditors. If your organisation has purchased ISO 27001, obtaining a copy of ISO 27002 is worth the additional investment, particularly for compliance leads who need detailed implementation guidance without starting from scratch.
The Four Control Themes in ISO 27001:2022
The 93 controls in Annex A are divided into four themes. Each theme groups controls by the nature of the asset or activity they protect. Here is what each theme covers, along with the controls that attract the most attention during audits.
Theme 1: Organisational Controls (A.5)
The largest theme, containing 37 controls, covers policies, governance, supplier relationships, and compliance obligations. These are the foundational controls that underpin everything else in your ISMS.
A.5.1 — Policies for Information Security
A.5.1 requires your organisation to define, approve, publish, and regularly review an information security policy and associated topic-specific policies. Auditors will want to see that policies have been approved by senior management, are accessible to staff, and have been reviewed within a defined period (typically annually). A policy that has not been reviewed for three years, or one that staff cannot locate, is a common minor nonconformity.
A.5.2 — Information Security Roles and Responsibilities
A.5.2 requires that security responsibilities are clearly defined and allocated. In practice, this means documenting who owns what — whether that is asset ownership, policy ownership, or incident response accountability. Organisations often implement this through a RACI matrix or by including security responsibilities in job descriptions. Auditors look for evidence that staff are aware of their responsibilities, not just that they exist on paper.
A.5.19 — Information Security in Supplier Relationships
A.5.19 addresses the risk introduced by third-party suppliers. Your organisation must define and implement processes for managing supplier relationships — including security requirements in contracts, periodic review of supplier compliance, and assessment of risk before onboarding. This control received heightened focus after a series of high-profile supply chain attacks and is one auditors examine closely. Related new controls include A.5.21 (managing security in the ICT supply chain) and A.5.23 (information security for use of cloud services), both introduced in the 2022 edition.
A.5.23 — Information Security for Use of Cloud Services
A.5.23 is one of the 11 new controls added in ISO 27001:2022, reflecting how widely organisations now rely on cloud platforms. It requires you to establish and communicate processes for acquiring, using, managing, and exiting cloud services — covering security requirements, shared responsibility boundaries, and data residency. If your organisation uses AWS, Azure, Microsoft 365, or any SaaS product, this control will apply, and auditors will expect documented agreements and security assessments for your key cloud providers.
Theme 2: People Controls (A.6)
The smallest theme, with 8 controls, covers the human element of information security — from pre-employment screening through to responsibilities when someone leaves the organisation.
A.6.1 — Screening
A.6.1 requires background verification checks to be carried out on all candidates prior to joining the organisation and on a risk-based basis for contractors and third parties. In the UK context, this typically means DBS checks where appropriate, reference checks, and employment history verification. The level of screening should be proportionate to the sensitivity of the role and the information being accessed.
A.6.3 — Information Security Awareness, Education and Training
A.6.3 is one of the most scrutinised controls in this theme. Auditors will want evidence that staff receive regular, relevant security awareness training — not a single induction video that was watched three years ago. Best practice involves annual training cycles, phishing simulations, and role-specific training for those with elevated access or data handling responsibilities. Records of completion must be maintained.
A.6.5 — Responsibilities After Termination or Change of Employment
A.6.5 requires that information security responsibilities that survive the end of employment — such as confidentiality obligations — are defined, communicated, and enforced. This also covers the timely revocation of access rights when someone leaves or changes role. Failing to disable accounts promptly after an employee’s departure is one of the most common findings in ISO 27001 audits and one of the simplest to address with a documented offboarding procedure.
Theme 3: Physical Controls (A.7)
This theme contains 14 controls covering the physical protection of information and IT assets — premises, equipment, and media. Even organisations with largely cloud-based infrastructure cannot exclude this section entirely, as physical risks still apply to offices, devices, and employees working remotely.
A.7.1 — Physical Security Perimeters
A.7.1 requires defined physical security perimeters to protect areas containing sensitive information or IT equipment. This means server rooms, network closets, and restricted office areas should have appropriate access controls — whether that is locked doors, access card systems, or PIN entry. Auditors will walk the floor and look for evidence that security boundaries exist and are enforced. Propped-open fire doors to server rooms are a surprisingly frequent finding.
A.7.9 — Security of Assets Off-Premises
A.7.9 addresses equipment taken outside the organisation’s premises — laptops, mobile phones, storage devices, and documents. Your policy must address the risks of working remotely, including requirements for screen locks, encryption, and the prohibition of leaving devices unattended in vehicles. With hybrid working now standard for most UK businesses, this control is more relevant than ever and is consistently tested during stage two audits.
A.7.10 — Storage Media
A.7.10 covers the management of removable and reusable storage media throughout its lifecycle — from procurement through to secure disposal. USB drives, external hard disks, and backup tapes must be inventoried, managed according to classification requirements, and disposed of securely. Many organisations choose to prohibit removable media entirely and implement this as a technical control under A.8.12 (data leakage prevention), using the policy prohibition as evidence for A.7.10.
Theme 4: Technological Controls (A.8)
The second largest theme with 34 controls, this section covers all technical and IT security controls — access management, cryptography, vulnerability management, logging, and secure development. Several new controls were added here in the 2022 edition to address modern attack vectors.
A.8.2 — Privileged Access Rights
A.8.2 requires that the allocation and use of privileged access rights is restricted and controlled. In practice, this means administrator accounts must be separate from standard user accounts, privileged access should be granted on a least-privilege basis, and privileged sessions should ideally be logged or monitored. Auditors will request a list of privileged accounts and evidence of periodic review. Stale admin accounts belonging to former employees or contractors are a recurring finding.
A.8.7 — Protection Against Malware
A.8.7 requires controls to detect and protect against malware. This extends beyond simply having antivirus software installed — it encompasses endpoint detection and response (EDR) tools, email filtering, web filtering, and user awareness about malware risks. Your controls must cover all relevant endpoints including servers, workstations, and mobile devices, and evidence of regular updates and scan results is typically requested at audit.
A.8.8 — Management of Technical Vulnerabilities
A.8.8 requires a systematic approach to identifying, evaluating, and remediating technical vulnerabilities. This means maintaining an asset inventory, subscribing to vulnerability intelligence feeds (such as NCSC alerts), and operating a defined patching process with documented timescales based on severity. Penetration testing results may also be requested as evidence of how you identify and address vulnerabilities that automated scanning might miss.
A.8.15 — Logging
A.8.15 requires that logs recording user activity, exceptions, faults, and security events are produced, stored, protected, and analysed. This is closely linked to incident detection and response. Auditors will want to see that logs are retained for an appropriate period (typically 90 days minimum for active use, with longer archival), that log integrity is protected from tampering, and that someone is actually reviewing them. Simply enabling logging without any monitoring process is unlikely to satisfy an auditor.
A.8.24 — Use of Cryptography
A.8.24 requires a policy on the use of cryptography, covering encryption of data at rest, data in transit, and key management. For most UK organisations, this means ensuring that laptops are encrypted (BitLocker or equivalent), that data transferred externally uses TLS, and that encryption keys are managed securely — including processes for key rotation and revocation. Weak or deprecated encryption algorithms (such as MD5 or SHA-1) are an audit finding that should be eliminated before your assessment.
A.8.28 — Secure Coding
A.8.28 is one of the new controls introduced in 2022 and applies to any organisation that develops software or applications internally. It requires that secure coding principles are applied throughout the development lifecycle — covering input validation, authentication, error handling, and code review practices. If your organisation does not develop software, this control can typically be excluded in your Statement of Applicability, but you will need to justify that clearly.
The Statement of Applicability
The Statement of Applicability (SoA) is one of the most important documents in your ISMS and is a mandatory requirement of ISO 27001. It is a formal record that lists every Annex A control, states whether it is applicable to your organisation, and explains the justification for that decision — whether the control is included because of a risk treatment decision, a legal obligation, a contractual requirement, or best practice.
For controls that are applicable, the SoA should also indicate their current implementation status — whether they are fully implemented, partially implemented, or planned. This gives auditors a clear picture of your ISMS maturity and allows them to verify that your risk treatment decisions translate into actual controls.
The SoA must be a living document. It should be reviewed and updated whenever there are significant changes to your organisation, your risk landscape, or the controls themselves. A SoA that was created during initial certification and never updated is a red flag for auditors conducting surveillance visits.
What “Not Applicable” Means — and How to Justify It
Excluding a control from your scope is entirely legitimate — ISO 27001 does not require all 93 controls to be implemented. However, the exclusion must be justified. Common legitimate reasons for exclusion include:
- The control relates to a risk that does not exist in your environment (for example, A.8.28 — Secure Coding if your organisation does not develop software)
- The risk addressed by the control has been accepted as within your risk appetite
- The control has been superseded by an alternative measure that addresses the same risk
What you cannot do is exclude a control simply because it is inconvenient or costly to implement, if the associated risk sits outside your accepted risk tolerance. Auditors are experienced at spotting exclusions that appear to be cost-avoidance decisions dressed up as risk justifications. Every exclusion should trace back to your risk assessment and risk treatment plan.
Common Mistakes Organisations Make with Annex A
Treating Annex A as a checklist rather than a risk-driven exercise. Some organisations tick through the 93 controls and implement them all without first conducting a proper risk assessment. This is backwards. ISO 27001 requires your risk assessment to drive your control selection — Annex A is the reference set you consult when deciding how to treat identified risks, not a to-do list.
Writing a SoA that does not link to the risk treatment plan. The SoA and the risk treatment plan should be joined at the hip. If a control is included in the SoA, it should correspond to a risk or obligation in your risk treatment plan. Disconnected documents suggest an ISMS built for audit appearance rather than genuine security management.
Over-excluding controls without proper justification. Organisations sometimes exclude controls because they assume they are not relevant, without examining whether a risk actually exists. Cloud controls are frequently excluded by organisations that use cloud services on the grounds that “the provider handles that” — an argument that conflates shared responsibility with full transfer of risk.
Implementing controls without generating evidence. A control only exists in audit terms if there is evidence it is operating. A patching policy with no patch records, a training requirement with no completion logs, or a supplier review process with no documented review outcomes will all result in findings, even if the underlying control is technically in place.
Not updating the SoA as the organisation changes. Cloud migrations, acquisitions, new product lines, and changes in how people work all have implications for your Annex A control set. Treating the SoA as a one-time certification artefact is a mistake that tends to surface during surveillance audits when the document no longer reflects reality.
Summary
Annex A in ISO 27001:2022 provides 93 controls across four themes — Organisational, People, Physical, and Technological — that represent the reference set for your information security control environment. It is not a mandatory list of things to implement; it is a structured starting point for making informed, risk-driven decisions about how to protect your organisation’s information assets. The companion document ISO 27002 provides the detailed implementation guidance that turns each control from a label into a practical activity.
Your Statement of Applicability is the document that ties everything together — recording which controls apply, why, and what their current status is. Getting the SoA right, keeping it current, and ensuring your control decisions are genuinely rooted in your risk assessment are the hallmarks of a mature, audit-ready ISMS. The most common failures in Annex A implementation are not technical gaps but documentation and process gaps — and they are all avoidable with the right approach from the outset.
