ISO 27001 Annex A Controls: Enterprise Implementation Guide

The 2022 restructure did more than renumber the controls. It reflected how information security risks actually present in modern organisations: distributed workforces, cloud-first architectures, complex supply chains, and persistent adversarial threats. The ISO 27001:2022 standard treats the four themes as operational categories: each maps to a functional area of the business with real ownership and evidence requirements. Understanding them that way is the foundation of enterprise implementation.

Organisational Controls (A.5.x: 37 controls)

The Organisational theme covers the governance layer of information security: policies, risk management, supplier relationships, asset classification, access control policy, incident management, and legal and contractual obligations. Three of the eleven new controls sit here: Threat intelligence (A.5.7), which requires organisations to collect, analyse, and act on information about threats relevant to their asset landscape; Information security for cloud services (A.5.23), which introduces specific requirements for cloud acquisition, use, and exit; and ICT readiness for business continuity (A.5.30), which formalises continuity planning at the technology layer.

At enterprise scale, Organisational controls are owned across multiple functions: legal, risk, ISMS, and IT security all have stakes in this theme. Fragmented ownership is a common implementation failure. When no single function drives the complete set, controls fall into the gaps between teams, and surveillance audits find them there.

People Controls (A.6.x: 8 controls)

The People theme covers the employment lifecycle as it relates to information security: pre-employment screening, terms and conditions of employment, security awareness and training, disciplinary processes, responsibilities after termination or role change, confidentiality agreements, remote working security, and reporting of information security events. Eight controls in this theme, all owned primarily by HR in collaboration with the ISMS function.

Remote working (A.6.7) became significantly more material after the shift to hybrid working models. Organisations that updated their remote working policies as an HR exercise, without revisiting the information security controls and evidence requirements, often find this control underevidenced relative to its actual risk exposure.

Physical Controls (A.7.x: 14 controls)

The Physical theme covers the protection of physical environments where information assets are held or processed: security perimeters, physical entry controls, securing offices and rooms, physical security monitoring, protection against environmental threats, clear desk and clear screen policies, equipment siting and protection, security of assets off-premises, storage media handling, supporting utilities, cabling security, equipment maintenance, and secure disposal or reuse of equipment.

Physical controls are often partially implemented before an ISMS programme begins. Many organisations already have access control systems, fire suppression, and asset disposal processes. But the implementation challenge is evidencing these controls to the standard required by Annex A, not building them from scratch. Disposal certificates, access logs, and maintenance records need to be stored systematically and retrievable at audit.

Technological Controls (A.8.x: 34 controls)

The Technological theme is the largest, with 34 controls covering the technical mechanisms that protect information. This includes user endpoint device management, privileged access rights, information access restriction, authentication information management, access rights reviews, malware protection, technical vulnerability management, configuration management, data leakage prevention, security monitoring, web filtering, cryptography, secure development lifecycle, security testing, and event logging. For a detailed treatment of the Technological controls, see the ISO 27001 Annex 8 Technological Controls guide.

The Technological controls represent the majority of implementation effort for most enterprise organisations. They require technical configuration alongside documentation: active controls that produce system outputs. And it's those outputs (logs, scan results, configuration records) that carry the highest assurance weight at both Stage 2 and surveillance audit.

The SoA is a mandatory document under Clause 6.1.3. For each of the 93 Annex A controls, it must record the include or exclude decision, the justification for that decision (based on risk assessment, legal or regulatory requirements, or contractual obligations), and the current implementation status. At enterprise scale, producing a defensible SoA requires more rigour than completing a standard template. For background on building one that stays current, see the ISO 27001 Statement of Applicability guide.

The most significant enterprise-specific challenge is scope consistency. A control that applies to one business unit may not apply to another. But a blanket exclusion that doesn't acknowledge this distinction won't survive audit scrutiny. Where different areas of the business have materially different risk profiles or processing activities, the SoA should reflect this, with justifications calibrated to the specific context rather than applied organisation-wide without analysis.

Common Enterprise SoA Errors

Four patterns account for the majority of SoA-related nonconformities at Stage 2 and surveillance audit:

1. Blanket exclusions without risk-based justification: excluding A.8.25 (secure development lifecycle) because "we do not develop software" when the organisation maintains scripts, automation, or configuration-as-code.
2. Exclusions that contradict the risk treatment plan: the risk register identifies a high-rated risk for which Annex A offers a direct mitigating control, but the SoA excludes that control without explanation.
3. Inclusion without implementation evidence: the SoA records a control as "implemented" but no evidence exists to support that status. The control is aspirational rather than operational.
4. Static SoA: the document is produced for Stage 2 audit and not updated as the ISMS evolves, resulting in a mismatch between the SoA and the actual control environment at surveillance audit.

A Phased Approach to SoA Development

A four-pass approach reduces the risk of SoA errors at enterprise scale:

1. Pass 1, Applicability: Work through all 93 controls and record the include or exclude decision and justification. Base this on risk assessment output and legal or contractual requirements, not on whether the control is currently in place.
2. Pass 2, Mapping: For controls marked as included, identify existing controls, policies, or technical mechanisms that contribute to implementation. Many controls will be partially covered by existing practice.
3. Pass 3, Gap identification: Identify what is missing between the existing state and the full control requirement. These gaps become the implementation backlog, prioritised by risk.
4. Pass 4, Evidencing: As controls are implemented, document the evidence that demonstrates implementation. The SoA should link to, or reference the location of, the evidence for each included control.

The SoA must be maintained as a living document throughout the ISMS lifecycle. Changes to the risk environment, business operations, or technology landscape that affect control applicability must be reflected in an updated SoA. A document that was accurate at Stage 2 audit and hasn't been reviewed since is a surveillance audit risk.

Ownership is the single most important structural decision in enterprise Annex A implementation. Every control needs a named individual who is accountable for its implementation and for producing evidence at audit. Without named ownership, controls stall in the gap between functions, evidence isn't collected systematically, and surveillance audits expose the same gaps cycle after cycle.

Distributing ownership across business functions is structurally necessary at enterprise scale. The ISMS team can't own and operate 93 controls. The practical model is to align control ownership with functional accountability: the function that carries operational responsibility for the activity also carries accountability for the control that governs it.

Applying a RACI Model

A RACI (Responsible, Accountable, Consulted, Informed) model applied to control ownership prevents the ambiguity that causes evidence gaps. For each Annex A control:

1. Responsible: The person or team that implements the control, configures the technical mechanism, enforces the policy, or carries out the process.
2. Accountable: The named owner who holds accountability for the control being implemented and who will be asked to demonstrate it at audit. One accountable owner per control.
3. Consulted: Functions whose input is required during implementation or review. For example, Legal providing input on data retention requirements for A.8.10.
4. Informed: Stakeholders notified of control status. For controls owned by other functions, the ISMS Manager is usually informed rather than responsible.

Control owners must be briefed on two things: what evidence they are expected to collect, and how to make that evidence available at audit. The most common failure at surveillance audit is that evidence exists and can't be produced. It's in a system the owner hasn't worked with for twelve months, or it was owned by someone who has since left. For practical guidance on embedding controls into operational practice, see how to implement ISO 27001 controls in practice.

Auditors don't test controls directly. They test evidence that controls are working. The practical question at every surveillance audit is: "Can you show me this control is operating as intended?" The answer depends on whether evidence has been collected, maintained, and can be produced on request.

Evidence quality varies, and the hierarchy matters. A documented policy demonstrates intent; a configuration record shows a technical control was set up correctly at a point in time; automated logs and monitoring outputs demonstrate continuous operation and carry the highest assurance for technical controls. Build the evidence architecture with that hierarchy in mind.

Organisational Controls Evidence

For Organisational controls, the primary evidence types are:

1. Signed and version-controlled policies with approval records and review history (A.5.1, A.5.2)
2. Risk register extract showing the risk assessment methodology and treatment decisions that drove SoA inclusions (A.5.3)
3. Signed supplier agreements with information security clauses and evidence of supplier review activity (A.5.19, A.5.20, A.5.21, A.5.22)
4. Asset inventory with ownership, classification, and acceptable use records (A.5.9, A.5.10, A.5.12, A.5.13)
5. Threat intelligence subscription records and outputs, with evidence that intelligence has been acted on (A.5.7)
6. Incident management records showing the full lifecycle from identification through containment to lessons learned (A.5.24 to A.5.28)
7. Cloud service register with security assessments for each cloud service in scope (A.5.23)

People Controls Evidence

For People controls, HR must maintain records that are both complete and accessible to the ISMS function at audit:

1. Pre-employment screening records: background check outputs, identity verification, and reference results for all staff with access to in-scope information assets (A.6.1)
2. Signed employment terms and conditions with explicit information security obligations (A.6.2)
3. Training completion records for information security awareness programmes, with completion rates by business unit and records for all in-scope staff (A.6.3)
4. Signed acceptable use agreements and confidentiality or non-disclosure agreements (A.6.6)
5. Termination and role-change records showing that access rights were reviewed and removed or amended within the defined timescale (A.6.5)
6. Remote working security assessments or approval records for staff working outside controlled environments (A.6.7)

Physical Controls Evidence

Physical controls evidence is often the most straightforward to collect, but it's frequently stored in formats that aren't retrievable at audit:

1. Physical access logs from electronic access control systems, covering entry to secure areas (A.7.2, A.7.4)
2. Visitor records, including sign-in logs and escort records for access to restricted areas (A.7.2)
3. Equipment asset register with location, assigned user, and maintenance history (A.7.8, A.7.13)
4. Destruction and disposal certificates for storage media. This is a specific and commonly audited evidence point (A.7.10, A.7.14)
5. Environmental monitoring records for data centres or server rooms: temperature, humidity, power continuity (A.7.5, A.7.11)
6. Physical security monitoring reports where CCTV or equivalent monitoring is used as a compensating control (A.7.4)

Technological Controls Evidence

Technological controls should generate evidence automatically through logging, monitoring, and configuration management tooling. Where evidence isn't being captured automatically, the implementation is incomplete:

1. SIEM outputs: event logs, alert records, and analyst investigation notes (A.8.15, A.8.16)
2. Vulnerability scanner outputs with remediation tracking showing that identified vulnerabilities were addressed within the defined SLA (A.8.8)
3. Patch management reports showing patching cadence and outstanding vulnerabilities by severity (A.8.8)
4. Penetration test reports with scope, methodology, findings, and evidence of remediation for critical findings (A.8.8)
5. Configuration baselines and configuration management records showing that systems are deployed to approved standards (A.8.9)
6. MFA deployment records showing coverage across privileged and remote access (A.8.3, A.8.5)
7. DLP alert and investigation logs (A.8.12)
8. Access rights review outputs showing that entitlements have been reviewed at the required frequency and that orphaned or excessive accounts have been removed (A.8.2, A.8.3)

Evidence Retention

Retention requirements should be defined in a documented records retention schedule and applied consistently. As a practical baseline:

1. Policies and procedures: retain for the full certification cycle plus one additional cycle (minimum three years) to allow comparison at surveillance audit
2. Audit evidence (access logs, vulnerability reports, training records): three to five years, depending on the sensitivity of the assets involved
3. Incident records: per applicable regulatory requirement, and no less than three years for ISMS purposes
4. Supplier agreements: for the duration of the relationship plus three years after termination

Evidence that exists but can't be produced at audit is treated by CABs as an absence of evidence. Retrieval must be tested before the audit.

Not all 93 controls carry equal risk weight. Attempting to implement all controls simultaneously isn't a viable programme model at enterprise scale. Implementation must be sequenced by risk weight: the controls that address the highest-rated risks in the risk assessment output should be implemented and evidenced first.

The following prioritisation framework provides a starting point, based on the controls most commonly scrutinised at Stage 2 audit and the areas where surveillance audits most frequently identify findings. It should be validated against the organisation's specific risk assessment output. The ISO 27002 guide to controls changes and implementation provides detailed implementation guidance for each control.

H3: Priority Tier 1: Implement Before Stage 2 Audit

These controls address foundational risks and are almost always examined at Stage 2. Absent or poorly evidenced controls in this tier are the most common reason for major nonconformities at initial certification:

1. Access control (A.8.2, A.8.3, A.8.4, A.8.5): User provisioning, privileged access management, source code access, and authentication. These controls should be technically enforced and evidenced with access rights reviews and provisioning or deprovisioning records.
2. Malware protection (A.8.7): Endpoint protection deployment, coverage reporting, and alert response records.
3. Technical vulnerability management (A.8.8): Vulnerability scanning cadence, patch management records, and remediation tracking.
4. Event logging and monitoring (A.8.15, A.8.16): SIEM deployment, log retention configuration, and evidence of alert investigation.
5. Information security incident management (A.5.24 to A.5.28): Defined process, tested process, and a log of incidents handled through the process, even if the log contains only low-severity events.
6. Information security policies (A.5.1): Approved, communicated, and reviewed, with evidence of all three.
7. Supplier relationships (A.5.19 to A.5.22): Supplier register, security clauses in contracts, and evidence of supplier risk assessment for key suppliers.

Priority Tier 2: Implement Within Six Months of Certification

These controls are material but are less likely to produce a Stage 2 major nonconformity if partially implemented, provided the gap is documented and a remediation plan is in place:

1. Threat intelligence (A.5.7): Subscription to a credible threat intelligence feed and a documented process for acting on intelligence outputs.
2. Cloud services security (A.5.23): Cloud register, security assessments for cloud services in scope, and exit planning documentation.
3. Secure development lifecycle (A.8.25 to A.8.32): For organisations with development activity, this tier covers security requirements, security testing, outsourced development management, and environment separation.
4. Data masking and leakage prevention (A.8.11, A.8.12): DLP tooling deployment and data masking procedures for test environments and third-party data sharing.

Priority Tier 3: Ongoing Programme

These controls are often partially in place before the ISMS programme begins, or they represent operational practice that matures over successive certification cycles:

1. Cryptography and key management (A.8.24): Cryptographic policy, key management procedures, and certificate lifecycle records.
2. Configuration management (A.8.9): Configuration baselines for key systems, change records, and configuration drift detection.
3. Capacity management (A.8.6): Capacity monitoring for critical systems and documented capacity thresholds.
4. Physical controls (A.7.x): Focus on evidencing existing controls to the required standard rather than building new physical security infrastructure.

The risk assessment output required under Clause 6.1.2 should be used to validate and, where necessary, override this framework. Where the risk assessment identifies high-rated risks outside Tier 1, those controls must be treated with equivalent urgency. For a broader implementation framework, see the ISO 27001 resource hub.

At enterprise scale, the manual overhead of tracking 93 controls, maintaining a live SoA, and ensuring evidence is collected continuously across distributed teams is substantial. Gracie AI Agents with Personas and Skills addresses this at the control level. For technical vulnerability management (A.8.8), for example, it pulls scanner outputs, maps them to the control, tracks remediation against defined SLAs, and surfaces the evidence in audit-ready format with no manual chase across teams. The same logic applies across the Annex A control set: evidence is captured continuously, not assembled at audit.

Organisations using SureCloud's GRC platform have reduced manual evidence collection by 50 to 65%, cutting the time between audit preparation and submission without reducing the quality of the evidence trail. That matters in the year between certification and first surveillance audit, when control discipline either becomes embedded practice or begins to slip.

The retrieval problem is structural, and it needs a structural answer. A platform that captures evidence automatically and makes it producible on demand removes the dependency on individual memory and manual filing that causes most surveillance audit failures. For more on how SureCloud supports ISO 27001 certification at scale, see the resource hub.