AuditXYZ

Lesson 2 of 5

ISO 27001 Annex A Controls: A Complete Guide

14 min readIntermediate

ISO 27001 Annex A Controls

Annex A is the reference set of information security controls that ISO 27001 provides. The 2022 revision reorganized these controls from 14 domains into four themes, consolidating the total from 114 to 93 controls while adding 11 new ones. Understanding Annex A is essential for building an effective ISMS — and for producing the Statement of Applicability your auditor will scrutinize line by line.

Before diving in, fix the most misunderstood point about Annex A in your mind: it is a reference list, not a checklist. The mandatory requirements of ISO 27001 are clauses 4 through 10. Annex A exists so that when you treat your risks, you compare your chosen controls against a comprehensive catalogue and confirm nothing necessary was omitted. You implement the controls your risks demand, and you justify — control by control — anything you exclude. Organizations that skip the risk assessment and simply "implement Annex A" invert the standard's logic, and experienced auditors notice.

What Changed in 2022

The 2013 edition had 114 controls in 14 domains (A.5 through A.18). The 2022 edition restructured everything:

  • 14 domains became 4 themes, numbered 5 through 8
  • 114 controls became 93 — none were deleted outright; 57 were merged into 24 consolidated controls, 23 were renamed, and 58 carried over essentially intact
  • 11 genuinely new controls were added for modern practices (cloud, threat intel, DLP, and more)
  • Five attributes were introduced as metadata on every control: control type (preventive/detective/corrective), information security properties (confidentiality/integrity/availability), cybersecurity concepts (identify/protect/detect/respond/recover), operational capabilities, and security domains. Attributes let you slice the catalogue for mappings — for example, filtering controls by NIST CSF-style functions.

The transition from 2013 certificates completed in October 2025, so the 2022 structure is now the only game in town. Any template, tool, or consultant still speaking in "A.9 Access Control" terms is working from the retired edition.

The Four Control Themes

ThemeControlsFocusTypical Owner
5 — Organizational37Policies, roles, asset and access governance, suppliers, incidents, continuity, legal/compliance, cloudLeadership, compliance, IT management
6 — People8Screening, employment terms, awareness, discipline, remote work, event reportingPeople ops / HR
7 — Physical14Perimeters, entry, equipment, media, utilities, clear deskOffice/facilities, IT
8 — Technological34Endpoints, access rights, crypto, logging, vulnerabilities, networks, development, DLPEngineering, IT, security

Theme 5: Organizational Controls (37)

The largest theme, covering the governance layer: information security policies (5.1), roles and responsibilities (5.2–5.4), threat intelligence (5.7), asset inventory and acceptable use (5.9–5.11), information classification and labelling (5.12–5.13), access control policy and identity management (5.15–5.18), supplier relationships and cloud services (5.19–5.23), incident management planning through evidence collection (5.24–5.28), business continuity and ICT readiness (5.29–5.30), and legal, privacy, and IP compliance (5.31–5.37).

For a SaaS company the heavy lifts here are usually supplier management (a real vendor inventory with risk-tiered reviews, not a spreadsheet from 2023), asset and data classification actually applied to systems and repositories, and incident management with documented, tested procedures. Auditors love 5.37 (documented operating procedures) as a probe: they pick a process your policy describes and ask the operator to walk through it.

Theme 6: People Controls (8)

Small but disproportionately audited, because evidence gaps are easy to find: background screening (6.1) for new hires, security terms in employment contracts (6.2), security awareness training (6.3) with completion records, disciplinary process (6.4), post-termination responsibilities (6.5), confidentiality agreements (6.6), remote working (6.7) — effectively universal now, so expect scrutiny of endpoint and home-working safeguards — and event reporting by personnel (6.8), meaning staff know how and where to report something suspicious. Auditors test 6.8 by simply asking random employees; brief your team.

Theme 7: Physical Controls (14)

Perimeters and entry controls (7.1–7.2), securing offices and facilities (7.3), physical security monitoring (7.4, new in 2022), protection against environmental threats (7.5), clear desk and clear screen (7.7), equipment siting, off-premises assets, and storage media (7.8–7.10), supporting utilities and cabling (7.11–7.12), maintenance (7.13), and secure disposal or reuse of equipment (7.14).

Cloud-first companies do not get to wave this theme away. Your offices still hold laptops and people; your remote workforce makes off-premises equipment (7.9) and media handling relevant; and the data center controls you inherit from AWS, Azure, or GCP must be documented as supplier-provided, with their audit reports (SOC 2, ISO certificates) collected as evidence. "Not applicable — we use the cloud" is a justification auditors reject; "implemented via cloud provider, verified through their assurance reports" is the defensible framing.

Theme 8: Technological Controls (34)

The engineering theme: user endpoint devices (8.1), privileged access rights (8.2), access restriction and source code access (8.3–8.4), secure authentication (8.5), capacity management (8.6), malware protection (8.7), technical vulnerability management (8.8) — a frequent finding generator; you need scanning and evidenced remediation SLAs — configuration management (8.9), information deletion, data masking, and DLP (8.10–8.12), backup (8.13), redundancy (8.14), logging and monitoring (8.15–8.16), clock sync (8.17), privileged utilities and software installation (8.18–8.19), network security, segregation, and web filtering (8.20–8.23), cryptography (8.24), and the secure development lifecycle (8.25–8.34): secure coding, security testing, outsourced development, environment separation, change management, and test data.

For product companies, the SDLC block (8.25–8.34) is where most implementation effort lands — and where mature engineering practice pays off, since code review, CI pipelines, environment separation, and dependency scanning map almost one-to-one onto the controls.

The 11 New Controls in 2022

These reflect the decade of change since 2013 and deserve explicit attention in your gap analysis, since older programs will not have them:

ControlNamePractical Implication
5.7Threat intelligenceCollect and act on threat info — advisories, vendor feeds, ISACs; even lightweight processes count if documented
5.23Security for use of cloud servicesPolicy and process for acquiring, using, managing, and exiting cloud services
5.30ICT readiness for business continuityTested ICT continuity — your DR plan, RTO/RPO, and exercises
7.4Physical security monitoringSurveillance/intrusion detection for premises
8.9Configuration managementEnforced secure baselines — IaC and drift detection fit naturally
8.10Information deletionDelete data when no longer required, including on customer request
8.11Data maskingMask/pseudonymize where warranted — especially production data in lower environments
8.12Data leakage preventionMeasures against unauthorized exfiltration — DLP tooling or compensating controls
8.16Monitoring activitiesMonitor networks/systems for anomalous behaviour — alerting, not just log storage
8.23Web filteringManage access to malicious external sites
8.28Secure codingEstablished secure coding principles in the SDLC

Selecting Controls: Risk First, Annex A Second

The correct sequence, and the one clause 6.1.3 actually requires:

  1. Run your risk assessment — identify risks to confidentiality, integrity, and availability of information in scope.
  2. Choose treatments — for risks you decide to modify, determine the controls needed. Design freely; you are not restricted to Annex A wording.
  3. Compare against Annex A — check all 93 controls to verify no necessary control was overlooked. This is Annex A's formal role.
  4. Produce the Statement of Applicability — every control marked applicable or excluded, with justification and implementation status. The SoA gets its own lesson.

Legitimate exclusions are narrow and factual: no in-house software development can exclude parts of 8.25–8.34 (though outsourced development, 8.30, may then apply); no physical data centers shifts 7.x controls to supplier assurance rather than exclusion. Expect a typical SaaS company to mark 85 to 93 controls applicable. An SoA with dozens of exclusions signals a scoping problem, not efficiency.

A Practical Implementation Order

For a cloud-first company building from a reasonable base:

  1. Governance spine first (5.1–5.4, 5.9–5.13): policies, roles, asset inventory, classification — everything else references these.
  2. Identity and access (5.15–5.18, 8.2–8.5): SSO, MFA, provisioning/deprovisioning, access reviews, privileged access. Highest risk reduction per hour spent.
  3. People controls (6.1–6.8): fold screening, contracts, and training into onboarding so they run automatically.
  4. Core technical hygiene (8.1, 8.7–8.9, 8.13, 8.15–8.16): MDM, vulnerability management, configuration baselines, backup, logging and monitoring.
  5. Suppliers and cloud (5.19–5.23): vendor inventory, risk-tiered reviews, cloud service policy, provider assurance reports.
  6. Incident response and continuity (5.24–5.30, 8.14): plans written, then exercised — the test evidence is what auditors want.
  7. SDLC controls (8.25–8.34): formalize what engineering already does; close gaps like test data handling and environment separation.
  8. Remainder by risk: physical monitoring, DLP, masking, web filtering, and the long tail as your risk register dictates.

Annex A Readiness Checklist

  • Risk assessment completed before control selection — not after
  • All 93 controls dispositioned in the SoA with justification and status
  • Exclusions are factual (activity genuinely absent), not convenience-based
  • Cloud-inherited physical controls documented as supplier-provided with assurance reports on file
  • The 11 new 2022 controls explicitly gap-assessed
  • Each applicable control has a named owner and identified evidence source
  • Access reviews, vulnerability remediation, and training operating on a schedule with records
  • Incident response and ICT continuity plans tested within the last 12 months
  • Supplier inventory current, with security reviews for critical vendors
  • SDLC controls mapped to actual engineering workflow (PRs, CI gates, environment separation)
  • Control-to-evidence mapping loaded into your compliance platform for continuous monitoring

Frequently Asked Questions

Do we have to implement all 93 controls?

No. You implement the controls your risk assessment and obligations make necessary, and justify exclusions in the SoA. In practice most organizations implement the large majority — but the reasoning must run risk-first, and auditors will probe whether your exclusion justifications hold.

Are the Annex A controls mandatory or is only clauses 4–10 mandatory?

Clauses 4–10 are unconditionally mandatory. Annex A is mandatory as a comparison reference: you must consider every control and document your determination in the SoA. An applicable-but-unimplemented control without a treatment plan is a nonconformity.

How do the 2022 themes map to the old 2013 domains?

ISO published a full mapping in ISO 27002:2022's annexes. Roughly: old domains A.5–A.6, A.8 (partly), A.9 (policy side), A.13 (partly), A.15–A.18 landed in organizational; A.7 became people; A.11 became physical; and A.9 (technical side), A.10, A.12–A.14 became technological. Every 2013 control has a 2022 home — nothing was truly deleted.

What is the relationship between Annex A and ISO 27002?

Identical control list, different depth. Annex A gives one-line control statements; ISO 27002:2022 gives several pages of implementation guidance per control, plus the attribute tables. Treat 27002 as the implementation manual — it is the best money you will spend on the project after the standard itself.

Which controls generate the most audit findings?

Consistently: 8.8 technical vulnerability management (scans exist, remediation evidence does not), 5.18/8.2 access rights (stale accounts, missing reviews), 6.3 awareness training (incomplete records), 5.19–5.22 supplier management (outdated inventories, no reviews), and 8.13 backup (backups run, restores never tested). Note that all five are operational discipline failures, not missing technology.

Can compliance automation platforms handle Annex A for us?

They accelerate it substantially — prebuilt control mappings, continuous technical checks, evidence collection, and SoA scaffolding. What they cannot do is your risk assessment, your applicability judgments, or the organizational controls that live in human process. Use the platform for instrumentation; keep the reasoning in-house.

In the next lesson, we will cover the Statement of Applicability in detail.


Platform choice determines how much Annex A evidence collects itself. AuditXYZ helps you compare compliance automation platforms on ISO 27001 depth and find auditors experienced with the 2022 control set.