ISO 27001 Annex A Controls: The Complete 2022 Guide

Key Concept: ISO 27001 Annex A controls — structure, selection, and implementation under the 2022 revision
Reading Time: 14 minutes
Difficulty: Intermediate
Relevant for: Information security managers, compliance officers, CTOs, startup founders pursuing ISO 27001 certification

What Is Annex A in ISO 27001?

When organizations start preparing for ISO 27001 certification, Annex A is usually the first thing that feels overwhelming. It's a reference list of 93 information security controls that your organization must evaluate, select from, and implement based on your specific risks.

Think of Annex A as your security toolbox. Not every tool applies to every organization — a fully remote SaaS company has different needs than a hospital with on-premise servers. The standard doesn't require you to implement all 93 controls. It requires you to assess each one against your risks and justify your decisions in a document called the Statement of Applicability (SoA).

This distinction matters because one of the most common mistakes organizations make is treating Annex A as a checklist to complete rather than a risk-based framework to apply. Your auditor won't ask "did you implement all 93 controls?" They'll ask "can you demonstrate why you selected these controls and how they address your identified risks?"

In this guide, we'll walk through how the 2022 revision restructured these controls, what's new, how to select and document them, and what your auditor actually expects to see.

What Changed from 2013 to 2022

The ISO 27001:2022 revision — published in October 2022 — brought the most significant restructuring of Annex A since the standard's inception. As of October 31, 2025, the transition period has ended. All ISO 27001:2013 certifications have expired, and every organization pursuing or maintaining certification now works exclusively with the 2022 version.

If you're starting fresh, this is good news — you only need to learn one structure. If you transitioned from 2013, you've already navigated these changes. Either way, understanding what changed and why helps you implement controls more effectively.

Structural reorganization

The 2013 version spread 114 controls across 14 domains — categories like Access Control, Asset Management, Communications Security, and Business Continuity. Many controls overlapped between domains, creating confusion about ownership and documentation.

The 2022 revision consolidated everything into four cleaner categories:

A.5 Organizational Controls — 37 controls covering governance, policies, roles, supplier relationships, and incident management
A.6 People Controls — 8 controls covering screening, training, awareness, remote working, and offboarding
A.7 Physical Controls — 14 controls covering facility access, equipment security, environmental protection, and monitoring
A.8 Technological Controls — 34 controls covering access management, encryption, logging, network security, and secure development

This grouping makes it immediately clear who owns what. Organizational controls generally fall to management and compliance teams. People controls belong to HR and training functions. Physical controls go to facilities and operations. Technological controls land with IT and engineering. The mapping from controls to responsible teams is far more intuitive than the 14-domain structure ever was.

Control consolidation

The reduction from 114 to 93 controls doesn't mean security requirements were removed. Instead, 24 controls from the 2013 version were merged where they overlapped. For example, separate controls for network security management and network security services were combined into a single, clearer control. Another 58 existing controls were updated to reflect the current threat landscape — incorporating references to cloud computing, remote work, and modern supply chain risks that barely existed when the 2013 version was written.

11 new controls

The 2022 revision introduced 11 entirely new controls that address threats and technologies that have emerged since 2013. These additions are where the standard catches up with how organizations actually operate today:

A.5.7 Threat intelligence — Collect and analyze information about security threats relevant to your organization. This moves security from purely reactive to proactive, requiring you to maintain awareness of emerging threats in your industry.

A.5.23 Information security for cloud services — Define and monitor security requirements for cloud service usage. Given that most organizations now depend on cloud infrastructure, this formalizes what was previously addressed through scattered controls.

A.5.30 ICT readiness for business continuity — Ensure your technology infrastructure can maintain or restore critical services during disruptions. This goes beyond traditional business continuity by specifically targeting ICT resilience.

A.7.4 Physical security monitoring — Deploy surveillance and monitoring tools to detect unauthorized physical access. This updates physical security for environments with modern monitoring capabilities.

A.8.9 Configuration management — Establish policies for documenting, implementing, monitoring, and reviewing system configurations across your network. Misconfigurations are among the most common causes of security incidents.

A.8.10 Information deletion — Manage data deletion to comply with legal, regulatory, and contractual requirements. This reflects growing data privacy regulations like GDPR that require demonstrable data lifecycle management.

A.8.11 Data masking — Use masking techniques to protect sensitive data, particularly personally identifiable information, during processing or testing.

A.8.12 Data leakage prevention — Implement controls to minimize unauthorized data exposure or transfer. DLP has moved from "nice to have" to a foundational security control.

A.8.16 Monitoring activities — Enhance visibility into system and network behavior to detect security incidents. This formalizes continuous monitoring as a distinct control rather than burying it within other requirements.

A.8.23 Web filtering — Control access to potentially dangerous or inappropriate websites. With the expansion of web-based threats and the 2025 Verizon DBIR finding that 15% of employees access generative AI tools on corporate devices, this control has become increasingly relevant.

A.8.28 Secure coding — Establish secure software development practices to prevent vulnerabilities from being introduced during the development lifecycle.

The attribute taxonomy

One of the most practical additions in the 2022 revision is the attribute taxonomy. Each control now includes a table of attributes that help you categorize and understand how controls fit into your broader security strategy. The five attribute types are:

Control type — Whether the control is preventive (stops incidents from occurring), detective (identifies incidents as they happen), or corrective (limits damage after an incident).

Information security properties — Which aspect of the CIA triad the control protects: confidentiality, integrity, or availability.

Cybersecurity concepts — Maps to the NIST Cybersecurity Framework functions: Identify, Protect, Detect, Respond, or Recover. This makes cross-framework mapping significantly easier for organizations that also align with NIST CSF.

Operational capabilities — Describes which operational function the control supports, such as governance, asset management, identity and access management, or incident management.

Security domains — Groups controls by broad security domains: Governance and Ecosystem, Protection, Defence, or Resilience.

These attributes are optional — your auditor won't require you to use them. But they're enormously helpful for mapping controls to business functions, cross-referencing with other frameworks, and building a Statement of Applicability that clearly communicates your security strategy to stakeholders.

The Four Control Categories in Detail

A.5 Organizational Controls (37 controls)

These controls establish the governance foundation of your Information Security Management System. They cover information security policies, roles and responsibilities, risk management frameworks, incident handling procedures, business continuity requirements, and supplier security management. Strong organizational controls ensure that leadership provides oversight, resources are allocated appropriately, and security responsibilities are clearly defined across the organization.

Three of the 11 new controls fall in this category — threat intelligence (A.5.7), cloud services security (A.5.23), and ICT readiness for business continuity (A.5.30) — reflecting how organizational governance must now explicitly address cloud dependency and proactive threat awareness.

Deep dive: Complete Guide to A.5 Organizational Controls

A.6 People Controls (8 controls)

Human error remains a leading cause of security incidents — the smallest category by control count, but arguably the highest-impact area for prevention. People Controls cover background screening before employment, security awareness and training programs, disciplinary processes, confidentiality agreements, remote working security, and secure offboarding procedures. These controls aim to transform employees from potential security liabilities into your first line of defense.

Deep dive: Complete Guide to A.6 People Controls

A.7 Physical Controls (14 controls)

Physical Controls protect your tangible assets and environments — facilities, equipment, cabling, and storage media. They include physical security perimeters, entry controls, securing offices and rooms, equipment maintenance, and secure disposal of media. One new control in this category — physical security monitoring (A.7.4) — formalizes the use of surveillance technology to detect unauthorized physical access. Even fully remote organizations need to address physical controls for employee home offices, data center providers, and coworking spaces.

Deep dive: Complete Guide to A.7 Physical Controls

A.8 Technological Controls (34 controls)

The largest category forms the technical backbone of your security posture. These controls address user access management, authentication mechanisms, cryptography, system hardening, logging and monitoring, backup strategies, network security, and secure software development. Seven of the 11 new controls sit here — configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding — reflecting the increasing technical sophistication of modern threats.

Deep dive: Complete Guide to A.8 Technological Controls

The Statement of Applicability

The Statement of Applicability is the most important document in your ISO 27001 implementation — it's the bridge between your risk register and your Annex A controls. The SoA lists every Annex A control, marks each as applicable or excluded, provides justification for every decision, and documents how applicable controls are implemented.

Your auditor will use the SoA as their primary navigation tool during certification. It tells them your risk-based rationale for control selection and gives them a roadmap for what evidence to examine. A well-constructed SoA demonstrates that your organization understands its risks and has made deliberate, documented decisions about how to address them — not just copied a template.

For a detailed walkthrough of building your SoA and connecting it to your risk treatment process, see our ISO 27001 Risk Treatment Plan guide.

How to Select and Implement Controls

Controls are never implemented "just in case." Every included control should trace back to an identified risk. Here's the practical process.

Step 1: Map your risks

Start with your risk assessment. Use your risk register to identify actual threats and vulnerabilities facing your organization. A SaaS company processing customer data faces different risks than a manufacturing firm with industrial control systems. Your risk assessment — not the Annex A list — determines which controls matter.

Step 2: Link risks to controls

For each identified risk, find the Annex A control or controls that mitigate it. Some mappings are straightforward: a "shadow IT" risk points directly to A.8.1 (user endpoint devices) and A.8.16 (monitoring activities). Others require multiple controls working together — a "data breach via third-party vendor" risk might require 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), and A.8.12 (data leakage prevention).

Step 3: Decide on inclusion or exclusion

If a control doesn't address any of your identified risks, you can exclude it — but you must document the justification in your SoA. For instance, a fully remote company with no physical office might exclude certain physical access controls while still addressing physical security for employee home offices and cloud data centers. The key is that every exclusion has a documented, defensible rationale.

Step 4: Document your implementation

For each included control, record four things clearly: who owns it (a specific person, not a department), what policy or procedure enforces it, how you implement it in practice, and what evidence proves it's working (logs, reports, screenshots, training records).

A practical example

Take A.6.3 — Information security awareness, education, and training. Here's what proper documentation looks like:

Applicable: Yes
Owner: Head of People
Implementation: All new employees complete security awareness training during their first week. Mandatory annual refresher training covers updated threats and company-specific policies. Training completion is tracked in our HR system with automated reminders for overdue completions.
Evidence: LMS completion logs, attendance records, training materials, internal wiki content, quarterly completion rate reports

Notice what this isn't: it's not a paragraph of aspirational language. It's a concrete description of who does what, when, and how you prove it. That's what your auditor wants to see.

What Your Auditor Will Examine

During your ISO 27001 audit, the auditor uses your Statement of Applicability as their guide. For each applicable control, they'll verify four things: that a specific person owns the control, that a documented policy or procedure governs it, that evidence demonstrates the control is operating as described, and that excluded controls have proper justification.

The most common audit findings relate to gaps between documentation and practice. Organizations write policies describing how things should work, but the auditor finds that actual practice differs. Your compliance management system should help you identify and close these gaps before the auditor arrives — not after.

Stage 1 audits focus heavily on your documentation: policies, the SoA, risk assessment, and ISMS governance requirements (Clauses 4-10). Stage 2 audits verify that your documented controls are actually implemented and effective. Preparing for both stages simultaneously — documentation and operational evidence — saves significant time and reduces the risk of nonconformities.

Common Mistakes to Avoid

After working with organizations through the certification process, certain mistakes appear consistently.

Implementing all 93 controls without risk assessment. The standard explicitly requires risk-based selection. Implementing everything without justification actually demonstrates a lack of understanding — and wastes resources on controls that don't address your actual risks.

Leaving controls without clear ownership. "The IT team" isn't an owner. A specific individual must be accountable for each control's implementation and ongoing effectiveness. When nobody owns a control, nobody maintains it.

Treating the SoA as a formality. The Statement of Applicability isn't a box-ticking exercise. It's the central document that connects your risk assessment to your control selection. A poorly written SoA is the fastest path to audit nonconformities.

Writing policies that don't match practice. Template-based policies that describe an idealized security program rather than your actual operations create immediate audit findings. Write policies that reflect what you actually do, then improve your practices and update the policies accordingly.

Forgetting continuous monitoring. Controls degrade over time. Access lists grow stale, configurations drift, training falls behind. Without regular review and monitoring, controls that passed your initial audit may fail the surveillance audit 12 months later. This is where automated evidence collection and compliance monitoring platforms provide the most value — they catch control degradation before your auditor does.

Building Your Annex A Hub

This guide provides the overview. For detailed implementation guidance on each control category, use our deep-dive guides:

A.5 Organizational Controls (37 controls) — Governance, policies, supplier management, and incident handling
A.6 People Controls (8 controls) — Screening, training, awareness, and offboarding
A.7 Physical Controls (14 controls) — Facility security, equipment protection, and monitoring
A.8 Technological Controls (34 controls) — Access management, encryption, logging, and secure development

For the broader certification process:

ISO 27001 Audit Checklist — Complete preparation guide for Stage 1 and Stage 2 audits
ISO 27001 Internal Audit Guide — Step-by-step process for conducting effective internal audits
Risk Treatment Plan Guide — Building and maintaining your risk treatment documentation
ISMS Workbook: Clauses 4-10 — The governance requirements that auditors examine before Annex A controls

Humadroid helps organizations implement and maintain ISO 27001 controls with AI-powered guidance, automated evidence collection, and a pre-configured control framework that maps directly to the 2022 Annex A structure. No expensive consultants. No spreadsheet chaos. Just genuine compliance at 97% less cost.

February 2026 update: This guide has been substantially expanded with ISO 27001:2022 transition completion context, all 11 new controls explained, the attribute taxonomy system, expanded implementation guidance, and comprehensive cross-linking to our Annex A deep-dive series and ISO certification resources.