ISO Digital Solutions Get the ISMS Framework

SGRII Insights  ·  ISO 27001:2022  ·  2026

Thirty-Four Technological Controls. Seven New Since 2022. Stage 2 Auditors Test These Operationally. Most ISMS Programmes Are Not Prepared for That Test.

Annex A.8 is the control theme where documentation meets operational reality — and where the gap between them is widest. Auditors do not accept policies as evidence for technological controls. They request configuration records, monitoring logs, and test results.

Why A.8 Is the Stage 2 Battleground

In any Stage 2 ISO 27001 audit, the auditor will select a sample of Annex A controls and request implementation evidence. The sample always includes A.8 technological controls — because these controls have the most objective evidence requirements and the most verifiable implementation status. A firewall rule either exists or it does not. A backup restoration test either succeeded or it did not. A vulnerability scan either ran or it did not.

This objectivity is what makes A.8 the battleground. Organisational controls (A.5) can be evidenced through meeting minutes, policy approvals, and process descriptions. People controls (A.6) can be evidenced through training records and HR processes. Physical controls (A.7) can be evidenced through site visits and access logs. Technological controls require technical evidence — and that evidence either exists or the control is not implemented.

The 2022 revision introduced seven new A.8 controls that specifically require evidence most implementations have not prepared: configuration management (A.8.9), information deletion (A.8.10), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23), and secure coding (A.8.28). Each represents a control area that did not have a dedicated Annex A requirement in the 2013 edition.

The Seven New Controls: Evidence Requirements

A.8.9 — Configuration management. Requires defined, documented, implemented, monitored, and reviewed security configurations for hardware, software, services, and networks. Evidence: baseline configuration documents, hardening standards applied, configuration change records, compliance scanning results. An organisation that cannot demonstrate its production server configurations against a documented baseline has an A.8.9 gap.

A.8.10 — Information deletion. Requires information stored in information systems, devices, or any storage media to be deleted when no longer required. Evidence: retention schedules linked to information classification, deletion verification records, media sanitisation logs. This is where data lifecycle management meets the ISMS — and where most organisations discover they retain data indefinitely because deletion processes do not exist.

A.8.11 — Data masking. Requires data masking to be used in accordance with the organisation’s topic-specific policy and business requirements, taking applicable legislation into consideration. Evidence: masking rules documented, environments where masking is applied (test, development, analytics), verification that production data is not exposed in non-production environments.

A.8.12 — Data leakage prevention. Requires data leakage prevention measures to be applied to systems, networks, and any other devices that process, store, or transmit sensitive information. Evidence: DLP tool configuration, DLP policy rules, alert investigation records, exception management. A DLP tool deployed but not monitored is an implemented technology, not an implemented control.

A.8.16 — Monitoring activities. Networks, systems, and applications should be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents. Evidence: what is monitored (systems, networks, applications), how anomalies are detected (SIEM rules, thresholds, baselines), what action results from detection (alert triage, escalation, investigation). This control makes monitoring an explicit requirement — not an implied good practice.

A.8.23 — Web filtering. Access to external websites should be managed to reduce exposure to malicious content. Evidence: web filtering categories configured, policy documented, bypass controls defined, exception management. A content filter that exists but is not governed by a policy with exception management is a technology deployment, not a control implementation.

A.8.28 — Secure coding. Secure coding principles should be applied to software development. Evidence: secure coding standards adopted, code review records, static/dynamic analysis results, developer training. An organisation that develops software without documented secure coding practices has an A.8.28 gap that represents real vulnerability exposure.

The Vulnerability Management Chain: A.8.8

A.8.8 (Management of technical vulnerabilities) is the A.8 control most frequently raised in audit findings — not because organisations lack vulnerability scanning, but because the scan-to-remediation chain is incomplete. The control requires identification, evaluation, and timely remediation of technical vulnerabilities.

The evidence chain: vulnerability scanning (evidence of scheduled scans with scope coverage), vulnerability assessment (evidence of prioritisation against risk), remediation (evidence of patches applied or compensating controls implemented within defined SLAs), and verification (evidence that remediation was effective). An organisation that scans weekly but remediates quarterly has a timing gap. An organisation that scans but does not assess has a prioritisation gap. An organisation that remediates but does not verify has an effectiveness gap.

The audit test: select a critical vulnerability from a recent scan. Trace it through assessment, remediation decision, implementation, and verification. If any step is missing, A.8.8 is not fully implemented — regardless of how many scans are in the evidence folder.

Access Control: A.8.2–A.8.5

Four controls define the access control architecture: privileged access rights (A.8.2), information access restriction (A.8.3), access to source code (A.8.4), and secure authentication (A.8.5). These controls interact with A.5.15 (Access control policy) and A.5.18 (Access rights) to form a complete access governance framework.

The audit evidence that most implementations lack is the periodic access review — evidence that access rights were reviewed, that excessive or outdated permissions were identified, and that remediation was completed. An access review that covers 100% of privileged accounts on a quarterly basis with documented remediation actions is a strong control. An annual review that produces a spreadsheet but no remediation evidence is a compliance artefact.

A.8.5 (Secure authentication) has specific evidence requirements in the current threat landscape: multi-factor authentication deployment records, password policy configuration evidence, and authentication failure monitoring. An MFA policy that exists but is not deployed on all privileged access is a gap between documented intent and operational control.

The SGRII Position

The SGRII position on A.8 controls is direct: if the evidence is technical, the audit preparation must be technical. A procedure that describes how vulnerability management should work is not evidence that vulnerability management works. Configuration standards that define hardening baselines are not evidence that systems are hardened.

The SGRII Annex A Implementation Guide maps all 34 A.8 controls with specific evidence requirements, Clause 8 operational linkages, and common audit findings. The Excel Template Pack includes control implementation tracking with evidence fields — so the gap between ‘applicable and implemented’ in the SoA and ‘where is the evidence?’ from the auditor cannot exist.