ISO 27001 Annex A Controls Explained
Detailed explanation of ISO 27001:2022 Annex A controls across the four categories: Organisational (37), People (8), Physical (14), and Technological (34). Covers the 11 new controls, control attributes, and practical guidance for building the Statement of Applicability.
- 1
ISO 27001:2022 Annex A contains 93 controls in four categories: Organisational (37), People (8), Physical (14), and Technological (34). The restructuring from 14 to 4 categories simplifies control ownership assignment.
- 2
Eleven new controls address threat intelligence, cloud security, ICT business continuity, configuration management, data deletion, data masking, DLP, monitoring, web filtering, secure coding, and physical security monitoring.
- 3
The Statement of Applicability is the critical bridge between your risk assessment and Annex A controls. Build it iteratively from the start, not as a last-minute audit preparation document.
- 4
New controls align closely with NIS2, DORA, and GDPR requirements, enabling organisations to use a single ISO 27001 control implementation to demonstrate compliance across multiple frameworks.
1. Annex A Structure in the 2022 Revision
ISO 27001:2022 Annex A references the controls defined in ISO/IEC 27002:2022. The previous structure of 114 controls across 14 categories (A.5 through A.18) has been reorganised into 93 controls across four thematic categories: A.5 Organisational controls (37 controls), A.6 People controls (8 controls), A.7 Physical controls (14 controls), and A.8 Technological controls (34 controls). The reduction from 114 to 93 controls is primarily due to merging overlapping controls from the 2013 version — no security topics have been removed. In fact, 11 entirely new controls have been added to address security domains that were not explicitly covered in the 2013 revision.
The 2022 revision also introduces a control attribute system defined in ISO 27002:2022. Each control is tagged with five attributes: control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts aligned to the NIST Cybersecurity Framework (identify, protect, detect, respond, recover), operational capabilities (e.g., governance, asset management, human resource security, physical security, system and network security, application security), and security domains (governance and ecosystem, protection, defence, resilience). While these attributes are informational and not audited under ISO 27001, they are valuable for mapping controls to other frameworks and for organising your Statement of Applicability in a way that aligns with NIS2, DORA, or other regulatory requirements.
The four-category structure reflects a more intuitive organisation than the previous 14 categories. Organisational controls address the governance, policy, and process dimensions of information security. People controls focus on the human element. Physical controls cover the tangible environment. Technological controls address the digital security measures. This structure makes it easier for organisations to assign control ownership, as the categories broadly align with organisational functions: governance and compliance teams own many organisational controls, HR owns people controls, facilities management owns physical controls, and IT/security teams own technological controls.
2. Organisational Controls (A.5: 37 Controls)
The organisational controls category is the largest, reflecting the standard's emphasis on governance and process-level security measures. Key controls include A.5.1 (Policies for information security), which requires a set of policies approved by management, communicated, and acknowledged by relevant personnel; A.5.2 (Information security roles and responsibilities), which requires defined and allocated responsibilities; and A.5.3 (Segregation of duties), which requires conflicting duties to be segregated to reduce fraud and error risk.
Asset management controls include A.5.9 (Inventory of information and other associated assets), A.5.10 (Acceptable use of information and other associated assets), A.5.11 (Return of assets), and A.5.12-A.5.13 covering classification and labelling. Access control is addressed through A.5.15 (Access control), A.5.16 (Identity management), A.5.17 (Authentication information), and A.5.18 (Access rights). Supplier relationship security is covered by A.5.19 through A.5.22, addressing supplier security policies, security within supplier agreements, managing ICT supply chain security, and monitoring and reviewing supplier services.
Notable new controls in the organisational category include A.5.7 (Threat intelligence), which requires the organisation to collect and analyse information about threats to produce actionable intelligence, and A.5.23 (Information security for use of cloud services), which requires establishing security processes for acquisition, use, management, and exit of cloud services. A.5.30 (ICT readiness for business continuity) is also new, requiring ICT continuity planning, implementation, and testing to support business operations during disruption. These new controls directly address gaps that had become increasingly apparent since the 2013 revision and align closely with NIS2 Article 21 requirements for threat intelligence, cloud security, and business continuity.
A.5.7 (Threat intelligence) aligns directly with NIS2 Article 21(2)(a) on risk analysis. Organisations can satisfy both requirements with a single threat intelligence programme that feeds into both the ISMS risk assessment and the NIS2 risk analysis.
3. People Controls (A.6: 8 Controls)
People controls address the human element of information security throughout the employment lifecycle. A.6.1 (Screening) requires background verification checks on all candidates prior to joining the organisation, proportionate to the business requirements, classification of information to be accessed, and perceived risks. In the EU context, screening must comply with GDPR requirements — particularly the principles of lawfulness, purpose limitation, and data minimisation. Not all screening measures that are common in other jurisdictions are permissible under EU data protection law, so ensure your screening procedures are reviewed by legal counsel.
A.6.2 (Terms and conditions of employment) requires that employment contracts state employees' information security responsibilities. A.6.3 (Information security awareness, education and training) requires that all personnel receive appropriate awareness and training, and regular updates on organisational policies and procedures. This is not a checkbox exercise — auditors will assess training content, delivery method, frequency, and evidence of understanding (e.g., quiz results, attestation records). A.6.4 (Disciplinary process) requires a formal disciplinary process for information security violations. A.6.5 (Responsibilities after termination or change of employment) requires that information security duties that remain valid after termination are defined, enforced, and communicated.
A.6.6 (Confidentiality or non-disclosure agreements) requires that confidentiality agreements reflecting the organisation's information protection needs are identified, documented, and signed. A.6.7 (Remote working) requires security measures when personnel work remotely — particularly relevant in the post-pandemic EU workplace where hybrid and remote working arrangements are widespread. A.6.8 (Information security event reporting) requires personnel to report observed or suspected information security events through appropriate channels. For each people control, the implementation must balance security requirements with employment law obligations under EU and national legislation, including works council consultation requirements in jurisdictions such as Germany, France, and the Netherlands.
4. Physical Controls (A.7: 14 Controls)
Physical controls protect the tangible environment in which information is processed, stored, and transmitted. A.7.1 (Physical security perimeters) requires defined security perimeters to protect areas containing information and information processing facilities. A.7.2 (Physical entry) requires secure areas to be protected by appropriate entry controls. A.7.3 (Securing offices, rooms and facilities) requires physical security measures for offices, rooms, and facilities. These foundational controls apply to every organisation with physical premises — including co-working spaces and shared office environments, where the organisation must define the security perimeter and manage access control within its area.
A.7.4 (Physical security monitoring) is a new control in the 2022 revision. It requires premises to be continuously monitored for unauthorised physical access. Implementation may include CCTV surveillance, intrusion detection systems, security guards, or a combination. In the EU, physical security monitoring must comply with GDPR requirements for CCTV and workplace monitoring — including data protection impact assessments where monitoring is likely to result in a high risk to data subjects' rights and freedoms, proportionality assessments, and compliance with employee monitoring regulations that vary by Member State.
A.7.5 through A.7.14 cover protection against physical and environmental threats (fire, flood, power failure), working in secure areas (visitor management, restricted access), clear desk and clear screen policies, equipment siting and protection, security of assets off-premises, storage media management and disposal, supporting utilities (power, cooling, telecoms), and cabling security. While physical controls may seem straightforward compared to technological controls, they require careful implementation in multi-site organisations, shared-tenancy buildings, and cloud-first environments where the organisation's physical footprint may be limited. For organisations that rely primarily on cloud infrastructure, many physical controls will be addressed through the cloud service provider's certifications — but this must be documented in the SoA and verified through supplier due diligence (A.5.19-A.5.22).
For organisations using co-location or cloud data centres, physical controls for those facilities are typically covered by the provider's ISO 27001 certification. Reference the provider's certificate in your SoA and verify coverage through their SOC 2 or ISO 27001 scope statement — but ensure you retain responsibility for physical security of your own offices and endpoints.
5. Technological Controls (A.8: 34 Controls)
Technological controls form the largest technical security category, addressing endpoint security, network security, application security, cryptography, and data protection. A.8.1 (User endpoint devices) requires security policies for devices used to access organisational information. A.8.2 (Privileged access rights) requires restriction and management of privileged access. A.8.3 (Information access restriction) requires access to information and systems to be restricted in accordance with the access control policy. A.8.5 (Secure authentication) requires secure authentication technologies and procedures based on access control policies and the risk assessment.
Several new controls in this category reflect the evolved threat and technology landscape. A.8.9 (Configuration management) requires security configurations to be established, documented, implemented, monitored, and reviewed for hardware, software, services, and networks. A.8.10 (Information deletion) requires information stored in information systems, devices, or any other storage media to be deleted when no longer required — directly supporting GDPR's data minimisation principle and right to erasure. A.8.11 (Data masking) requires data to be masked in accordance with the organisation's policies and risk assessment, using techniques such as anonymisation and pseudonymisation. A.8.12 (Data leakage prevention) requires data leakage prevention measures to be applied to systems, networks, and other devices that process, store, or transmit sensitive information.
A.8.16 (Monitoring activities) requires networks, systems, and applications to be monitored for anomalous behaviour and appropriate actions to be taken. A.8.23 (Web filtering) requires access to external websites to be managed to reduce exposure to malicious content. A.8.28 (Secure coding) requires secure coding principles to be applied to software development — covering input validation, session management, error handling, authentication, and authorisation within the development lifecycle. Each of these controls requires both implementation and monitoring — auditors will verify not only that controls exist but that they are actively monitored and that detected issues are responded to in accordance with the incident management process.
6. The 11 New Controls: A Closer Look
The 11 new controls introduced in ISO 27001:2022 address security domains that became critical since the 2013 revision. A.5.7 (Threat intelligence) requires organisations to collect, analyse, and produce intelligence about information security threats. This includes subscribing to threat feeds, participating in information-sharing communities (such as ISACs), and integrating threat intelligence into the risk assessment and control monitoring processes. For EU organisations, ENISA's threat landscape reports and national CSIRT feeds are valuable intelligence sources.
A.5.23 (Information security for use of cloud services) addresses the reality that most organisations now rely heavily on cloud services. The control requires a process for cloud service acquisition that includes security requirements assessment, a cloud security policy, and ongoing management of cloud service security including monitoring of the cloud provider's security posture, managing shared responsibility boundaries, and planning for cloud service termination. A.5.30 (ICT readiness for business continuity) extends traditional business continuity planning to explicitly cover ICT systems, requiring that ICT continuity is planned, implemented, maintained, and tested — not merely assumed because backup systems exist.
The technological new controls — A.8.9 (Configuration management), A.8.10 (Information deletion), A.8.11 (Data masking), A.8.12 (Data leakage prevention), A.8.16 (Monitoring activities), A.8.23 (Web filtering), and A.8.28 (Secure coding) — collectively address the modern digital environment where data proliferation, cloud adoption, distributed workforces, and sophisticated threats require more granular technical controls than the 2013 revision provided. For organisations operating in GDPR-regulated environments, several of these controls (particularly data masking, information deletion, and data leakage prevention) directly support data protection obligations. Organisations building their ISO 27001 ISMS should map these new controls to their existing technology stack, identify gaps, and prioritise implementation based on the risk assessment.
The 11 new controls cannot be excluded without strong justification. Auditors expect most organisations to find these controls applicable, as they address risks that are nearly universal in modern IT environments. If you plan to exclude any new control, prepare a well-documented justification based on your risk assessment.
7. Building the Statement of Applicability
The Statement of Applicability (SoA) is the document that connects your risk assessment to the Annex A controls. For each of the 93 controls, the SoA must state: whether the control is applicable (with justification if not applicable), the implementation status (implemented, partially implemented, planned, or not implemented), and a reference to the control implementation (e.g., the policy, procedure, technical measure, or other evidence that implements the control). The SoA is a mandatory document under Clause 6.1.3(d) and is one of the first documents the auditor requests at Stage 1.
Build the SoA as a living document from the start of your ISMS implementation, not as a last-minute audit preparation exercise. Begin with the risk assessment: for each identified risk, determine which Annex A controls mitigate it and mark those controls as applicable in the SoA. Then review the remaining controls — some will be applicable based on legal, regulatory, or contractual requirements even if the risk assessment did not directly identify them (e.g., GDPR data deletion requirements making A.8.10 applicable). For controls deemed not applicable, document a clear justification: why the risk does not exist, why the control is not relevant to your technology environment, or why the risk is addressed through other means.
The SoA should also capture the implementation approach for each applicable control. Reference specific documents (policies, procedures, work instructions), technical implementations (tool names, configurations), and organisational measures (roles, responsibilities, processes). This level of detail transforms the SoA from a compliance checklist into a useful operational document that maps your security controls to the standard's requirements. Maintain version control on the SoA and update it when the risk assessment changes, when new controls are implemented, or when existing controls are modified. The SoA is reviewed at every audit — Stage 1, Stage 2, surveillance, and recertification — so keeping it current is essential for ongoing certification maintenance.
How many of the 93 controls will we need to implement?
This depends on your risk assessment and organisational context. In practice, most organisations find 80-90 of the 93 controls applicable. The controls are designed to be broadly applicable, and exclusions require documented justification in the Statement of Applicability. Controls most commonly excluded are specific physical security controls (for fully remote organisations with no physical premises) and certain operational controls that are not relevant to the organisation's technology environment. The 11 new controls are expected to be applicable for virtually all organisations.
What changed between the 2013 and 2022 Annex A?
The 114 controls in 14 categories were reorganised into 93 controls in 4 categories (Organisational, People, Physical, Technological). This reorganisation involved merging overlapping controls and adding 11 new controls: A.5.7 (Threat intelligence), A.5.23 (Cloud security), A.5.30 (ICT business continuity readiness), A.7.4 (Physical security monitoring), A.8.9 (Configuration management), A.8.10 (Information deletion), A.8.11 (Data masking), A.8.12 (Data leakage prevention), A.8.16 (Monitoring activities), A.8.23 (Web filtering), and A.8.28 (Secure coding). No security topics were removed — the control count decreased because overlapping controls were consolidated.
How do Annex A controls map to ISO 27002?
ISO 27001 Annex A lists the controls by name and objective. ISO 27002:2022 provides detailed implementation guidance for each control, including purpose, guidance on implementation, and supplementary information. The control numbers are identical between the two documents. Think of ISO 27001 Annex A as the 'what' (which controls to implement) and ISO 27002 as the 'how' (detailed guidance on implementation). ISO 27002 is not a certifiable standard — it is a companion guidance document to ISO 27001.
Can we add controls that are not in Annex A?
Yes. Annex A is a reference set of controls, not an exhaustive catalogue. Clause 6.1.3(b) explicitly states that the organisation may determine controls beyond those in Annex A if the risk assessment identifies risks that are not adequately addressed by the Annex A controls. Additional controls may come from other sources such as sector-specific standards, regulatory requirements, or organisational security policies. Any additional controls should be documented in the risk treatment plan and referenced in the SoA.
What are control attributes and do auditors assess them?
ISO 27002:2022 introduced five control attributes: control type (preventive, detective, corrective), information security properties (CIA triad), cybersecurity concepts (NIST CSF alignment), operational capabilities, and security domains. These attributes are informational — they help organisations categorise and filter controls for different purposes (e.g., mapping to other frameworks, assigning ownership, prioritising implementation). Certification auditors do not assess control attributes, as they are part of ISO 27002 guidance, not ISO 27001 requirements. However, using attributes in your SoA can demonstrate a mature, well-structured approach to control management.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.