If your company is pursuing ISO 27001, there's a good chance engineering will get a long list of tasks. Annex A has 93 controls, but you don't implement them all, and many of them aren't about code at all. Here's how to figure out which ones are yours.
For a full breakdown of every control and its purpose, see this guide to ISO 27001 controls explained.
First, the basics
ISO/IEC 27001:2022 defines requirements for an Information Security Management System (ISMS). Annex A is a reference set of 93 controls, grouped into four themes:
| Theme | Controls | Focus |
|---|---|---|
| Organizational (A.5) | 37 | Governance, policies, suppliers, incidents, continuity, legal |
| People (A.6) | 8 | Screening, training, remote work, event reporting |
| Physical (A.7) | 14 | Facilities, equipment, physical access |
| Technological (A.8) | 34 | Endpoints, access, crypto, networks, development, logging |
You don't have to implement all of them. You choose controls based on your risk assessment and document the decision in a Statement of Applicability (SoA), including justification for any exclusions.
Where engineering usually comes in
Most of the work for developers sits in the technological theme (A.8), with some in the organizational one (A.5). Here are common examples:
Access and authentication
- A.8.2 Privileged access rights: restrict and manage admin access
- A.8.3 Information access restriction: limit access based on need
- A.8.5 Secure authentication: MFA and strong authentication mechanisms
- A.8.4 Access to source code: protect repositories from unauthorized access
Secure development
- A.8.25 Secure development life cycle
- A.8.26 Application security requirements
- A.8.27 Secure system architecture and engineering principles
- A.8.28 Secure coding
- A.8.29 Security testing in development and acceptance
- A.8.30 Outsourced development
- A.8.31 Separation of development, test, and production environments
- A.8.33 Test information: protect data used for testing
Operations and resilience
- A.8.6 Capacity management
- A.8.8 Management of technical vulnerabilities
- A.8.9 Configuration management
- A.8.13 Information backup
- A.8.14 Redundancy of information processing facilities
- A.8.32 Change management
Logging and monitoring
- A.8.15 Logging
- A.8.16 Monitoring activities
- A.8.17 Clock synchronization (so logs line up reliably)
Data and network protection
- A.8.10 Information deletion
- A.8.11 Data masking
- A.8.12 Data leakage prevention
- A.8.20 to A.8.22 Network security, network services, and segregation of networks
- A.8.24 Use of cryptography and key management
A few organizational controls also matter to engineering teams, such as A.5.23 (security for cloud services), A.5.24 to A.5.28 (incident management), and A.5.30 (ICT readiness for business continuity).
For the full set with a short purpose for each, this ISO 27001 Annex A controls list is handy to keep open while you map things out.
What this looks like in practice
Many of these controls you probably already do. The difference is that ISO 27001 expects you to document them and show evidence:
- Code review and approvals can serve as evidence for change management (A.8.32).
- CI pipeline results support security testing (A.8.29).
- Cloud and infrastructure configuration shows secure configuration and network controls.
- Backup job reports and restore tests support A.8.13.
- Vulnerability scan reports support A.8.8.
- Centralized logs and alerts support A.8.15 and A.8.16.
The point isn't to create new work. It's to capture what already happens and keep it consistently.
The order of work matters
- Define your ISMS scope
- Run a risk assessment
- Select applicable controls
- Write your Statement of Applicability
- Implement controls and keep evidence
- Run an internal review before the certification audit
Start from risk, not from the list. Ticking off Annex A without understanding your risks leads to wasted effort and gaps where it matters.
What auditors want to see
Auditors look for evidence that controls are implemented and operating, not just documented. Typical items include policies, risk assessments, the SoA, asset inventory, access reviews, training records, vendor assessments, incident records, backup reports, vulnerability scans, change records, security logs, business continuity tests, and internal audit and management review records. What you need depends on your scope, risks, and applicable controls.
ISO 27001 vs ISO 27002
ISO/IEC 27001 sets the requirements for an ISMS and is the standard you certify against. ISO/IEC 27002 gives guidance on implementing the controls. In short, 27001 says what you need, and 27002 helps you understand how to apply it.
Common mistakes
- Treating Annex A as a checklist rather than a risk-based reference
- Writing an SoA with no real reasoning behind exclusions
- Leaving controls without a clear owner
- Gathering evidence only right before the audit
- Treating the ISMS as a one-off project
Reduce the manual work
For many teams the hardest part isn't the controls. It's tracking owners, collecting evidence, managing risks and policies, and preparing for audits. A compliance automation platform can centralize that, so engineers aren't chasing screenshots at the last minute.
Wrapping up
ISO 27001 isn't just paperwork. Much of Annex A overlaps with practices good engineering teams already follow: access control, secure development, change management, logging, and backups. The goal is to understand your risks, choose the right controls, document them, and keep the evidence current.
Which Annex A control has been the hardest for your team? Let me know in the comments.
Top comments (0)