# ISO 27001 Annex A Controls
ISO 27001 Annex A is the normative reference catalog of information security controls embedded within the ISO/IEC 27001 standard for information security management systems (ISMS). It exists because organizations cannot effectively manage information security risk without a structured, internationally recognized set of controls to draw from. Without such a catalog, control selection becomes ad hoc, inconsistent across business units, and difficult to audit or defend to regulators, customers, or certification bodies. Annex A solves the problem of control selection arbitrariness by providing a comprehensive, risk-linked menu of safeguards that organizations must evaluate, select, and justify. Critically, Annex A does not dictate which controls every organization must implement. It requires that organizations demonstrate they have considered every control and made a deliberate, documented decision about applicability.
---
ISO 27001 Annex A is a normative annex to the ISO/IEC 27001:2022 standard, meaning it carries mandatory consideration requirements even though the specific controls within it are not all mandatory for every organization. The annex presents 93 controls organized into four thematic categories: Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). The 2022 revision consolidated and restructured the prior 2013 version, which contained 114 controls across 14 domains, reducing redundancy and introducing 11 new controls addressing areas such as threat intelligence, cloud service security, data masking, and ICT continuity.
Annex A is not a standalone security standard. It is best understood as the control reference library that supports an ISMS built to ISO 27001. The detailed implementation guidance for each control lives in the companion standard ISO/IEC 27002:2022, which is informative rather than normative. Organizations are certified against ISO 27001, not ISO 27002.
The 2022 revision introduced control attributes, which are metadata tags that allow organizations to filter and map controls by type (preventive, detective, corrective), security property (confidentiality, integrity, availability), cybersecurity concept (aligned to NIST CSF functions), operational capability, and security domain. These attributes significantly improve an organization's ability to cross-reference Annex A controls against other frameworks such as NIST SP 800-53, CIS Controls, and SOC 2 criteria, reducing duplicated compliance work across multiple standards.
---
The operational mechanics of Annex A begin with the risk assessment process mandated by ISO 27001 Clause 6.1.2. Organizations must identify information assets, assess the threats and vulnerabilities that could affect those assets, determine the likelihood and impact of potential incidents, and calculate resulting risk levels. This risk assessment drives control selection, not the other way around.
Risk Assessment and Control Selection
The organization catalogs its information assets, which may include customer databases, source code repositories, operational technology systems, employee records, or cloud environments. For each asset, the organization identifies relevant threats (such as ransomware, insider theft, or hardware failure) and vulnerabilities (such as unpatched systems or weak access controls). Risk levels are calculated using a defined methodology, most commonly a likelihood-times-impact matrix, producing a risk register.
For each identified risk that exceeds the organization's defined risk appetite, the organization selects one or more Annex A controls to treat that risk. The selection must be traceable: a specific risk in the risk register maps to a specific control in Annex A. For example, a risk of unauthorized access to a financial database might be treated by Annex A control 5.15 (Access control), 5.17 (Authentication information), and 8.5 (Secure authentication).
Statement of Applicability Construction
The Statement of Applicability (SoA) is the central document that lists all 93 Annex A controls, indicates whether each is applicable or excluded, and provides justification for each decision. For included controls, the SoA explains why the control is needed and how it is implemented. For excluded controls, the SoA must justify why the control is not applicable and confirm that the exclusion does not undermine the organization's ability to meet its information security objectives. The SoA is audited directly during ISO 27001 certification assessments; a poorly constructed SoA is one of the most common reasons organizations fail or receive major nonconformities.
Implementation and Evidence Generation
Selected controls are implemented according to the guidance in ISO 27002. Implementation involves technical configuration, policy development, process changes, or some combination. Consider a mid-sized financial services firm implementing Annex A control 8.8 (Management of technical vulnerabilities). The firm must establish a vulnerability scanning schedule, assign ownership for remediation, define acceptable timeframes for patching based on severity, and integrate results into the risk register. The control is not satisfied by simply purchasing a vulnerability scanner; it requires a documented process, assigned roles, and evidence of operation.
Each control should have at least one measurable performance indicator. For control 6.8 (Information security incident management), a relevant metric might be the percentage of security incidents reported within the defined timeframe, or the mean time between incident detection and containment. These metrics serve as the foundation for the monitoring and measurement requirements in ISO 27001 Clause 9.1.
Concrete Implementation Scenario
A software-as-a-service company undergoing ISO 27001 certification identifies a risk of sensitive customer data exposure through misconfigured cloud storage buckets. The risk assessment assigns this a high risk rating. The organization selects controls 5.23 (Information security for use of cloud services), 8.9 (Configuration management), 8.10 (Information deletion), and 8.12 (Data leakage prevention) to treat the risk.
The SoA documents these selections with justification tied directly to the cloud data exposure risk. The organization implements configuration baselines for all cloud storage services, deploys a cloud security posture management (CSPM) tool to detect misconfigurations, establishes a quarterly review process for cloud service security, and trains developers on secure cloud configuration practices.
During the certification audit, the auditor reviews the SoA entry, requests evidence of the CSPM tool output showing compliant configurations, examines training records, and interviews the cloud operations team about the quarterly review process. The traceable chain from risk to control to implementation to evidence is what makes the audit defensible. Without this documented traceability, the organization cannot demonstrate that its control selections are risk-based rather than arbitrary.
Continuous Review and Adaptation
Risk environments change. New threats emerge, business processes shift, and technology stacks evolve. Organizations must reassess risks periodically and following significant changes, then update their control selections and SoA accordingly. An organization that acquires a subsidiary, migrates to a cloud-first architecture, or launches a new product line must treat these as triggers for risk reassessment and potential SoA revision. This is not a one-time exercise; it is an ongoing operational requirement that extends throughout the certification lifecycle.
---
Annex A provides the internationally recognized benchmark against which organizations demonstrate their information security control posture to customers, regulators, partners, and auditors. When a procurement team asks a vendor to confirm ISO 27001 certification, they are asking, in effect, whether that vendor has systematically assessed its information risks and implemented a justified, auditable set of controls. Without a structured control catalog like Annex A, these assurances would be meaningless because there would be no common reference point.
Consequences of Unstructured Control Selection
Organizations that treat security control selection as an informal exercise consistently produce the same failure patterns: overlapping controls in low-risk areas, complete gaps in high-risk areas, no documentation trail linking controls to risks, and inability to demonstrate due diligence when an incident occurs. When a breach happens, regulators and litigants ask what controls were in place and how the organization decided they were sufficient. An undocumented, unstructured control environment cannot answer that question.
The 2017 Equifax breach illustrates the consequences of control selection failures. The breach stemmed from an unpatched Apache Struts vulnerability that had been known for months. An effective implementation of what is now Annex A control 8.8 (Management of technical vulnerabilities) would have required a defined patch management process with ownership and timelines. The absence of such a structured control contributed directly to a breach affecting 147 million individuals and resulting in settlements exceeding $700 million.
Common Misconceptions and Pitfalls
The most persistent misconception is that ISO 27001 certification proves an organization is secure. It does not. Certification means the organization has implemented a management system that systematically addresses information security risk, including a justified selection of controls. A certified organization with poor security hygiene is possible if the organization selects minimal controls or implements them poorly. The standard ensures a process exists; it does not guarantee outcomes.
A second common misconception is that Annex A is a checklist to be completed once. It is a living reference that must be revisited as risks and business contexts change. Organizations that treat their SoA as a one-time exercise produce stale, inaccurate documentation and fail surveillance audits when auditors discover that the documented control set no longer reflects the actual operational environment.
Organizations also frequently underestimate the ongoing effort required to maintain evidence of control operation. Implementing a control is different from operating a control, which is different from proving a control operates effectively over time. The evidence generation and maintenance burden can be substantial, particularly for organizations with limited security operations resources.
---
CDA approaches ISO 27001 Annex A through the Risk Governance and Assurance (RGA) domain of the Planetary Defense Model. The RGA domain treats compliance not as a periodic certification exercise but as a continuous operational state. CDA's foundational methodology, Perpetual Compliance Assurance (PCA), operationalizes the principle that compliance is not an event. It is a state.
In practice, this means CDA does not wait for an annual internal audit or a scheduled certification assessment to evaluate control effectiveness. Instead, CDA structures its engagements so that Annex A control performance is continuously monitored, with real-time or near-real-time indicators mapped to each selected control. When a control degrades, whether because a patch management process falls behind schedule, a privileged access review is missed, or a configuration baseline drifts, the deviation is captured immediately rather than discovered months later during an audit preparation sprint.
CDA's SoA development process differs from standard consulting approaches in two specific ways. First, CDA maps every SoA entry not only to the risk that justifies the control but also to the evidence artifacts that demonstrate ongoing control operation. This means the SoA functions as a living assurance document, not a static declaration. Second, CDA aligns Annex A control selections to cross-framework mappings from the outset, connecting each control to relevant NIST SP 800-53 controls, CIS Controls, and where applicable, MITRE ATT&CK techniques. This cross-mapping allows organizations to satisfy multiple compliance requirements from a single control implementation rather than managing separate control sets for each framework.
For organizations in regulated industries, CDA's PCA approach produces a significant operational advantage: when a regulator or customer requires evidence of control operation, the organization can produce current, timestamped evidence immediately rather than reconstructing it retrospectively. This is not a documentation exercise; it is an operational posture that reduces audit burden, accelerates third-party assurance processes, and produces measurable reductions in compliance overhead over time.
---
---
---