ISO 27001 Annex A.8 Technological Controls: Evidence Guide

Annex A.8 is where an ISMS stops being paperwork and starts touching real systems, and it is where most certification audit nonconformities on technical controls are raised. The 34 technological controls in ISO/IEC 27001:2022 Annex A cover endpoints, privileged access, vulnerabilities, configuration, logging, networks, cryptography and the development life cycle, each in a single line that leaves the implementation open. This guide works through every A.8 control by sub-group and states what each one is for in plain words, what a control owner should build, and the evidence an auditor will normally sample. It is written for ISMS managers, control owners and internal auditors preparing for a stage 2 or surveillance audit. Control intent is paraphrased here; the normative wording is in ISO/IEC 27001:2022 and the guidance in ISO/IEC 27002:2022, both published by ISO and IEC, and should be read in the standards themselves. For the full control catalogue and attributes, see the ISO 27002 Controls Guide.

Key takeaways

Evidence beats policy. For A.8 an auditor expects to see the control running: a configuration export, a scan report, a log query, a change ticket, not only a policy statement.
Seven of the 34 are new in 2022. 8.9 configuration management, 8.10 information deletion, 8.11 data masking, 8.12 data leakage prevention, 8.16 monitoring activities, 8.23 web filtering and 8.28 secure coding are where immature evidence shows up most often.
Several controls lean on organisational ones. 8.2 to 8.5 implement the access rules in 5.15 to 5.18; 8.30 depends on supplier controls 5.19 to 5.22; 8.32 is the technical side of change governance.
Cloud inheritance is allowed, but must be argued. A provider can operate 8.14 or 8.20 for you, yet the Statement of Applicability must say so and you must review the provider's assurance.
Machine identities sit inside A.8. Service accounts, API keys and certificates fall under 8.2, 8.5, 8.15 and 8.24; ignoring them is a frequent audit gap.

How A.8 differs from the rest of Annex A

ISO/IEC 27002:2022, edition 3, groups its 93 controls into four themes, and the technological theme in clause 8 holds 34 of them, numbered 8.1 to 8.34. ISO lists no amendment to ISO/IEC 27002:2022. ISO/IEC 27001:2022 itself was amended in February 2024 by Amendment 1 (climate action changes), which does not change the Annex A control list. The organisational theme (A.5) says what the organisation decides; A.8 says what its systems must do. That makes A.8 the theme where an auditor most often asks to watch a screen share or receive an export rather than read a document.

Sub-group	Controls	Typical owner	Main evidence type
Endpoint and access	8.1 to 8.5	IT operations, IAM team	MDM compliance reports, PAM records, access review outputs, MFA coverage
Resilience and hygiene	8.6 to 8.8, 8.13, 8.14	Infrastructure, vulnerability management	Capacity dashboards, EDR coverage, scan and patch reports, restore test records
Data protection	8.10 to 8.12, 8.24	Data owners, security engineering	Deletion certificates, masking rules, DLP policy and incident logs, key inventory
Configuration and change	8.9, 8.18, 8.19, 8.32	Platform engineering, change manager	Baselines, drift reports, change tickets, software allow lists
Logging and monitoring	8.15 to 8.17	SOC, SIEM engineering	Log source inventory, use cases, alert handling records, NTP configuration
Network	8.20 to 8.23	Network team	Network diagrams, firewall rule reviews, segment design, web filter policy
Development life cycle	8.25 to 8.31, 8.33, 8.34	Engineering, AppSec	SDLC standard, security requirements, code review and test results, environment separation

Endpoint and access controls: 8.1 to 8.5

Control	Intent in plain words	Evidence auditors usually sample
8.1 User endpoint devices	Protect information held on or reached from laptops, phones and other user devices	Device standard; MDM or UEM compliance report showing encryption, screen lock and OS version; BYOD rules
8.2 Privileged access rights	Restrict and manage elevated rights so they are granted, used and removed deliberately	Privileged account inventory (human and machine), approval records, PAM session logs, quarterly review sign off
8.3 Information access restriction	Enforce the access rules agreed under 5.15 inside each system	Role definitions, sample of user to role assignments, results of the last access review
8.4 Access to source code	Control who can read and change source code, tools and libraries	Repository permission export, branch protection settings, removal of leavers from the source platform
8.5 Secure authentication	Use authentication strength that matches the risk of the system and the access	MFA coverage report, authentication standard, conditional access or equivalent policy, lockout settings

What to build first: one privileged account register that includes service accounts and automation identities, then MFA on every administrative and remote access path. Auditors often pick five privileged accounts at random and ask who approved each and when it was last reviewed. See the Privileged Access Management Guide and the MFA Guide.

Resilience and hygiene: 8.6 to 8.8, 8.13 and 8.14

Control	Intent in plain words	Evidence auditors usually sample
8.6 Capacity management	Monitor and plan resource use so services stay available	Capacity thresholds and alerts, trend reports, a capacity review minute
8.7 Protection against malware	Prevent, detect and recover from malware, backed by user awareness	EDR or anti-malware coverage against the asset inventory, alert handling sample, exclusion list review
8.8 Management of technical vulnerabilities	Find vulnerabilities, judge exposure and fix them on time	Scan scope versus inventory, remediation SLAs, overdue items with risk acceptance, penetration test follow up
8.13 Information backup	Keep and test backup copies in line with an agreed backup policy	Backup policy, job success reports, restore test records with dates and outcomes
8.14 Redundancy of information processing facilities	Build in enough redundancy to meet availability requirements	Availability requirements per service, architecture showing redundancy, failover test results

For 8.8 the question that sinks audits is "how do you know the scanner sees everything?" Reconcile scan targets with the asset inventory from 5.9 at least monthly and keep the reconciliation. For 8.13 a restore test is evidence; a green backup job is not. See the Vulnerability Management Guide, the Capacity Management as a Security Control guide and the Backup and Recovery Testing Checklist.

Data protection: 8.10 to 8.12 and 8.24

Control	Intent in plain words	Evidence auditors usually sample
8.10 Information deletion	Delete information when it is no longer needed, on systems, devices and with suppliers	Retention schedule, deletion job logs, disposal certificates, supplier deletion confirmations on contract exit
8.11 Data masking	Hide or transform sensitive data where full values are not needed, in line with access policy and legal duties	Masking or tokenisation rules per data set, non-production data handling standard, sample of masked records
8.12 Data leakage prevention	Apply measures to systems, networks and devices that handle sensitive information to prevent leakage	DLP policy scope, rule set mapped to classification labels, incident and false positive records
8.24 Use of cryptography	Define and apply rules for cryptography, including key management	Cryptography standard (algorithms, key lengths), key and certificate inventory, rotation records, encryption at rest and in transit evidence

These controls depend on classification under 5.12. Without labels, 8.12 rules have nothing to key on and 8.11 cannot say which fields are sensitive. A sensible order is classification, then retention and deletion, then masking for non-production, then DLP on the highest risk channels. See the Data Loss Prevention (DLP) Guide, the Data Retention and Secure Deletion guide and the Cryptographic Key Management guide.

Configuration, change and software control: 8.9, 8.18, 8.19 and 8.32

8.9 Configuration management: establish, document, apply, monitor and review secure configurations for hardware, software, services and networks. Evidence: hardening baselines (for example CIS Benchmarks or vendor baselines) with your deviations recorded, and a drift report showing what is out of baseline today. See the Configuration Drift and Baseline Enforcement Guide.
8.18 Use of privileged utility programs: restrict and control tools that can override system and application controls. Evidence: list of such utilities, who may run them, and logging of their use.
8.19 Installation of software on operational systems: manage software installation on production systems securely. Evidence: an allow list or approved software catalogue, removal of local admin rights, and installation logs.
8.32 Change management: subject changes to processing facilities and systems to change control. Evidence: a sample of changes with risk assessment, approval, testing and rollback plan, plus emergency changes reviewed after the fact. See the Change Management Security guide.

Infrastructure as code helps all four: a merged pull request with review is both the change record (8.32) and the configuration baseline (8.9). Say so in the implementation statement so the auditor samples the repository rather than a ticketing tool.

Logging and monitoring: 8.15 to 8.17

Control	Intent in plain words	Evidence auditors usually sample
8.15 Logging	Produce, store, protect and analyse logs of activities, exceptions and faults	Logging standard naming required events, log source inventory, retention settings, access restrictions on logs
8.16 Monitoring activities	Watch networks, systems and applications for anomalous behaviour and act on it	Detection use case list, alert triage records, escalation into incident management (5.25, 5.26)
8.17 Clock synchronization	Synchronise clocks to approved time sources so events can be correlated	NTP configuration for servers, network devices and cloud services; drift monitoring

A common question for 8.16 is "show me an alert from last month and what happened next." Keep a handful of closed alerts with timestamps for each stage. See the Log Management and Retention guide and the SIEM Guide.

Network controls: 8.20 to 8.23

8.20 Networks security: secure, manage and control networks and network devices. Evidence: current network diagram, device hardening, management plane access restrictions.
8.21 Security of network services: identify and monitor the security mechanisms, service levels and requirements of network services, including those bought in. Evidence: service agreements with security terms, SD-WAN or ISP security configuration.
8.22 Segregation of networks: separate groups of services, users and systems. Evidence: segment design with the rationale, firewall rule review, test showing a blocked path. See the Network Segmentation Guide.
8.23 Web filtering: manage access to external websites to reduce exposure to malicious content. Evidence: filter policy by category, coverage for remote users, block logs. See the DNS Filtering vs Secure Web Gateway guide.

Development life cycle: 8.25 to 8.31, 8.33 and 8.34

Control	Intent in plain words	Evidence auditors usually sample
8.25 Secure development life cycle	Set rules for building software and systems securely	SDLC standard with security gates, training records for developers
8.26 Application security requirements	Identify and approve security requirements when building or buying applications	Requirements template (for example based on OWASP ASVS), sample of approved requirements for a recent project
8.27 Secure system architecture and engineering principles	Define and apply secure engineering principles to all development	Architecture principles, design review or threat model records
8.28 Secure coding	Apply secure coding principles in software development	Coding standard, SAST and dependency scan results, peer review enforcement
8.29 Security testing in development and acceptance	Define and run security tests within the life cycle	Test plans, DAST or penetration test reports, release sign off showing findings handled
8.30 Outsourced development	Direct, monitor and review development done by others	Contract security clauses, supplier code review or test evidence, acceptance testing
8.31 Separation of development, test and production environments	Keep environments separate and secured	Separate accounts or subscriptions, access lists per environment, deployment pipeline controls
8.33 Test information	Select, protect and manage information used for testing	Rules on production data in test, masking evidence (links to 8.11), approvals for exceptions
8.34 Protection of information systems during audit testing	Plan and agree audit tests on operational systems to limit disruption	Agreed scope and timing for technical audits and penetration tests, read only access for auditors

Organisations that only buy software can often scope 8.25 to 8.29 narrowly, but 8.26 still applies to procurement and 8.30 to any customisation. See the Secure Software Development Lifecycle (SSDLC) Guide and the Secure Coding Guide.

Where identity fits

Non-human identities appear across A.8 even though no control names them. Service accounts and workload identities are privileged under 8.2; API keys, tokens and certificates are authentication information protected under 8.5 and governed by 5.17; their activity belongs in the 8.15 log sources; and the keys behind them fall under 8.24. Pipelines that deploy code hold credentials that bridge 8.31 environments. Put machine identities in the same privileged register and review cycle as people, with owners and expiry. See the Service Account Security Guide, the Secrets Management Guide and the NHI and AI Agent Audit Evidence guide.

Rolling out and evidencing A.8

Confirm applicability: mark each of the 34 controls in the Statement of Applicability as applicable, inherited from a named provider, or excluded with a reason. See the ISO 27001 Statement of Applicability Template.
Assign one owner per control: a named role, not a team, with the evidence source written next to it.
Write implementation statements: two to four sentences per control naming the tools, scope and frequency. Avoid restating the control wording.
Collect a baseline of evidence: run each report once, store it with the date, and note gaps as risks or corrective actions.
Close the new controls first: 8.9, 8.10, 8.11, 8.12, 8.16, 8.23 and 8.28 usually have the least mature evidence.
Test with an internal audit: sample like a certification auditor would, for example five changes, five privileged accounts and one restore. See the ISMS Internal Audit and Management Review guide.
Automate collection: schedule exports so evidence for surveillance audits is a query, not a project. If an automated control breaks, fall back to the manual record and log the gap as a nonconformity rather than hiding it.

Decision guidance: small, large and cloud-first

Situation	Practical approach	Watch out for
Small organisation, mostly SaaS	Lean on provider controls for 8.14, 8.20, 8.21; focus on 8.1, 8.2, 8.5, 8.12, 8.13	Assuming SaaS backups cover you; check the shared responsibility terms
Large, hybrid estate	Split A.8 owners by platform; one evidence register; automate 8.8, 8.9, 8.15	Inconsistent baselines between business units
Software company	Treat 8.25 to 8.31 as the core of the audit; use pipeline evidence	Production data copied to test without 8.33 approval
Buyer of software only	Scope development controls to procurement and configuration	Excluding 8.26 and 8.30 entirely despite customisations

Detection and measurement

EDR and MDM coverage: percentage of inventory assets reporting in the last 7 days (8.1, 8.7).
Critical vulnerability age: median days to remediate critical findings against the SLA (8.8).
Baseline compliance: percentage of systems matching the approved configuration (8.9).
Restore success: share of scheduled restore tests that met the recovery objective (8.13).
Log source coverage: percentage of in-scope systems sending required events to the central log store (8.15).
Privileged accounts reviewed: share of human and machine privileged accounts reviewed in the last cycle (8.2).

Common failure patterns

Policy only: a statement for 8.16 with no detection use cases or alert records behind it.
Scanner blind spots: 8.8 evidence that covers servers but not cloud workloads, containers or network devices.
Machine accounts missing: 8.2 reviews that list people only, while long-lived service accounts with admin rights go unreviewed.
Untested backups: 8.13 evidence made only of job success emails.
Inheritance without proof: controls marked as provider-operated with no reviewed provider certificate or report under 5.22.
Production data in test: 8.33 breached by routine database copies to development.

Framework mapping

NIST publishes an ISO/IEC 27001:2022 crosswalk for SP 800-53 Rev. 5 through its OLIR catalogue and warns that mappings are not always one to one. The table shows closely related controls for orientation, not equivalence.

A.8 group	NIST SP 800-53 Rev. 5	NIST CSF 2.0
8.2, 8.3, 8.5	AC-6, AC-3, IA-2, IA-5	PR.AA-01, PR.AA-05
8.7, 8.8	SI-3, RA-5, SI-2	ID.RA-01, PR.PS-02
8.9, 8.19, 8.32	CM-2, CM-6, CM-11, CM-3	PR.PS-01
8.13, 8.14	CP-9, CP-10	PR.DS-11, PR.IR-03
8.15 to 8.17	AU-2, AU-6, AU-8, SI-4	PR.PS-04, DE.CM-01, DE.CM-09
8.20, 8.22	SC-7	PR.IR-01
8.24	SC-12, SC-13, SC-28, SC-8	PR.DS-01, PR.DS-02
8.25 to 8.29	SA-3, SA-8, SA-11, SA-15	PR.PS-06

Practitioner checklist

Record applicability, owner and evidence source for all 34 A.8 controls in the Statement of Applicability.
Include service accounts, API keys and certificates in the 8.2 privileged register and review cycle.
Reconcile vulnerability scan scope with the asset inventory monthly and keep the result.
Keep dated restore test records for each critical service.
Publish hardening baselines with recorded deviations and a current drift report.
Maintain a log source inventory and at least a few closed alerts per quarter as 8.16 evidence.
Ban unmasked production data in test unless an approved exception exists.
Run an internal audit that samples A.8 the way the certification body will.

ISO 27001 Annex A.8 Technological controls: What Auditors Expect for All 34 Controls