Annex A Unmasked: Every Control Domain, Its Attack Surface Relevance, and Its Most Common Implementation Failure
"A lock is only as strong as the door it's on."
- Security proverb
Introduction: The Most Misread Document in Information Security
Annex A is the part of ISO 27001 that most organizations go to first. Before the risk assessment is complete, before the scope is properly defined, before the methodology is documented - someone opens the standard, turns to Annex A, and starts building a spreadsheet. It feels productive. It looks like progress. It is frequently the first mistake.
Annex A is not a to-do list. It is not a minimum security standard. It is not a catalogue of controls that every organization must implement. It is a reference control set - a structured compendium of security controls that an organization should consider when designing its risk treatment, with the requirement that every control be either applied or explicitly, justifiably excluded.
The distinction matters enormously in practice. Organizations that treat Annex A as a checklist implement controls that don't address their actual risks, invest disproportionately in controls that satisfy auditors rather than managing threats, and develop a compliance culture that treats the form of security as a substitute for its substance. Organizations that treat Annex A as a reference - applying it downstream of a genuine risk assessment - build control environments that are proportionate, defensible, and genuinely protective.
This chapter walks through all 93 controls of ISO 27001:2022 Annex A across the four themes - Organizational, People, Physical, and Technological - with analysis of each control's purpose, its attack surface relevance, how it typically fails in practice, and what good implementation actually looks like.
Part 1 - The 2022 Restructure: Understanding the New Architecture
1.1 From 114 to 93: What Changed and Why
The 2013 version of ISO 27001 organized 114 controls across 14 domains. The 2022 version reorganized these into 93 controls across 4 themes. The reduction in control count does not represent a reduction in scope - most of the "reduction" reflects the merging of controls that addressed overlapping concerns. Eleven genuinely new controls were added to address threats and technologies that the 2013 version had not adequately covered.
The four themes replace the domain structure:
| Theme | Controls | Focus |
|---|---|---|
| Organizational (5.x) | 37 | Policies, processes, governance, supplier relationships, information handling |
| People (6.x) | 8 | Human resources security - screening, training, awareness, offboarding |
| Physical (7.x) | 14 | Physical and environmental security |
| Technological (8.x) | 34 | Technical controls - access, cryptography, operations, development |
The reorganization reflects a more coherent understanding of how controls relate to each other. Organizational controls address the governance and process layer. People controls address the human layer. Physical controls address the environmental layer. Technological controls address the technical layer. These layers are interdependent - a strong technical access control can be undermined by a weak organizational process for removing access when employment ends, which in turn reflects a people control failure in offboarding.
1.2 The New Attribute System
Each control in the 2022 Annex A is tagged with five attribute sets. These attributes are not requirements - they are analytical tools that help organizations filter and organize the control set for specific purposes.
Control type: Preventive (reduces the likelihood of an incident), Detective (identifies that an incident has occurred), Corrective (restores security after an incident). Most controls are preventive; detective and corrective controls are often underweighted in practice, which is why many organizations discover incidents late and recover slowly.
Information security properties: Which of the CIA triad the control primarily addresses - Confidentiality, Integrity, Availability. Most controls address confidentiality; integrity and availability controls deserve explicit attention.
Cybersecurity concepts: Alignment with the NIST Cybersecurity Framework functions - Identify, Protect, Detect, Respond, Recover. This attribute facilitates alignment with NIST CSF for organizations that use both frameworks.
Operational capabilities: The security capability the control supports - governance, asset management, information protection, human resource security, physical security, system and network security, and so on.
Security domains: Governance and ecosystem, protection, defence, resilience.
For GRC practitioners mapping ISO 27001 controls to other frameworks - NIST CSF, SOC 2, DORA, NIS2 - these attributes provide the most direct path to alignment analysis.
Part 2 - Organizational Controls (5.1–5.37)
The 37 organizational controls cover the broadest range of the four themes - from the foundational policy requirement to the sophisticated threat intelligence and information security event management controls that sit at the top of the security maturity curve.
5.1 - Information Security Policies
Purpose: Establish the governance foundation - a set of policies approved by management, communicated to staff, and reviewed at defined intervals.
Attack surface relevance: Policies are not a direct attack surface, but their absence or inadequacy creates indirect exposure everywhere. Without a clear information classification policy, employees don't know how to handle sensitive data. Without an acceptable use policy, employees don't know what is and isn't permitted. Without a clear incident reporting policy, incidents aren't reported.
Common failure: Policies exist as documents rather than practices. They are approved by the CISO and filed in a SharePoint site that nobody knows about. They use generic template language that doesn't reflect the organization's actual context. They haven't been reviewed since the last certification. The surest test: ask any employee what the organization's information classification scheme is. If they cannot answer, the classification policy has not been communicated.
What good looks like: A small, coherent policy framework - a top-level information security policy, plus supporting policies for specific domains (access control, cryptography, acceptable use, incident management, supplier security) - that is written in language appropriate for its audience, reviewed annually, integrated into onboarding, and visibly referenced in operational decisions.
5.2 - Information Security Roles and Responsibilities
Purpose: Ensure that security responsibilities are defined, allocated, and communicated. Every security activity must have an identified owner.
Attack surface relevance: Ambiguous accountability is one of the most exploitable organizational weaknesses. Threat actors study organizations before attacking them. An organization where nobody is clearly responsible for supplier security, or where access review is nobody's explicit job, has gaps that sophisticated attackers will find and exploit.
Common failure: Roles are defined in the ISMS documentation but not reflected in job descriptions, performance objectives, or operational practice. Asset owners exist on paper but have never been told what asset ownership requires of them.
What good looks like: Security responsibilities are embedded in job descriptions and performance reviews for every role with security accountability. Asset owners receive specific guidance on what ownership means - they know their assets, participate in risk assessments affecting those assets, and are the decision-makers for access and sharing requests.
5.3 - Segregation of Duties
Purpose: Prevent a single individual from having the ability to both commit and conceal a fraudulent or malicious act by separating conflicting responsibilities.
Attack surface relevance: Segregation of duties failures are a primary enabler of insider fraud. If the same person can create a supplier, approve a payment, and process the transaction, a single compromised account can enable financial fraud. If the same person manages security monitoring and has administrative access to the systems being monitored, they can both attack and conceal.
Common failure: Segregation of duties is treated as a finance and audit concern rather than a security control. The IT administrator who manages the Active Directory also manages the SIEM system that would detect unauthorized AD changes. The developer who writes code also deploys it to production.
What good looks like: A documented analysis of conflicting duties across high-risk roles - particularly in IT administration, finance, and privileged access management - with compensating controls where true segregation is impractical due to team size.
5.4 - Management Responsibilities
Purpose: Require management at all levels to actively support information security within their areas of responsibility.
Common failure: Management responsibilities for security are not included in performance objectives. Security is treated as something the security team does, not something managers are accountable for in their own domains.
5.5 - Contact with Authorities
Purpose: Maintain appropriate contacts with relevant law enforcement, regulatory authorities, and emergency services, so that when incidents occur, the organization knows who to contact and how.
Attack surface relevance: GDPR requires notification to supervisory authorities within 72 hours of becoming aware of a personal data breach. NIS2 requires initial notification within 24 hours for significant incidents. Organizations that don't know who their regulatory contacts are will miss these timelines.
Common failure: The contacts exist in a document that is not accessible to the incident response team at 2:00 AM when a breach is discovered.
5.6 - Contact with Special Interest Groups
Purpose: Maintain contact with security forums, professional associations, and information sharing communities relevant to the organization's sector.
Common failure: This control is treated as a checkbox - a few professional memberships are noted and the control is marked as implemented. The value of the control lies in active participation: attending briefings, consuming shared intelligence, contributing incident data.
5.7 - Threat Intelligence (New in 2022)
Purpose: Collect, analyze, and use threat intelligence relevant to the organization's information security risks.
Attack surface relevance: This is one of the most significant additions to the 2022 standard. Organizations without a threat intelligence capability are flying blind - their risk assessments are based on generic threat categories rather than the specific techniques, targets, and tools of the actual threat actors targeting their sector.
Common failure: Threat intelligence is conflated with vulnerability scanning or generic security news. True threat intelligence is specific, actionable, and relevant - it tells the organization something specific about threats that are relevant to its assets, and it feeds into risk assessment updates, detection rule tuning, and incident response planning.
What good looks like: A defined threat intelligence process that identifies relevant sources (ISACs, government advisories, vendor intelligence feeds, OSINT), assigns responsibility for consumption and analysis, and produces regular briefings for the security team and management.
5.8 - Information Security in Project Management
Purpose: Integrate information security into the organization's project management methodology so that security requirements are identified and addressed before systems or processes go live.
Attack surface relevance: Security technical debt is almost always created at project initiation - when a new system is designed without security requirements, the resulting vulnerabilities are baked in and expensive to remediate after the fact.
Common failure: Security is a late-stage gate review rather than an early-stage design input. The project team builds the system, then asks the security team to review it before launch. The review identifies issues. The project is already late and over budget. The security issues are documented as post-launch remediation items and then deferred indefinitely.
5.9 - Inventory of Information and Other Associated Assets
Purpose: Identify and maintain an inventory of information assets and their owners.
Common failure: The inventory exists but is incomplete (shadow IT, cloud sprawl), out of date, or insufficiently detailed (systems listed without their data classification, ownership, or criticality rating).
5.10 - Acceptable Use of Information and Other Associated Assets
Purpose: Define rules for the acceptable use of information assets - what employees may and may not do with organizational information and systems.
Common failure: The policy is written for a technology landscape that no longer exists - it addresses email and web browsing but not cloud services, personal devices, AI tools, or remote working environments.
5.11 - Return of Assets
Purpose: Ensure that employees and other personnel return all organizational assets upon termination or change of employment.
Common failure: The offboarding process addresses device return but misses digital assets - cloud service credentials, personal copies of organizational data, access to SaaS services subscribed personally rather than through IT.
5.12 - Classification of Information
Purpose: Classify information according to its sensitivity and value so that it receives appropriate protection.
Common failure: Classification schemes are too complex - four or five levels when two or three would serve. Classification is a paper exercise - information is theoretically classified but the classification has no operational consequence. Classification is applied to documents but not to data in systems and databases where most sensitive information actually resides.
5.13 - Labelling of Information
Purpose: Apply information labels in accordance with the classification scheme so that the classification is visible to handlers.
Common failure: Labelling is applied to new documents but not to the legacy document estate. Labels are applied inconsistently. Electronic labelling uses metadata that is stripped when documents are shared externally.
5.14 - Information Transfer
Purpose: Ensure that information transferred within and outside the organization is adequately protected.
Common failure: Transfer policies exist for formal channels but not for the informal channels employees actually use (personal email, WhatsApp, USB drives, personal cloud storage).
5.15 - Access Control
Purpose: Establish rules for controlling access to information and systems based on business and security requirements.
Attack surface relevance: Access control failures are involved in the majority of significant security incidents. Excessive permissions, unreviewed access rights, shared credentials, and inadequate authentication are among the most exploited vulnerabilities.
Common failure: Access rights accumulate over time without review - employees change roles, accumulate permissions from previous roles, and eventually have far more access than their current role requires. Access reviews are conducted annually and treated as rubber-stamp exercises.
5.16 - Identity Management
Purpose: Manage the full lifecycle of identities - creation, maintenance, and removal - for people and systems accessing the organization's information assets.
Common failure: Stale accounts - former employees, former contractors, service accounts for decommissioned systems - persist in the directory long after the associated access should have been removed.
5.17 - Authentication Information
Purpose: Control the management of authentication information (passwords, keys, certificates, tokens) so that it is kept secure throughout its lifecycle.
Attack surface relevance: Credential theft and misuse are involved in the majority of external breaches. Weak passwords, reused passwords, shared credentials, hardcoded credentials in code, and unmanaged service account passwords are among the most exploited attack vectors.
Common failure: Password policies focus on complexity rules rather than length. Multi-factor authentication is deployed for external access but not for internal systems. Development and test environments contain hardcoded credentials stored in version control.
5.18 - Access Rights
Purpose: Manage the provisioning, modification, and removal of access rights in accordance with the access control policy.
Common failure: Access provisioning is well-controlled but access modification and removal are not. Role changes don't trigger access review. Leavers' accounts are disabled but not deleted - and the disable process sometimes doesn't cover SaaS services subscribed outside of IT's visibility.
5.19 - Information Security in Supplier Relationships
Purpose: Protect the organization's assets that are accessible to or handled by suppliers.
Attack surface relevance: Supply chain attacks have become one of the dominant breach vectors. A supplier with access to organizational systems or data is an extension of the attack surface - their security posture is as relevant as the organization's own.
Common failure: Supplier security is managed contractually but not operationally - nobody verifies whether suppliers are actually meeting those requirements. The supplier security questionnaire is completed at onboarding and never revisited.
5.20 - Addressing Information Security Within Supplier Agreements
Purpose: Establish information security requirements in supplier contracts.
Common failure: Security clauses are generic - copied from a template and included in every contract regardless of the supplier's risk profile. They use vague language that is impossible to audit.
5.21 - Managing Information Security in the ICT Supply Chain
Purpose: Address information security risks associated with the ICT products and services supply chain.
Attack surface relevance: Software supply chain attacks - the compromise of software build pipelines, update mechanisms, or open-source dependencies - have emerged as one of the most sophisticated attack vectors. The SolarWinds attack, the Kaseya attack, and Log4Shell are high-profile examples.
Common failure: ICT supply chain risk is treated as a procurement decision rather than an ongoing security concern. Software dependencies are not inventoried or monitored for vulnerabilities.
5.22 - Monitoring, Review and Change Management of Supplier Services
Purpose: Regularly monitor, review, and manage changes to supplier services to ensure continued compliance with security requirements.
Common failure: Supplier review is conducted annually as a management review input rather than continuously. Changes to supplier services - new sub-processors, changes to data handling practices, significant security incidents at the supplier - are not systematically monitored.
5.23 - Information Security for Use of Cloud Services (New in 2022)
Purpose: Establish processes for the acquisition, use, management, and exit from cloud services, addressing the security requirements specific to cloud environments.
Attack surface relevance: Cloud services introduce unique security considerations - shared responsibility models, multi-tenancy risks, data sovereignty concerns. The 2013 version had no specific cloud control; the 2022 addition reflects how central cloud services have become.
Common failure: Organizations assume that using a major cloud provider (AWS, Azure, GCP) means security is handled. The shared responsibility model is misunderstood - cloud providers secure the infrastructure; customers are responsible for securing their configurations, data, identities, and applications. Misconfigured cloud storage has been the direct cause of numerous significant data exposures.
5.24 - Information Security Incident Management Planning and Preparation
Purpose: Plan and prepare for information security incident management, establishing roles, responsibilities, processes, and communication channels before an incident occurs.
Common failure: Incident response plans exist as documents but have never been tested through exercises. The plan contains contact information that is out of date. It assumes system availability (the plan is stored on the network that has just been encrypted by ransomware). Key decisions - when to involve law enforcement, when to notify regulators - have not been pre-authorized.
5.25 - Assessment and Decision on Information Security Events
Purpose: Establish criteria for assessing security events and determining whether they constitute incidents requiring a formal response.
Common failure: Every security event is either escalated (overwhelming incident response capacity) or dismissed (causing genuine incidents to be missed). The criteria for escalation are vague and inconsistently applied.
5.26 - Response to Information Security Incidents
Purpose: Respond to information security incidents in accordance with documented procedures.
Common failure: Response procedures cover technical containment and eradication but not the full incident lifecycle - business continuity during the incident, communications management, regulatory notification, legal preservation requirements.
5.27 - Learning from Information Security Incidents
Purpose: Use the knowledge gained from incidents to reduce future risk.
Common failure: Post-incident reviews focus on what happened rather than why it happened and what systematic changes would prevent recurrence. The risk register is not updated to reflect the risk information the incident has revealed.
5.28 - Collection of Evidence
Purpose: Define and implement procedures for the identification, collection, acquisition, and preservation of evidence relating to information security incidents.
Common failure: Log retention periods are too short to support incident investigations - many attacks have dwell times of weeks or months. Evidence collection is not conducted with forensic integrity - systems are touched before they are imaged, chains of custody are not maintained.
5.29 - Information Security During Disruption
Purpose: Plan for the maintenance or restoration of information security at an appropriate level during a disruption.
Common failure: Business continuity plans address operational resilience but not security resilience - there is no documented plan for maintaining security controls during a disruption.
5.30 - ICT Readiness for Business Continuity (New in 2022)
Purpose: Plan, implement, maintain, and test ICT readiness to ensure information availability at the required level during disruption.
Common failure: ICT business continuity planning and information security are managed in organizational silos. Backup procedures exist but have not been tested. Ransomware recovery has not been specifically rehearsed.
5.31 - Legal, Statutory, Regulatory, and Contractual Requirements
Purpose: Identify and document the legal, statutory, regulatory, and contractual requirements relevant to information security.
Common failure: Requirements are listed but their implications for specific controls are not analyzed - knowing that GDPR applies is not the same as understanding which controls GDPR requires.
5.32 - Intellectual Property Rights
Purpose: Implement appropriate procedures to protect intellectual property rights in relation to information assets.
Common failure: Software licensing is not tracked. Open-source license obligations are not assessed for software incorporated into products.
5.33 - Protection of Records
Purpose: Protect records from loss, destruction, falsification, unauthorized access, and unauthorized release, in accordance with legal, statutory, regulatory, and contractual requirements.
Common failure: Retention schedules exist but are not operationalized - data is retained indefinitely because nobody has implemented deletion procedures.
5.34 - Privacy and Protection of Personal Information
Purpose: Identify and meet the requirements for the preservation of privacy and protection of personal information in accordance with applicable legislation and regulation.
Common failure: Privacy and security are managed by different teams with limited coordination. Data protection impact assessments (DPIAs) required by GDPR are not connected to the ISMS risk assessment process.
5.35 - Independent Review of Information Security
Purpose: Review the organization's information security management approach independently at planned intervals or when significant changes occur.
Common failure: Internal audit has insufficient security expertise to conduct meaningful reviews of technical controls. Third-party assessments are conducted by consultants who were also involved in implementation.
5.36 - Compliance with Policies, Rules, and Standards for Information Security
Purpose: Regularly review compliance of information processing and procedures with information security policies, rules, and standards.
Common failure: Compliance review is limited to documentation - checking that policies exist rather than verifying that they are followed.
5.37 - Documented Operating Procedures
Purpose: Document operating procedures for information processing facilities and make them available to all who need them.
Common failure: Procedures are undocumented - critical operations depend on tribal knowledge held by specific individuals. Procedures are documented but not maintained - they describe how systems worked two technology generations ago.
Part 3 - People Controls (6.1–6.8)
The eight people controls address the human dimension of information security - from hiring through active employment to departure. This is the smallest theme numerically but addresses the largest attack surface: people.
6.1 - Screening
Purpose: Conduct background verification checks on candidates for employment, contractors, and third parties commensurate with the sensitivity of their role.
Attack surface relevance: Insider threat begins at hiring. An individual who joins with malicious intent or with undisclosed factors that create vulnerability represents a risk that background screening can identify or deter.
Common failure: Screening is applied inconsistently - senior employees and executives are not screened, or are screened less rigorously, despite often having the greatest access. Contractors and third-party staff with privileged access are not screened at all.
6.2 - Terms and Conditions of Employment
Purpose: Establish contractual security obligations for employees and contractors.
Common failure: Security obligations are buried in lengthy employment contracts that employees sign without reading. Specific obligations - confidentiality, acceptable use, incident reporting, post-employment restrictions - are not called out clearly.
6.3 - Information Security Awareness, Education, and Training
Purpose: Ensure that all personnel receive appropriate security awareness training and that individuals with security responsibilities have the skills required for their roles.
Attack surface relevance: This is the control that most directly addresses the human attack surface. Effective security awareness training reduces susceptibility to phishing and social engineering, improves secure handling of sensitive information, and increases the likelihood that security incidents are reported promptly.
Common failure: Annual compliance training that employees click through in 20 minutes without engaging. Training content that is generic rather than role-specific. Training completion is measured as the security metric, rather than behavioral change.
What good looks like: A layered training program - baseline awareness for all staff, role-specific training for high-risk roles (finance, HR, IT administrators, developers), simulated phishing campaigns used to identify and address specific vulnerabilities, and just-in-time training triggered by specific events.
6.4 - Disciplinary Process
Purpose: Establish a formal disciplinary process for employees who have violated information security policies.
Common failure: The disciplinary process exists in HR policy but security policy violations are not recognized as disciplinary triggers. Major violations are handled inconsistently based on seniority.
6.5 - Responsibilities After Termination or Change of Employment
Purpose: Ensure that information security responsibilities that survive employment are clearly communicated and enforced.
Common failure: Post-employment obligations are in the employment contract but are never discussed at offboarding. Former employees retain copies of organizational information on personal devices used for work.
6.6 - Confidentiality or Non-Disclosure Agreements
Purpose: Use confidentiality or NDA agreements to protect organizational information shared with employees, contractors, and third parties.
Common failure: NDAs are generic, use standard template language, and are not tailored to the specific information being protected. Enforcement mechanisms are not considered.
6.7 - Remote Working
Purpose: Implement security measures to protect information accessed, processed, or stored at remote working locations.
Attack surface relevance: Remote work dramatically expanded the attack surface from 2020 onward. The home network is typically far less controlled than the corporate network. Physical security of screens and documents in home environments is typically lower than in offices.
Common failure: Remote working security policy was developed hastily during pandemic response and has not been reviewed since. The policy does not address the use of personal devices for work, despite the fact that personal device use is widespread.
6.8 - Information Security Event Reporting
Purpose: Establish a mechanism through which employees can report observed or suspected information security events, weaknesses, and incidents.
Attack surface relevance: During attacker dwell time, employees may observe indicators of compromise. A reporting culture that makes it easy and safe to report suspicions significantly reduces dwell time.
Common failure: The reporting mechanism exists but is not communicated. Employees who report incidents are not given feedback, which removes the reinforcement that encourages future reporting.
Part 4 - Physical Controls (7.1–7.14)
7.1 - Physical Security Perimeters
Purpose: Define and implement security perimeters to protect areas containing sensitive information and information processing facilities.
Common failure: Physical security perimeters are defined for data centers but not for areas where sensitive work is routinely conducted - finance offices, HR areas, legal departments.
7.2 - Physical Entry
Purpose: Control physical access to secure areas through appropriate entry controls.
Common failure: Access control lists for secure areas are not regularly reviewed. Former employees' physical access credentials are not revoked promptly. Tailgating is not prevented or detected.
7.3 - Securing Offices, Rooms, and Facilities
Purpose: Design and implement physical security for offices, rooms, and facilities.
Common failure: Clean desk policies exist but are not enforced. Whiteboards containing sensitive information are not cleared at end of day.
7.4 - Physical Security Monitoring (New in 2022)
Purpose: Continuously monitor premises for unauthorized physical access.
Common failure: CCTV covers entry points but not internal areas where equipment and media are stored. Out-of-hours access - the most significant risk period - is not specifically monitored.
7.5 - Protecting Against Physical and Environmental Threats
Purpose: Protect against physical and environmental threats - fire, flood, earthquake, other natural disasters, power disruption.
Common failure: Environmental monitoring is implemented in the primary data center but not in secondary facilities.
7.6 - Working in Secure Areas
Purpose: Design and implement security measures for working in secure areas.
Common failure: Procedures for working in secure areas are documented but not enforced - unescorted contractors work in server rooms, mobile devices are used in secure areas.
7.7 - Clear Desk and Clear Screen
Purpose: Define and implement clear desk and clear screen rules to prevent unauthorized access to sensitive information.
Common failure: Policy exists but behavioral compliance is not monitored. Automatic screen locks are configured with timeout periods that are too long.
7.8 - Equipment Siting and Protection
Purpose: Protect equipment from environmental threats and unauthorized access through appropriate siting.
Common failure: Server room environmental controls are not monitored with alerting. Power protection has not been tested under real failure conditions.
7.9 - Security of Assets Off-Premises
Purpose: Protect assets taken off-site from the security risks of working outside organizational premises.
Common failure: Laptops are encrypted but mobile phones and tablets are not. There is no requirement to report lost or stolen devices promptly.
7.10 - Storage Media
Purpose: Manage the lifecycle of storage media - acquisition, use, transportation, and disposal - throughout its use.
Attack surface relevance: Storage media that is disposed of without secure erasure is a direct confidentiality risk. High-profile data breaches have resulted from hard drives removed from decommissioned servers being resold without erasure.
Common failure: Media disposal procedures exist for centrally managed equipment but not for endpoint devices. Printers with internal storage - which retain copies of documents printed - are not included in the media disposal process.
7.11 - Supporting Utilities
Purpose: Protect information processing facilities from power failures and other disruptions caused by failures in supporting utilities.
Common failure: Power protection is implemented for primary systems but not for secondary systems, networking equipment, or physical security systems.
7.12 - Cabling Security
Purpose: Protect power and telecommunications cabling from interception, interference, or damage.
Common failure: Cabling is protected in data centers but not in office areas - network ports in meeting rooms and reception areas can be used for unauthorized network access.
7.13 - Equipment Maintenance
Purpose: Maintain equipment correctly to ensure continued availability and integrity.
Common failure: Maintenance is conducted on primary equipment but not on backup systems - backup power systems and disaster recovery infrastructure may fail precisely when they are needed.
7.14 - Secure Disposal or Re-Use of Equipment
Purpose: Verify that all sensitive data has been deleted or overwritten prior to disposal or reuse of equipment.
Common failure: Standard operating system deletion or formatting is used rather than secure overwrite - standard deletion does not remove data from storage media and the data is recoverable with readily available tools.
Part 5 - Technological Controls (8.1–8.34)
8.1 - User Endpoint Devices
Purpose: Protect information stored on, processed by, or accessible through user endpoint devices.
Common failure: Endpoint protection is deployed on managed corporate devices but not on personal devices used for work. Endpoints that have not received updates or have had security software disabled continue to access corporate resources.
8.2 - Privileged Access Rights
Purpose: Restrict and manage the use of privileged access rights.
Attack surface relevance: Privileged accounts are the primary target of sophisticated attackers. Compromising a single privileged account can provide the access needed to navigate the entire environment, deploy ransomware, exfiltrate data, or persist undetected.
Common failure: Privileged accounts are used for daily tasks (email, web browsing) alongside administrative tasks. Privileged access is not logged or monitored with the intensity the risk warrants.
What good looks like: Separate privileged accounts used exclusively for administrative tasks. Just-in-time privileged access granted for specific tasks and revoked immediately afterward. Comprehensive logging of all privileged access activity with alerting for anomalous patterns.
8.3 - Information Access Restriction
Purpose: Restrict access to information and application functions in accordance with the access control policy.
Common failure: Access is controlled at the system level but not at the data level. Users have access to all customer records when their role only requires access to their own portfolio.
8.4 - Access to Source Code
Purpose: Restrict access to program source code and associated development tools and libraries.
Attack surface relevance: Source code is a high-value target for intellectual property theft and for supply chain attacks - malicious modifications can introduce backdoors that are then distributed through the software to customers.
Common failure: Source code repositories are accessible to all developers regardless of whether they work on the relevant codebase. Secrets - API keys, credentials, encryption keys - are hardcoded in source code stored in version control.
8.5 - Secure Authentication
Purpose: Implement secure authentication technologies and procedures based on information access restrictions.
Attack surface relevance: Authentication is the primary gatekeeping mechanism for information access. Credential stuffing, password spraying, phishing for credentials, and brute force attacks all target the authentication layer.
Common failure: Multi-factor authentication is deployed selectively - external access requires MFA but internal systems do not, and attackers who gain initial access can pivot without MFA friction.
8.6 - Capacity Management
Purpose: Monitor and adjust the use of resources to ensure required system performance and availability.
Common failure: Capacity planning addresses normal operations but not incident response - when a major incident occurs, the logging, monitoring, and forensic tools required for response may be resource-constrained.
8.7 - Protection Against Malware
Purpose: Implement controls to protect against malware.
Common failure: Antimalware is deployed on endpoints but not on servers, network appliances, or cloud workloads. Detection is signature-based and does not detect novel or fileless malware.
8.8 - Management of Technical Vulnerabilities
Purpose: Manage technical vulnerabilities of information systems by obtaining timely information about vulnerabilities, assessing exposure, and taking appropriate action.
Attack surface relevance: Unpatched vulnerabilities are the second most commonly exploited attack vector after credential compromise. The time between vulnerability disclosure and exploitation has shortened dramatically - in some cases, exploit code is available within hours of a CVE being published.
Common failure: Patching processes address operating systems and major applications but miss firmware, network devices, IoT devices, and third-party libraries. Patch testing cycles are so long that critical patches are not deployed within any reasonable timeframe.
8.9 - Configuration Management (New in 2022)
Purpose: Define, document, implement, monitor, and review configurations - including security configurations - for hardware, software, services, and networks.
Common failure: Security baselines exist on paper but configuration drift is not detected or corrected. Cloud infrastructure configurations are not assessed against security benchmarks. Configuration changes are made without change management process.
8.10 - Information Deletion (New in 2022)
Purpose: Delete information stored in information systems, devices, or in any other storage media when no longer required.
Common failure: Retention schedules are defined but deletion is not operationalized - data accumulates indefinitely. Deletion is performed on primary storage but not on backups, archived copies, or secondary systems.
8.11 - Data Masking (New in 2022)
Purpose: Use data masking in accordance with applicable policies and regulations to limit exposure of sensitive data.
Common failure: Production data is used in development and test environments without masking, exposing sensitive personal data, financial data, or health data to development staff and contractors.
8.12 - Data Leakage Prevention (New in 2022)
Purpose: Apply data leakage prevention measures to systems, networks, and devices that process, store, or transmit sensitive information.
Common failure: DLP tools are deployed but in monitoring mode rather than blocking mode. DLP policies are too broad (too many false positives) or too narrow (genuine leakage is not detected).
8.13 - Information Backup
Purpose: Maintain and regularly test backup copies of information, software, and systems.
Attack surface relevance: Backup integrity is the primary determinant of ransomware recovery outcomes. Organizations with tested, isolated, current backups recover from ransomware. Organizations without them pay the ransom or lose their data.
Common failure: Backups are taken but never tested. Backups are not isolated from the production environment - ransomware encrypts backups along with production data.
8.14 - Redundancy of Information Processing Facilities
Purpose: Implement redundancy in information processing facilities to meet availability requirements.
Common failure: Redundancy is implemented for primary systems but not for security systems - SIEM, identity providers, and MFA systems may lack the redundancy of the production systems they protect.
8.15 - Logging
Purpose: Produce, store, protect, and analyze logs that record activities, exceptions, faults, and other relevant events.
Attack surface relevance: Logs are the primary forensic record of security events. Many significant regulatory requirements - GDPR breach notification, NIS2 incident reporting - require an assessment of the scope and nature of an incident that is impossible without adequate logs.
Common failure: Log coverage is incomplete. Log retention is too short - 30-day retention is inadequate for investigating attacks with multi-month dwell times. Logs are not centralized. Log integrity is not protected - logs stored on compromised systems may be tampered with.
8.16 - Monitoring Activities (New in 2022)
Purpose: Monitor networks, systems, and applications to detect anomalous behavior and potential information security incidents.
Common failure: Monitoring is alert-based rather than behavioral - it detects known bad signatures but misses novel attacks. Alerts are generated in volumes that overwhelm the team's capacity to investigate.
8.17 - Clock Synchronization
Purpose: Synchronize the clocks of information processing systems with approved time sources.
Common failure: Inconsistent clocks can cause certificate validation failures, authentication failures, and Kerberos authentication breakdowns. Log correlation during incident investigation depends on accurate timestamps across all systems.
8.18 - Use of Privileged Utility Programs
Purpose: Control and restrict the use of utility programs that are capable of overriding system and application controls.
Common failure: Powerful system utilities are available to all users with administrative access rather than being restricted to specific authorized use cases. Their use is not logged or alerted on.
8.19 - Installation of Software on Operational Systems
Purpose: Implement secure procedures for installing software on operational systems.
Common failure: Users have local administrator rights that allow them to install software without IT approval - a primary vector for malware introduction and shadow IT.
8.20 - Networks Security
Purpose: Secure networks and network devices to protect information in systems and applications.
Common failure: Network segmentation is implemented at the perimeter but not internally - once an attacker is inside the network, they can reach most systems without further authentication. East-west traffic is not monitored.
8.21 - Security of Network Services
Purpose: Identify, implement, and monitor security mechanisms for network services.
Common failure: Security requirements for network services are defined at procurement but not monitored throughout the service lifecycle.
8.22 - Segregation of Networks
Purpose: Segregate groups of information services, users, and information systems within networks.
Attack surface relevance: Network segmentation limits the blast radius of a successful attack. An attacker in a flat network can typically reach domain controllers, database servers, and financial systems without encountering additional access controls.
Common failure: Development, test, and production environments are not properly segregated. Operational technology (OT) and IT networks are not segmented.
8.23 - Web Filtering (New in 2022)
Purpose: Manage access to external websites to reduce exposure to malicious content.
Common failure: Web filtering is deployed but exceptions are granted liberally. SSL inspection is not implemented, so encrypted traffic - which now represents the majority of web traffic - is not filtered.
8.24 - Use of Cryptography
Purpose: Define and implement rules for the effective use of cryptography to protect information.
Common failure: Legacy systems use deprecated algorithms (MD5, SHA-1, DES, RC4). Encryption key management is inadequate - keys are not rotated or are accessible to a broader set of personnel than necessary.
8.25 - Secure Development Lifecycle
Purpose: Establish rules for the secure development of software and systems.
Attack surface relevance: The application layer is the most commonly targeted attack surface for web-facing systems. SQL injection, cross-site scripting, insecure deserialization, and authentication flaws account for a substantial proportion of application-layer breaches.
Common failure: Security requirements are defined for the product but not for the development process. Security testing is conducted at the end of the development cycle, creating pressure to release with known vulnerabilities.
8.26 - Application Security Requirements
Purpose: Identify, specify, and approve information security requirements when developing or acquiring applications.
Common failure: Security requirements are generic rather than application-specific. Acquired applications are not assessed against security requirements before deployment.
8.27 - Secure System Architecture and Engineering Principles
Purpose: Establish, document, maintain, and apply the principles for engineering secure systems throughout all information system development activities.
Common failure: Security architecture principles exist at a strategic level but are not translated into practical engineering guidance that development teams can apply.
8.28 - Secure Coding (New in 2022)
Purpose: Apply secure coding principles to software development.
Common failure: Secure coding training is provided during onboarding but not refreshed as languages, frameworks, and threat landscapes evolve. Static analysis tools are available but not integrated into the development pipeline.
8.29 - Security Testing in Development and Acceptance
Purpose: Define and implement security testing processes in the development and acceptance lifecycle.
Common failure: Security testing is a single penetration test conducted before major releases rather than a continuous activity integrated into the development pipeline. Automated security testing (SAST, DAST, dependency scanning) is not integrated into the CI/CD pipeline.
8.30 - Outsourced Development
Purpose: Direct, monitor, and review activities relating to outsourced software development.
Common failure: Security requirements for outsourced development are defined in the contract but not verified during development. Code produced by outsourced developers is not reviewed for security issues before integration.
8.31 - Separation of Development, Test, and Production Environments
Purpose: Separate development, testing, and production environments and protect them appropriately.
Common failure: Developers have access to production environments for "support" purposes. Production data is used in test environments without sanitization.
8.32 - Change Management
Purpose: Apply change management procedures to changes to information processing facilities and systems.
Common failure: Change management is applied to planned changes but not to emergency changes. Changes are reviewed for operational impact but not for security impact.
8.33 - Test Information
Purpose: Appropriately select, protect, and manage test information.
Common failure: Production data - customer personal data, financial records, health data - is used in test and development environments without anonymization or pseudonymization. This is both a security control failure and, where personal data is involved, a GDPR violation.
8.34 - Protection of Information Systems During Audit Testing
Purpose: Plan and agree on audit tests and other assurance activities involving assessment of operational systems to minimize disruption to business processes.
Common failure: Audit tools that are used in production environments are not controlled - they may introduce vulnerabilities, cause system instability, or generate log noise that interferes with real monitoring.
Part 6 - Putting Annex A Into Practice
6.1 The Control Implementation Sequence
A practical sequencing approach for Annex A implementation:
Foundation controls first: Some Annex A controls are prerequisites for others. The asset inventory (5.9) must exist before risk assessment can be meaningful. The access control policy (5.15) must be defined before access rights (5.18) can be provisioned correctly. Identify the dependency chains and build in the right order.
High-visibility controls early: Controls that are visible to employees - the information security policy, the acceptable use policy, the awareness training program - have broad organizational impact and send a signal that the ISMS is real.
High-risk controls urgently: If the risk assessment identifies critical risks, the controls that address them are not part of a phased implementation plan - they are urgent remediation items.
6.2 The Control Evidence Framework
For each implemented control, the ISMS must be able to produce evidence that the control exists, is operational, and is effective:
| Evidence Type | Examples |
|---|---|
| Policy / procedure | Documented policy, signed acknowledgement records |
| Technical configuration | System screenshots, configuration exports, tool reports |
| Process records | Meeting minutes, approval records, review logs |
| Training records | Completion records, assessment results |
| Testing records | Penetration test reports, vulnerability scan results, backup test records |
| Monitoring records | Log extracts, alert records, incident records |
Building the evidence framework at implementation - not retrospectively before an audit - is the discipline that separates genuinely operational ISMSs from compliance theater.
Summary: What Chapter 4 Has Established
Annex A is not a checklist. It is a structured reference set of 93 controls across four themes - Organizational, People, Physical, and Technological - that represents the accumulated security knowledge of the standards community about how organizations should protect information.
Every control has a purpose, an attack surface dimension, and a characteristic failure mode. Understanding all three - not just the purpose, but how it typically fails - is what separates practitioners who implement controls effectively from those who implement them formally.
The 11 new controls in the 2022 version - threat intelligence, cloud services, configuration management, information deletion, data masking, data leakage prevention, physical security monitoring, monitoring activities, web filtering, secure coding, and ICT readiness for business continuity - collectively address the most significant gaps in the 2013 version and reflect the evolved threat landscape of the 2020s.
The risk-driven approach to Annex A - selecting controls because they address identified risks, not because they appear on a list - is the intellectual discipline that makes the difference between a compliant ISMS and an effective one.
Next: Chapter 5 - The Documentation Architecture: What Must Exist, What Must Be Proven, and What Kills Certifications
© ISO 27001 Wiki - For CISOs, Security Analysts, and GRC Professionals