Overview

Annex A controls are the 93 information security controls listed in Appendix A of ISO 27001:2022 that organizations can select from to address identified information security risks. They represent internationally recognized security best practices organized into four themes: Organizational, People, Physical, and Technological.

What it means in practice

Think of Annex A as a comprehensive menu of security controls. Based on your risk assessment, you select which controls to implement from this menu. You're not required to implement all 93 - only those that address risks identified in your specific context.

Real-world example: If your risk assessment identifies employee misuse of data as a risk, you might select A.5.10 (Acceptable use policy), A.6.3 (Security awareness training), and A.8.15 (Logging and monitoring). If you're cloud-only, you might exclude A.7.1-A.7.14 (Physical controls) as not applicable to your infrastructure.

The four control themes

Organizational controls (A.5.1 - A.5.37) - 37 controls

Management-level controls for governance, policies, risk management, asset management, supplier security, incident management, business continuity, and compliance.

Key examples:

  • A.5.1 - Policies for information security

  • A.5.7 - Threat intelligence

  • A.5.9 - Inventory of information and assets

  • A.5.19 - Information security in supplier relationships

  • A.5.24 - Information security incident management planning

People controls (A.6.1 - A.6.8) - 8 controls

Controls managing human-related security risks throughout the employment lifecycle from hiring through termination.

Key examples:

  • A.6.1 - Screening (background checks)

  • A.6.3 - Information security awareness, education and training

  • A.6.7 - Remote working

  • A.6.8 - Information security event reporting

Physical controls (A.7.1 - A.7.14) - 14 controls

Controls protecting the physical environment where information assets are stored or processed.

Key examples:

  • A.7.1 - Physical security perimeters

  • A.7.2 - Physical entry controls

  • A.7.4 - Physical security monitoring

  • A.7.10 - Storage media management

Technological controls (A.8.1 - A.8.34) - 34 controls

Technical and IT security controls including access management, cryptography, network security, secure development, and vulnerability management.

Key examples:

  • A.8.2 - Privileged access rights

  • A.8.5 - Secure authentication

  • A.8.8 - Management of technical vulnerabilities

  • A.8.13 - Information backup

  • A.8.16 - Monitoring activities

Control distribution: Most organizations implement 40-70 controls depending on size, complexity, and risk profile. Small cloud-native startups might implement fewer physical controls, while regulated enterprises typically implement 80+ controls.

Changes from ISO 27001:2013

Restructured and consolidated

The 2022 version reduced 114 controls in 14 domains to 93 controls in 4 themes, making the framework cleaner and more logical.

11 new controls for modern threats

  • A.5.7 - Threat intelligence

  • A.5.23 - Information security for use of cloud services

  • A.8.9 - Configuration management

  • A.8.10 - Information deletion

  • A.8.11 - Data masking

  • A.8.12 - Data leakage prevention

  • A.8.16 - Monitoring activities

  • A.8.23 - Web filtering

  • A.8.28 - Secure coding

  • A.7.4 - Physical security monitoring

  • A.8.9 - Configuration management

24 controls merged

Related controls from 2013 were consolidated to reduce duplication. For example, several access control requirements were combined into streamlined controls.

Transition note: If you're certified under ISO 27001:2013, you must transition to the 2022 control structure by October 31, 2025. This requires remapping your Statement of Applicability to the new numbering and addressing any new controls relevant to your risks.

How to select controls

Step 1: Complete risk assessment

Identify information security risks your organization faces. Controls are selected to address these risks, not implemented blindly.

Step 2: Determine control applicability

For each identified risk, review Annex A to find controls that would reduce the risk to acceptable levels.

Step 3: Consider risk treatment options

You can treat risks through:

  • Control implementation: Apply Annex A controls to reduce risk

  • Risk avoidance: Eliminate the risky activity

  • Risk transfer: Use insurance or outsource to third parties

  • Risk acceptance: Formally accept risks below your threshold

Step 4: Document in Statement of Applicability

Create your SoA listing all 93 controls with inclusion/exclusion status and justifications based on risk assessment.

Step 5: Implement selected controls

Deploy included controls with appropriate scope, timing, and resources based on risk priority.

Control selection tip: Start with foundational controls that enable others - policies (A.5.1), asset inventory (A.5.9), access control (A.5.15), backup (A.8.13), and monitoring (A.8.16). These create infrastructure supporting other controls.

Control implementation guidance

ISO 27002:2022 companion standard

While ISO 27001 lists control objectives, ISO 27002 provides detailed implementation guidance for each control including purpose, implementation guidance, and related information.

Control attributes in ISO 27002

The 2022 version introduced control attributes helping you understand:

  • Control type: Preventive, detective, or corrective

  • Information security properties: Confidentiality, integrity, availability

  • Cybersecurity concepts: Identify, protect, detect, respond, recover

  • Operational capabilities: Which security functions the control supports

  • Security domains: Governance, protection, defense, resilience

Tailoring controls to context

ISO 27001 expects controls to be implemented proportionally. A 10-person startup's "secure coding" (A.8.28) will differ from a bank's approach, but both can be compliant if appropriate to their risk and context.

Proportionality example: For A.6.3 (Security awareness training), a small organization might conduct monthly lunch-and-learn sessions, while a large enterprise might deploy a learning management system with role-based curricula, quarterly phishing simulations, and certification programs. Both satisfy the control if appropriate to their size and risk.

Common control implementation patterns

High-priority controls for most organizations

Based on common risk profiles, these controls are typically included:

  • Organizational: A.5.1 (Policies), A.5.9 (Asset inventory), A.5.15 (Access control), A.5.24 (Incident management)

  • People: A.6.3 (Training), A.6.8 (Incident reporting)

  • Technological: A.8.2 (Privileged access), A.8.5 (Authentication), A.8.8 (Vulnerability management), A.8.13 (Backup), A.8.16 (Monitoring)

Controls often excluded

Depending on context, organizations commonly exclude:

  • Physical controls (A.7.x): Cloud-only organizations with no data centers

  • Development controls (A.8.25-A.8.34): Organizations that don't develop software

  • Supplier controls (A.5.19-A.5.22): Organizations with minimal third-party dependencies

Exclusion scrutiny: Auditors carefully examine control exclusions. Generic justifications like "not applicable" or "not relevant" are insufficient. Reference specific risk assessment findings or organizational characteristics (e.g., "Cloud-only architecture validated in risk assessment RA-2024-001").

Organizational controls deep dive (A.5.x)

Information security policies (A.5.1 - A.5.4)

  • A.5.1 - Policies for information security

  • A.5.2 - Information security roles and responsibilities

  • A.5.3 - Segregation of duties

  • A.5.4 - Management responsibilities

Contact management (A.5.5 - A.5.6)

  • A.5.5 - Contact with authorities

  • A.5.6 - Contact with special interest groups

Threat and project management (A.5.7 - A.5.8)

  • A.5.7 - Threat intelligence

  • A.5.8 - Information security in project management

Asset management (A.5.9 - A.5.14)

  • A.5.9 - Inventory of information and other associated assets

  • A.5.10 - Acceptable use of information and other associated assets

  • A.5.11 - Return of assets

  • A.5.12 - Classification of information

  • A.5.13 - Labelling of information

  • A.5.14 - Information transfer

Access control (A.5.15 - A.5.18)

  • A.5.15 - Access control

  • A.5.16 - Identity management

  • A.5.17 - Authentication information

  • A.5.18 - Access rights

Supplier relationships (A.5.19 - A.5.23)

  • A.5.19 - Information security in supplier relationships

  • A.5.20 - Addressing information security within supplier agreements

  • A.5.21 - Managing information security in the ICT supply chain

  • A.5.22 - Monitoring, review and change management of supplier services

  • A.5.23 - Information security for use of cloud services (NEW in 2022)

Incident management (A.5.24 - A.5.28)

  • A.5.24 - Information security incident management planning and preparation

  • A.5.25 - Assessment and decision on information security events

  • A.5.26 - Response to information security incidents

  • A.5.27 - Learning from information security incidents

  • A.5.28 - Collection of evidence

Business continuity (A.5.29 - A.5.30)

  • A.5.29 - Information security during disruption

  • A.5.30 - ICT readiness for business continuity

Compliance (A.5.31 - A.5.37)

  • A.5.31 - Legal, statutory, regulatory and contractual requirements

  • A.5.32 - Intellectual property rights

  • A.5.33 - Protection of records

  • A.5.34 - Privacy and protection of PII

  • A.5.35 - Independent review of information security

  • A.5.36 - Compliance with policies and standards for information security

  • A.5.37 - Documented operating procedures

Evidence requirements for controls

What auditors verify

For each included control, auditors request evidence that:

  • Control exists: Documented policies, procedures, or configurations

  • Control operates: Records, logs, or outputs showing ongoing operation

  • Control is effective: Results demonstrate risk reduction (e.g., vulnerability scans show patching effectiveness)

Evidence examples by control type

  • Policy controls: Approved policy documents, acknowledgment records

  • Process controls: Procedure documents, checklists, workflow tickets

  • Technical controls: Configuration screenshots, system logs, scan reports

  • Training controls: Training completion records, test scores, attendance logs

Evidence collection strategy: Don't wait until audit to gather evidence. Implement systematic evidence collection as part of control operation - quarterly access reviews generate evidence for A.5.18, backup job logs provide evidence for A.8.13, training completion reports support A.6.3.

Additional controls beyond Annex A

When Annex A isn't enough

If your risk assessment identifies risks not adequately addressed by the 93 standard controls, you can implement additional controls specific to your context.

Documenting additional controls

List additional controls in your Statement of Applicability or maintain a supplemental control register. Clearly link them to specific risks they address.

Examples of additional controls

  • Industry-specific controls (PCI DSS requirements for payment processors)

  • Regulatory requirements (HIPAA controls for healthcare)

  • Emerging technology controls (AI/ML security not fully covered in standard)

  • Organization-specific risks (unique operational or geographic risks)

Getting help

Accelerate control selection and implementation with ISMS Copilot. Get guidance on which controls address your specific risks, generate implementation documentation, and create evidence collection plans for audit readiness.

Was this helpful?