ISO 27001 Annex A Controls: All 93 Controls Explained

ISO 27001 Annex A Controls: All 93 Controls Explained

TL;DR

• ISO/IEC 27001:2022 Annex A contains 93 controls in 4 themes: Organizational (37), People (8), Physical (14), and Technological (34).
• The 2022 revision replaced 114 controls across 14 domains from the 2013 version; 11 controls are entirely new.
• You must assess all 93 controls for applicability, you do not implement every one. Exclusions must be justified in the Statement of Applicability (SoA).
• ISO/IEC 27002:2022 is the companion document with implementation guidance for each control; you certify against ISO 27001, not ISO 27002.
• The October 31, 2025 transition deadline has passed. All active certifications now must reference the 2022 standard. (Source: IAF MD 26:2022)

Who this is for

This article is for security managers, IT leads, and compliance staff preparing for ISO 27001 certification or transitioning an existing ISMS from the 2013 standard. It covers what each control theme requires and where the 11 new controls fit. If you are still deciding whether to pursue ISO 27001, start with the ISO 27001 certification process overview.

What Annex A Is, and What It Is Not

Annex A is a normative annex to ISO/IEC 27001:2022, meaning it is part of the standard itself, not advisory. It lists the controls your organization must evaluate during risk treatment.

The controls in Annex A are documented in detail in ISO/IEC 27002:2022, published in March 2022. ISO 27002 provides the purpose, implementation guidance, and other information for each of the 93 controls. Annex A names them; ISO 27002 explains how to apply them. Neither document is a checklist you work through sequentially. The correct sequence is:

1. Complete a risk assessment (Clause 6.1.2).
2. Select controls to treat identified risks, from Annex A and any other sources (Clause 6.1.3(b)).
3. Document all 93 controls in your Statement of Applicability, marking each as applicable or not applicable with justification (Clause 6.1.3(d)).
4. Implement selected controls and gather operating evidence.

A certification auditor reviews the SoA against your risk assessment to verify the logic holds. Controls marked "not applicable" without a credible rationale are a common finding at Stage 2 audits (the on-site conformity assessment, following the Stage 1 documentation review).

What changed from 2013 to 2022

The 2013 version organized 114 controls across 14 alphabetically-named domains (A.5 through A.18). The 2022 version reorganized into 4 themes with consecutive numbering (5.1 through 8.34). The structural differences:

Each control in the 2022 version carries five attributes: control type (preventive/detective/corrective), information security properties (confidentiality/integrity/availability), cybersecurity concepts aligned to NIST CSF, operational capabilities, and security domains. These attributes are not certification requirements, but they help with control mapping and gap analysis.

Theme 1: Organizational Controls (Controls 5.1-5.37)

Organizational controls set the management framework for the ISMS. They cover policies, governance structures, asset ownership, supplier relationships, and legal obligations. Leadership owns most of these controls.

Policies and governance (5.1-5.4)

5.1 Policies for information security. A set of information security policies must be defined, approved by management, published, and communicated to relevant personnel. The standard requires a top-level policy plus supporting policies for specific areas. Auditors check for evidence of management approval and distribution, not just the documents themselves.

5.2 Information security roles and responsibilities. All information security responsibilities must be defined and allocated. This includes the ISMS owner, control owners, and day-to-day operational roles. Undefined responsibilities are one of the most frequent nonconformities at Stage 1 audits.

5.3 Segregation of duties. Conflicting duties and areas of responsibility must be segregated to reduce opportunities for unauthorized modification or misuse. For small organizations with limited headcount, compensating controls (logs, supervisory review) can satisfy this requirement.

5.4 Management responsibilities. Management must require all personnel to apply information security in line with the organization's policies. This feeds directly into awareness training (6.3) and disciplinary processes (6.4).

Risk, assets, and classification (5.5-5.14)

5.5 Contact with authorities. The organization must maintain appropriate contacts with relevant authorities (regulators, law enforcement, emergency services). This is not about lobbying; it means knowing who to call during an incident and having documented escalation paths.

5.6 Contact with special interest groups. Participation in professional forums, ISACs, or vendor advisory groups to stay informed about threat developments. Relevant for threat intelligence (5.7). In practice this means maintaining at least one active membership (sector-specific ISAC, CISA alerts, or a vendor advisory programme) and recording how outputs feed into risk reviews. Auditors check that membership exists and that outputs are actually reviewed, not just that a forum was joined.

5.7 Threat intelligence (new in 2022). The organization must collect, analyze, and produce information about information security threats to inform risk treatment decisions. In practice, this means subscribing to threat feeds relevant to your sector, monitoring vendor advisories, and reviewing outputs from groups like FS-ISAC or H-ISAC. The control does not mandate a full threat intelligence program; it requires that threat information reaches decision-makers.

5.8 Information security in project management. Information security must be integrated into project management, regardless of the project type. Projects that introduce new systems, change data flows, or affect suppliers all require a security assessment step.

5.9 Inventory of information and other associated assets. Maintaining an inventory of assets associated with information and information processing is required. The inventory must show asset ownership and classification. A common audit finding is an incomplete inventory that captures servers and databases but omits shadow IT, SaaS subscriptions, and paper records. Ownership gaps, where an asset has no assigned owner, are the other leading nonconformity; controls 5.12 (classification) and 5.18 (access rights) both depend on ownership being established first.

5.10 Acceptable use of information and other associated assets. Rules for acceptable use must be identified, documented, and implemented. Acceptable use policies are frequently present but unread: auditors test whether staff can describe the key restrictions, not just whether a document exists. Policies that are only signed at onboarding and never reinforced are a common finding under 6.3 (awareness training) as well.

5.11 Return of assets. All personnel and relevant third parties must return organizational assets upon change or termination of employment, contract, or agreement. Offboarding checklists satisfy this control when they explicitly list device return, badge surrender, and revocation of remote access credentials. The most common finding is that the checklist exists but completion is not recorded or verified, leaving no evidence that steps were followed.

5.12 Classification of information. Information must be classified according to the legal requirements, value, criticality, and sensitivity to unauthorized disclosure or modification. Most organizations use a three-tier scheme (public/internal/confidential or similar).

5.13 Labeling of information. An appropriate set of procedures for information labeling must be developed and implemented in accordance with the classification scheme. Labeling failures are almost always consistency failures: a policy that requires "Confidential" headers on printed documents but not on email attachments creates a gap auditors will find. Digital labeling using metadata or data classification tools (e.g., Microsoft Purview sensitivity labels) satisfies this control for electronic documents and makes 8.12 (data leakage prevention) enforceable.

5.14 Information transfer. Rules, procedures, or agreements for the transfer of information between the organization and third parties must be in place for all transfer types (electronic, physical, verbal). Verbal transfer is the most commonly overlooked category: meetings with external parties where classified information is discussed require the same protective consideration as email or file transfer. NDAs (6.6) address legal obligations; this control addresses the operational procedures for how transfer actually happens securely.

Suppliers, incident management, and continuity (5.15-5.30)

5.15 Access control. Rules to control physical and logical access to information and processing facilities must be established and implemented, based on business and information security requirements. This is the policy-level control that governs 5.16 through 5.18 and 8.2 through 8.5. A documented access control policy must exist before auditors can evaluate whether individual technical controls (identity management, authentication, access rights) are consistent with an approved framework. Missing the top-level policy is a nonconformity that cascades across every access-related control.

5.16 Identity management. The full lifecycle of identities, creation, maintenance, and deletion, must be managed. This pairs with 5.17 (authentication information) and 5.18 (access rights).

5.17 Authentication information. Management of authentication information must follow a formal management process, including advising personnel to keep authentication information confidential. Initial credential delivery (first-use passwords, shared secrets) is a common gap: sending temporary passwords in plaintext email does not meet this control. A formal process requires secure delivery, mandatory change on first use, and a record that the process was followed.

5.18 Access rights. Provisioning, reviewing, modification, and removal of access rights must follow a documented process, with periodic access reviews.

5.19 Information security in supplier relationships. Requirements for managing information security risks associated with supplier access must be agreed on and documented. The most common audit gap is inherited trust: an organization imposes security requirements on primary suppliers but does not verify that sub-processors used by those suppliers meet equivalent requirements. This is especially relevant in SaaS environments where a supplier may process data on a sub-processor's infrastructure without the customer's explicit awareness.

5.20 Addressing information security in supplier agreements. Relevant security requirements must be included in agreements with suppliers. Standard commercial contracts rarely contain the specifics ISO 27001 auditors look for: incident notification timelines, audit rights, data handling obligations, and rights to terminate on security grounds. Adding a security schedule or data processing addendum to supplier contracts is the standard implementation path.

5.21 Managing information security in the ICT supply chain. Processes for managing security risks in the ICT supply chain must be defined and implemented, including software and hardware components. This control specifically targets the risk of compromised hardware (tampered devices) and software (malicious dependencies, supply-chain attacks similar in pattern to the 2020 SolarWinds incident). Practical implementation includes software bill of materials (SBOM) tracking, hardware procurement from verified sources, and integrity verification of software before deployment.

5.22 Monitoring, review, and change management of supplier services. Supplier performance against security requirements must be regularly monitored and reviewed. Auditors commonly find that initial vetting is thorough but ongoing monitoring does not happen: a supplier assessed at onboarding but not reviewed for three years is a gap. Practical monitoring includes annual review of SOC 2 reports, penetration test summaries, or questionnaire responses from critical suppliers, with a record of the review.

5.23 Information security for use of cloud services (new in 2022). Processes for acquiring, using, managing, and exiting cloud services must be established in line with the organization's security requirements. Cloud services introduce shared responsibility models that require explicit definition of which security obligations belong to the provider and which belong to the customer.

5.24 Information security incident management planning and preparation. The organization must plan for and prepare to handle incidents through defined roles, responsibilities, and procedures. Planning without testing is a common audit observation: incident response plans that have never been exercised provide weaker assurance than exercised plans, even if less polished. Tabletop exercises documented with dates and participants satisfy the preparation requirement more convincingly than documentation alone.

5.25 Assessment and decision on information security events. Security events must be assessed and triaged to determine whether they qualify as incidents. The key evidence auditors seek is a documented triage criteria or decision tree: how does the organization decide whether an event is a reportable incident or a benign anomaly? Without criteria, event assessment is subjective and inconsistent, which is itself a finding under this control.

5.26 Response to information security incidents. Incidents must be responded to in accordance with documented procedures. Response procedures need to address containment, eradication, recovery, and external notification, including regulatory reporting timelines where applicable (for example, GDPR Article 33 requires supervisory authority notification within 72 hours of a personal data breach). Auditors look for evidence that response procedures were actually followed during any real incidents in the audit period, not just that procedures exist.

5.27 Learning from information security incidents. Knowledge gained from incidents must feed back into the risk assessment and control improvements. Post-incident reviews (also called after-action reviews or lessons-learned reports) are the primary evidence. A common audit observation is that reviews are conducted informally and outputs are not tracked to specific control changes or risk register updates; the standard expects a documented link between what was learned and what changed.

5.28 Collection of evidence. Procedures for identifying, collecting, acquiring, and preserving information that can serve as evidence must be defined. Evidence handling is especially relevant if incidents may lead to disciplinary action or legal proceedings, where chain-of-custody failures can make evidence inadmissible. Procedures should specify who may collect evidence, how it is stored (read-only forensic copies, hash verification), and how long it is retained.

5.29 Information security during disruption. Plans must address how information security controls will be maintained during adverse situations, including business continuity events. A common gap is that business continuity plans focus entirely on availability while ignoring confidentiality and integrity: a disaster recovery scenario that bypasses normal access controls or ships unencrypted backups to an offsite location violates this control even if systems are restored on schedule.

5.30 ICT readiness for business continuity (new in 2022). ICT systems supporting critical business functions must be planned, implemented, maintained, and tested to ensure availability during disruption. This control bridges the ISMS with business continuity management system (BCMS) requirements.

Legal and compliance (5.31-5.37)

5.31 Legal, statutory, regulatory, and contractual requirements. Requirements relevant to information security must be identified, documented, and kept current. Organizations operating across jurisdictions face the hardest challenge here: a legal register that covers only the home country while the organization processes data under GDPR, HIPAA, or sector-specific regulations is incomplete. Auditors look for a documented register, evidence it is reviewed when the regulatory environment changes, and traceability from requirements to implemented controls.

5.32 Intellectual property rights. Procedures for protecting intellectual property rights in relation to software and information assets must be implemented. The most common nonconformity is unlicensed software: an inventory check that reveals commercial software installed without valid licenses is a finding under this control. Procedures should include a software asset management process that tracks licenses, version counts, and authorized installation sources.

5.33 Protection of records. Records must be protected from loss, destruction, falsification, unauthorized access, and unauthorized release. Records relevant to the ISMS itself (risk assessments, audit evidence, training records, SoA versions) require particular attention because they are the evidence base for certification. Retention schedules must align with legal requirements and with the audit cycle; deleting records before an auditor can review them is a risk organizations often underestimate.

5.34 Privacy and protection of personal information. Privacy and protection of personally identifiable information (PII) must be ensured as required by relevant legislation and regulation. For organizations subject to GDPR or similar regimes, ISO 27701 (Privacy Information Management) extends this control.

5.35 Independent review of information security. The organization's approach to managing information security must be reviewed independently at planned intervals. "Independent" does not require an external party: an internal audit function separate from the team running the ISMS satisfies the requirement. What it cannot be is a self-assessment by the same team responsible for the ISMS. Review outputs must be documented and fed into the management review (Clause 9.3) and, where findings are significant, into corrective action processes.

5.36 Compliance with policies, rules, and standards for information security. Managers must regularly review compliance with information security policies, procedures, and standards. This control requires active manager-level review, not just a compliance team check. Evidence typically takes the form of manager attestation records, spot-check outputs, or compliance review meetings with documented findings. An organization that relies entirely on IT team self-assessment without line manager involvement is likely to have a gap here.

5.37 Documented operating procedures. Operating procedures for information processing must be documented and made available to all who need them. This control is broader than it appears: it covers not just IT runbooks but any operational procedure that affects information security, including backup procedures, change procedures, and access provisioning workflows. Undocumented tribal knowledge held by one individual creates both a security risk and a nonconformity finding.

Theme 2: People Controls (Controls 6.1-6.8)

People controls cover the full employment lifecycle from pre-hire screening through post-termination obligations. Eight controls, but failures here, inadequate screening, no security training, poor offboarding, account for a disproportionate share of security incidents.

6.1 Screening. Background verification checks must be carried out before hiring or engaging personnel. The depth of screening should match the role's access to sensitive information and systems. Roles with privileged access warrant more thorough checks.

6.2 Terms and conditions of employment. Employment and contractor agreements must state each party's information security responsibilities. This includes confidentiality obligations, acceptable use, and duties that survive termination. Auditors commonly find that employment contracts reference a security policy but the policy itself is not provided to employees at hire, or that contractor agreements are weaker than employee agreements even though contractor access is equivalent. Both are findings under this control.

6.3 Information security awareness, education, and training. All personnel and relevant contractors must receive security awareness training at hire and regularly thereafter, calibrated to their role. One-time onboarding training does not satisfy this control. Auditors look for documented training completion records, not just training materials.

6.4 Disciplinary process. A formal disciplinary process must exist for personnel who violate information security policy. The process must be documented and communicated. The control is satisfied by HR disciplinary procedures that explicitly include security policy violations within their scope; a separate security-specific process is not required. What auditors check is that personnel are aware the process exists and that it has teeth: a process that is documented but never applied provides weak deterrence.

6.5 Responsibilities after termination or change of employment. Security responsibilities and obligations that survive the end of employment, confidentiality agreements, data return, non-disclosure, must be defined, communicated, and enforced. Offboarding checklists should reference these obligations explicitly. A common gap is role-change handling: an employee who moves from a privileged role to a standard role should have elevated access revoked, but access reviews that only trigger at termination will miss this. 5.18 (access rights) and 6.5 must both be addressed in internal transfer procedures.

6.6 Confidentiality or non-disclosure agreements. NDAs or confidentiality agreements reflecting the organization's information protection needs must be in place with personnel and third parties. NDAs without defined terms around information classification, permitted disclosure, and duration are often weaker than they appear. Auditors look for agreements that are specific enough to be enforceable, not generic boilerplate with no reference to the organization's classification scheme or the types of information the person will access.

6.7 Remote working. Security measures for personnel working remotely must be implemented and communicated. This includes equipment security, access controls, and policies for working in public or shared spaces. Remote working policies written pre-pandemic often assumed occasional remote access as an exception; organizations where remote or hybrid work is now the default need to ensure the policy reflects current operating reality. Screen privacy in public locations, VPN requirements, and rules around family member access to work devices are common gaps when policies have not been updated.

6.8 Information security event reporting. Personnel must be required to report observed or suspected information security events through appropriate channels as quickly as possible. Barriers to reporting, fear of blame, unclear escalation paths, are a control failure under 6.8.

Theme 3: Physical Controls (Controls 7.1-7.14)

Physical controls protect premises, equipment, and storage media from unauthorized physical access, damage, and loss.

7.1 Physical security perimeters. Security perimeters must be defined and used to protect areas containing information and processing facilities. Perimeters can include building walls, locked server rooms, reception barriers, and guarded areas. For organizations in co-working or shared office environments, defining the perimeter becomes more complex: if the organization does not control building access, the perimeter must begin at the organization's own space boundary, with compensating controls such as cable locks and screen privacy filters for exposed workstations.

7.2 Physical entry. Secure areas must be protected by appropriate entry controls to ensure only authorized personnel gain access. Entry controls must generate a record: a locked door that anyone with a key can open is weaker than an access control system that logs who entered and when. For server rooms and secure areas, auditors look for visitor logs, access request processes, and periodic review of who holds access credentials, mirroring the access rights review required under 5.18.

7.3 Securing offices, rooms, and facilities. Physical security for offices and facilities must be designed and applied. "Designed and applied" means the physical security approach is intentional and documented, not just ad hoc. Auditors commonly find this control satisfied at the server room level but unapplied to areas where sensitive paper documents or user workstations are located. Floor areas handling confidential information should be covered by the same physical security thinking as server rooms.

7.4 Physical security monitoring (new in 2022). Premises must be continually monitored for unauthorized physical access. Monitoring tools include CCTV, intrusion alarms, and access control logs. The requirement for monitoring is new in 2022; the 2013 version addressed physical entry but not ongoing monitoring.

7.5 Protecting against physical and environmental threats. Physical and environmental threats, fire, flood, earthquake, power failure, vandalism, must be identified and protections put in place. Threat identification must reflect the actual geography and operating environment: an organization in a flood-prone region that does not address flood risk, or one in a seismic zone with no consideration for earthquake resilience, has a gap in the identification step even if fire suppression and power backup are mature. Protections must be proportionate to the risk level identified.

7.6 Working in secure areas. Procedures for working in secure areas must be designed and applied. Procedures typically address unsupervised access, camera restrictions, equipment brought in or out, and escort requirements for visitors. For cloud-only or fully remote organizations with no physical secure area, this control may be excluded from the SoA with documented rationale, but the exclusion must be justified in the context of the ISMS scope.

7.7 Clear desk and clear screen. Clear desk rules for papers and removable storage media, and clear screen rules for information processing facilities, must be defined and implemented. This control addresses the exposure risk from unattended documents and unlocked screens.

7.8 Equipment siting and protection. Equipment must be sited and protected to reduce risks from environmental threats and unauthorized access. For organizations using colocation data centers, this control is partially delegated to the facility provider: the organization should verify that the provider's physical security (raised flooring, fire suppression, cooling redundancy, access controls) meets the required standard, typically evidenced by the provider's SOC 2 or ISO 27001 certification.

7.9 Security of assets off-premises. Off-premises assets, laptops, mobile devices, external drives, must be protected. The organization must define what protection is required when assets leave controlled premises. Full-disk encryption is the baseline for laptop and mobile device protection; without it, physical theft of a device is also a data breach. Policies often specify encryption but do not verify it is active: MDM solutions that enforce and report encryption status on enrolled devices provide the evidence auditors need.

7.10 Storage media. Storage media must be managed through their lifecycle: acquisition, use, transport, and disposal. Encrypted transport and secure destruction at end-of-life (e.g., NIST SP 800-88-compliant wiping or physical destruction) satisfy the disposal requirement.

7.11 Supporting utilities. Equipment must be protected from power failures and other disruptions caused by failures in supporting utilities. For on-premises infrastructure, this means UPS (uninterruptible power supply) for graceful shutdown and generators for extended outages. For cloud-hosted infrastructure, this control is largely inherited from the cloud provider's availability zone design, but the organization must verify the provider's uptime commitments and understand which utility failures are covered by the shared responsibility model.

7.12 Cabling security. Power and telecommunications cabling must be protected from interception, interference, or damage. For modern cloud-first organizations with minimal on-premises infrastructure, this control typically applies to office network cabling and patch panels rather than long-haul communications lines. The most common issue found in office environments is network ports in publicly accessible areas (lobbies, meeting rooms) that are active and unmonitored, creating an easy physical network intrusion point.

7.13 Equipment maintenance. Equipment must be maintained correctly to ensure availability and integrity. Maintenance records are the primary evidence: auditors look for scheduled maintenance programmes, records of who performed maintenance and when, and whether maintenance personnel (particularly external contractors) were authorized and supervised. Unauthorized or unsupervised maintenance of processing equipment is a security risk that this control is specifically designed to address.

7.14 Secure disposal or reuse of equipment. Equipment must be verified to ensure sensitive data and licensed software have been removed or securely overwritten before disposal or reuse.

Theme 4: Technological Controls (Controls 8.1-8.34)

The largest theme, covering technical security measures for endpoints, networks, applications, data, and development environments.

Endpoints and access (8.1-8.6)

8.1 User endpoint devices. Information stored on, processed by, or accessible via user endpoints must be protected. This covers laptops, desktops, tablets, and mobile phones. Disk encryption, endpoint detection tools, and mobile device management (MDM) are common implementation choices.

8.2 Privileged access rights. Privileged access rights must be restricted, managed, and monitored. Privileged accounts should be separate from standard user accounts, used only when elevated access is required.

8.3 Information access restriction. Access to information and system functions must be restricted in accordance with the access control policy. This control requires that the access control policy (5.15) is actually implemented in systems: role-based access control aligned to job functions, with no standing broad access granted "just in case." Auditors look for evidence that access grants are traceable to a business justification and that access to sensitive data is limited to those with a documented need.

8.4 Access to source code. Read and write access to source code, development tools, and software libraries must be appropriately managed. Source code access is often broader than necessary: contractors and junior developers granted write access to production repositories, or former employees whose repository access was not revoked at offboarding, are recurring audit findings. Branch protection rules requiring pull request review and preventing direct commits to main branches are a standard technical control that satisfies the management requirement.

8.5 Secure authentication. Authentication technologies and procedures must be established based on access restrictions and information classification. This includes multi-factor authentication (MFA) for privileged and remote access, and password policies aligned with NIST SP 800-63B guidance (length over complexity, no mandatory rotation without evidence of compromise).

8.6 Capacity management. Capacity requirements must be monitored, adjusted, and projections made to ensure required system performance. Capacity failures are an availability concern that connects to both ISMS objectives and business continuity planning (5.29, 5.30). The control requires forward-looking projections, not just current monitoring: an organization that tracks current utilization but has no process for projecting demand growth against available capacity has a partial implementation.

Operations and protection (8.7-8.15)

8.7 Protection against malware. Protection against malware must be implemented and supported by appropriate user awareness. Technical controls (endpoint detection and response tools, email filtering, web filtering under 8.23) address the automated layer; user awareness (6.3) addresses the human layer. Neither alone is sufficient: an organization with mature endpoint protection but no phishing awareness training, or vice versa, has a partial implementation. Auditors look for evidence that both layers are active and that coverage is verified, not assumed.

8.8 Management of technical vulnerabilities. Technical vulnerabilities must be identified, evaluated, and remediated in a timely manner. This requires a defined patching process with risk-based prioritization and tracking.

8.9 Configuration management (new in 2022). Configurations of hardware, software, services, and networks must be established, documented, implemented, monitored, and reviewed. Configuration drift is a documented source of security vulnerabilities; this control formalizes the requirement to prevent it.

8.10 Information deletion (new in 2022). Information stored in information systems, devices, or other storage media must be deleted when no longer required. This supports both security (reducing exposure) and regulatory compliance (data retention limits).

8.11 Data masking (new in 2022). Data masking must be used in line with the access control policy and applicable legislation. Development and test environments must not use unmasked production data. This applies particularly to environments with PII or financial data.

8.12 Data leakage prevention (new in 2022). Data leakage prevention measures must be applied to systems, networks, and devices that process, store, or transmit sensitive information. DLP tooling combined with data classification (5.12) is the standard implementation path.

8.13 Information backup. Backup copies of information, software, and systems must be maintained and tested in accordance with the agreed backup policy. Testing means actually restoring from backup, not just verifying that backup jobs complete.

8.14 Redundancy of information processing facilities. Facilities must be implemented with sufficient redundancy to meet availability requirements. "Sufficient" is defined by the organization's availability objectives, which should be documented in the ISMS scope or in service level agreements. A single-availability-zone cloud deployment with no failover is less resilient than a multi-region active-active configuration; the right architecture depends on the recovery time objective (RTO) the organization has committed to. Auditors look for evidence that redundancy decisions were made against documented availability requirements, not that a specific architecture was chosen.

8.15 Logging. Logs recording user activities, exceptions, faults, and information security events must be produced, stored, protected, and analyzed. Log retention periods must reflect regulatory and operational requirements.

Monitoring and network security (8.16-8.22)

8.16 Monitoring activities (new in 2022). Networks, systems, and applications must be monitored for anomalous behavior, with actions taken to evaluate potential incidents. This formalizes SIEM or equivalent log analysis capabilities as a requirement, not an optional enhancement.

8.17 Clock synchronization. The clocks of information processing systems must be synchronized to an approved time source. Accurate timestamps are required for log correlation and incident investigation.

8.18 Use of privileged utility programs. Utility programs capable of overriding system or application controls must be restricted and tightly controlled. This covers tools such as database query utilities with direct table access, OS-level diagnostic tools, and network analyzers. The key risk is that these tools can be used to bypass application-layer access controls. Controls include restricting installation to authorized administrators, logging all use, and removing tools from systems where they are not needed for an active operational purpose.

8.19 Installation of software on operational systems. Procedures and measures must be implemented to securely manage software installation on operational systems. Uncontrolled software installation is one of the most common sources of both malware introduction and license compliance failures. Effective implementation typically requires that users do not have local administrator rights on their devices, that an approved software list exists, and that any exception requires an authorization process. MDM or endpoint management tooling provides the technical enforcement layer.

8.20 Networks security. Networks and network devices must be secured, managed, and controlled to protect information in systems and applications. This is the top-level network security policy control, analogous to 5.15 for access control. It must be read alongside 8.21 (network services), 8.22 (network segregation), and 8.23 (web filtering). Common implementation elements include documented network architecture, firewall rule review processes, and configuration standards for network devices. Networks that have grown organically without documented architecture are a frequent gap at Stage 1 audits.

8.21 Security of network services. Security mechanisms, service levels, and management requirements of all network services must be identified, implemented, and monitored. For organizations that use ISP or managed network service providers, this control requires that security requirements are specified in the service agreement and that the provider's performance against those requirements is monitored, aligning with the supplier management controls (5.19 through 5.22). In-house network services require equivalent documentation of their own security configuration and monitoring approach.

8.22 Segregation of networks. Groups of information services, users, and information systems must be segregated in networks. Flat networks where all devices can reach each other directly are a common gap here.

Web, cryptography, and supply chain (8.23-8.30)

8.23 Web filtering (new in 2022). Access to external websites must be managed to reduce exposure to malicious content. Policy-based filtering that blocks known malicious categories while allowing legitimate business access is the standard implementation.

8.24 Use of cryptography. Rules for effective use of cryptography, including key management, must be defined and implemented. This includes encryption standards, key generation, storage, distribution, retirement, and revocation.

8.25 Secure development lifecycle. Rules for secure development of software and systems must be established and applied throughout the development lifecycle. This includes threat modeling, security requirements, code review, SAST/DAST testing, and separation of development, test, and production environments. In NIST CSF 2.0, this control maps to PR.PS (Platform Security), not data-protection subcategories.

8.26 Application security requirements. Information security requirements must be identified, specified, and approved for application development or acquisition. Security requirements need to be defined before development begins, not identified during testing or production. A common failure mode is treating security as a post-development testing gate (caught by 8.29) rather than a design-phase input. Requirements should address authentication, authorization, encryption, audit logging, and data handling, mapped to the sensitivity of the data the application processes.

8.27 Secure system architecture and engineering principles. Principles for engineering secure systems must be established, documented, maintained, and applied to any information system implementation. OWASP guidelines and NIST SP 800-160 are common reference points.

8.28 Secure coding (new in 2022). Secure coding principles must be applied to software development. This includes input validation, output encoding, parameterized queries, error handling, and following the OWASP Top 10 for identifying common vulnerabilities. The control formalizes what many development teams do informally.

8.29 Security testing in development and acceptance. Security testing processes must be defined and implemented in the development and acceptance cycle. Security testing at acceptance is a gate, not an afterthought: SAST (static application security testing) integrated into CI/CD pipelines, DAST (dynamic testing) in pre-production environments, and penetration testing before major releases are the standard implementation layers. Auditors look for evidence that security findings from testing are tracked to resolution, not just that testing was performed.

8.30 Outsourced development. The organization must direct, monitor, and review activities related to outsourced system development. Outsourced development introduces supply chain risk (5.21) and requires the same secure development lifecycle requirements (8.25) to apply to the external team. Contracts should specify secure coding standards, code review requirements, security testing obligations, and the organization's right to audit. Accepting deliverables without security testing because the vendor "says it's secure" is a common and significant gap.

Change management and assets (8.31-8.34)

8.31 Separation of development, test, and production environments. Development, testing, and production environments must be separated and secured. Environment separation prevents accidental or unauthorized changes to production systems and reduces the risk of developer access to production data. A developer with direct database access to production has, in practice, bypassed the access controls that 8.3 requires. Separation is most commonly implemented through separate accounts, separate infrastructure, and access controls that restrict production access to operations roles with specific change management procedures (8.32).

8.32 Change management. Changes to information processing facilities and information systems must be subject to change management procedures. Change management failures are a leading cause of security incidents: an undocumented configuration change that inadvertently opens a firewall port, or a software update deployed without testing, falls under this control. The procedure must address authorization, testing, rollback capability, and post-change review. Emergency change procedures are also required and must not become a routine workaround for bypassing normal controls.

8.33 Test information. Test information must be appropriately selected, protected, and managed. Using production data in test environments without masking is the most common finding under this control, and it intersects with 8.11 (data masking). Realistic test data that does not contain real PII, financial records, or other sensitive information should be generated or anonymized before use in development and test environments. Where production data must be used for testing, it requires the same access controls and protections as production itself.

8.34 Protection of information systems during audit testing. Audit requirements and activities involving verification of operational systems must be carefully planned and agreed to minimize disruptions to business processes. This control governs what auditors and penetration testers are permitted to do on production systems: intrusive testing (active exploitation, load generation) requires explicit authorization and scheduling to avoid causing the very availability or integrity failures it is meant to assess. A written scope agreement signed before any audit or penetration test activity begins on production systems is the standard implementation.

The 11 New Controls at a Glance

If your organization transitioned from the 2013 standard, these 11 controls warrant specific attention in your gap analysis. A control marked "not applicable" without a documented rationale is a finding waiting to happen.

Mapping Annex A to Other Frameworks

For organizations managing multiple compliance obligations, Annex A controls overlap substantially with other frameworks.

Mappings above are illustrative (7 of 93 controls shown). Sources: NIST CSF 2.0 Reference Tool (nist.gov/cyberframework); NIST SP 800-53 Rev. 5 Appendix H (ISO 27001 crosswalk); ISO 27002:2022 Annex B. Verify mappings against primary sources for formal gap analysis.

An organization that has implemented NIST 800-53 controls or holds SOC 2 will find significant overlap with Annex A. A gap analysis comparing existing controls against the Annex A list is faster than starting from scratch. For a structured comparison, see our ISO 27001 vs SOC 2 guide.

Common Mistakes When Implementing Annex A Controls

Treating the SoA as a status tracker rather than a risk document. The SoA must show the connection between each control and a specific risk or legal obligation. An SoA that just lists controls as "implemented" or "not applicable" without rationale will not hold up at audit.

Implementing all 93 controls regardless of scope. Controls that do not address identified risks in your defined ISMS scope add cost without adding security. A cloud-only SaaS company with no physical premises has legitimate grounds to limit several physical controls, provided the rationale is documented.

Marking controls as implemented when they are still partial. Controls partially in place should be documented as "in progress" with a target date. Auditors do not penalize honest in-progress status; they penalize claims of implementation that evidence contradicts.

Underweighting organizational controls. Controls 5.1 through 5.37 are the management foundation. A mature technical posture on top of weak policies and undefined ownership creates an ISMS that works on paper but fails in incidents.

Skipping the new controls on transition. The 11 new controls from 2022 address real gaps, cloud security, configuration drift, data leakage, monitoring, that the 2013 version did not directly require. Carrying over an existing ISMS without reassessing these controls is a gap.

Frequently Asked Questions

How many controls are in ISO 27001:2022 Annex A?

ISO 27001:2022 Annex A contains 93 controls across 4 themes: Organizational (37, controls 5.1-5.37), People (8, controls 6.1-6.8), Physical (14, controls 7.1-7.14), and Technological (34, controls 8.1-8.34). The 2013 version contained 114 controls across 14 domains.

Do I have to implement all 93 controls?

No. ISO 27001 Clause 6.1.3 requires you to evaluate all 93 controls and document your decisions in the Statement of Applicability. Controls outside your scope or not relevant to identified risks can be excluded, but each exclusion requires a written justification. Undocumented exclusions are a nonconformity.

What is the difference between ISO 27001 and ISO 27002?

ISO 27001 is the certifiable standard defining ISMS requirements. ISO 27002 is a guidance document providing implementation advice for each Annex A control. Certification is against ISO 27001. ISO 27002 is a reference used during implementation, not an auditable requirement.

What are the 11 new controls added in 2022?

5.7 (Threat intelligence), 5.23 (Cloud services security), 5.30 (ICT readiness for business continuity), 7.4 (Physical security monitoring), 8.9 (Configuration management), 8.10 (Information deletion), 8.11 (Data masking), 8.12 (Data leakage prevention), 8.16 (Monitoring activities), 8.23 (Web filtering), and 8.28 (Secure coding).

How long does it take to implement Annex A controls?

Implementation timelines depend on your organization's size, existing security maturity, and ISMS scope. The October 2025 transition deadline required organizations certified to the 2013 standard to update their ISMS to the 2022 structure. New certifications vary: a focused scope with some existing controls can reach Stage 1 audit readiness in under a year; a broad scope starting from minimal documentation typically requires longer. See our ISO 27001 certification cost breakdown for related planning data.

Can I include controls not listed in Annex A?

Yes. ISO 27001 Clause 6.1.3(b) explicitly allows organizations to use controls from any source. Annex A is a reference set, not an exhaustive catalog. If your risk assessment identifies a risk that none of the 93 controls adequately addresses, you can and should implement a custom control, documented in the SoA.

Sources

1. ISO, "ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements," iso.org, accessed 2026-05-12. https://www.iso.org/standard/27001
2. ISO, "ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls," iso.org, accessed 2026-05-12. https://www.iso.org/standard/75652.html
3. NIST, "Special Publication 800-63B: Digital Identity Guidelines, Authentication and Lifecycle Management," pages.nist.gov, accessed 2026-05-12. https://pages.nist.gov/800-63-3/sp800-63b.html
4. OWASP, "OWASP Top Ten," owasp.org, accessed 2026-05-12. https://owasp.org/www-project-top-ten/
5. IAF, "IAF Mandatory Document for the Transition of Management System Accreditation and Certification to ISO/IEC 27001:2022 (IAF MD 26:2022)," iaf.nu, accessed 2026-06-23. https://iaf.nu/en/iaf-documents/
6. NIST, "Special Publication 800-88 Rev. 1: Guidelines for Media Sanitization," csrc.nist.gov, accessed 2026-06-23. https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final
7. NIST, "Special Publication 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems," csrc.nist.gov, accessed 2026-06-23. https://csrc.nist.gov/publications/detail/sp/800-160/vol-1-rev-1/final

Last reviewed: 2026-06-23. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.