ISO 27001:2022 Annex A has 93 controls in four themes, and engineers mostly own the 34 technological controls, A.8.1 to A.8.34, plus parts of the organisational set. For each one you decide in the Statement of Applicability whether it applies, then implement it and save dated proof.
How does Annex A split between teams?
The 2022 edition groups controls as organisational (37), people (8), physical (14) and technological (34). Engineering touches the technological group most, and shares organisational controls on supplier security, incident management, access control and continuity. The ISO page for the standard returned a 403 to our fetch, so this checklist follows the published structure and common reading. Take exact wording from your licensed copy.
An important reminder: Annex A is a menu. Your risk assessment drives which controls you choose, and the Statement of Applicability records each decision with a reason.
What should the checklist hold?
Group by engineering activity. The references are to the Annex A numbers in the 2022 edition.
Endpoints and identity. Managed devices with disk encryption, screen lock and patching (A.8.1). Privileged access limited and logged (A.8.2). Access to information and source code restricted (A.8.3 and A.8.4). Secure authentication, with multi-factor authentication for administrators and remote access (A.8.5). Evidence: device fleet report, privileged account list, identity provider policy.
Malware, vulnerabilities and configuration. Malware protection (A.8.7), technical vulnerability management with scanning and deadlines (A.8.8), and configuration management with baselines and infrastructure as code (A.8.9). Evidence: scan reports, closure tickets, baseline files in version control.
Data protection. Deletion of data no longer needed (A.8.10), masking in non production where relevant (A.8.11), leakage prevention (A.8.12), and cryptography with a key policy (A.8.24). Evidence: retention job logs, masking procedure, key rotation log.
Resilience. Backups tested by restore (A.8.13), redundancy for availability needs (A.8.14), and capacity monitoring (A.8.6). Evidence: restore record, failover test, capacity dashboard.
Logging and monitoring. Logs produced, protected and reviewed (A.8.15), monitoring activities with alerts (A.8.16), and clock synchronisation (A.8.17). Evidence: log source list, alert sample with ticket.
Network. Network security, segmentation and web filtering (A.8.20 to A.8.23). Evidence: rules export and segment diagram.
Secure development. Secure development lifecycle (A.8.25), security requirements for applications (A.8.26), secure architecture (A.8.27), secure coding (A.8.28), security testing in development and acceptance (A.8.29), separation of development, test and production (A.8.31) and change management (A.8.32). Evidence: pull request rules, SAST and dependency scan outputs in the pipeline, environment separation settings, a sampled change.
Outsourcing and test data. Supervising outsourced development (A.8.30) and protecting test data (A.8.33). Evidence: supplier terms, test data procedure.
In which order should engineers work?
Inventory and access first, because the rest depends on knowing assets and who can touch them. Then logging, vulnerability management and backups, which produce steady evidence. Then the development controls inside your pipeline. Finish with data protection tuning and the restore and failover tests.
What mistakes are common?
- Marking controls applicable with no implementation behind them.
- Excluding controls with a weak reason, such as no time.
- Policies that describe the standard and not the system.
- Evidence that shows the setting but not that it runs, such as one dashboard screenshot.
- Ignoring the new 2022 controls, such as threat intelligence, configuration management and data leakage prevention.
What to do
- Get the Annex A list and your risk register.
- Mark each technological control in the SoA with a reason for the decision.
- For each selected control write the standard, apply the configuration and save one dated proof.
- Add pipeline gates for scanning and review so evidence appears on every release.
- Test backups and incident response with a real exercise.
- Run an internal audit sample before the certification body arrives.
Quick check
How many Annex A controls are technological?
The 2022 edition lists 34 technological controls, A.8.1 to A.8.34, out of 93 in total.
Do I have to implement every Annex A control?
No. You select controls through risk assessment and record each decision, with reasons, in the Statement of Applicability.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. Technical evidence for items such as vulnerability management, secure development testing and configuration comes from your real code and dependencies through scans, SBOMs and reachability, and monitoring continues between audits. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. Certification is granted after an audit by an independent body. Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo
Sources
- ISO/IEC 27001 page on iso.org, not retrievable (HTTP 403) on 18 October 2026, so references follow the widely published 2022 structure
Last reviewed: 18 October 2026.