ISO 27001 Annex A
The technological controls, grouped the way engineers work.
Theme 8 holds 34 controls on devices, identities, networks, data, code and operations. It is where Stage 2 evidence mostly comes from, because these controls run every day and leave logs. Seven of them are new in the 2022 edition. Here is each one, its usual setup, and what an auditor asks to see.
Back to ISO 27001 services01 · Six groups
Thirty-four controls in six groups
Grouped by the team that usually runs them, so each group has an obvious owner.
| Group | Controls | New in 2022 | Deeper page |
|---|---|---|---|
| Endpoints and identity | 8.1 to 8.5 | None | Access control explained |
| Systems and networks | 8.7, 8.18 to 8.23 | 8.23 | None yet |
| Cryptography and data protection | 8.10 to 8.12, 8.24 | 8.10, 8.11, 8.12 | Cryptography and key management |
| Secure development | 8.25 to 8.33 | 8.28 | Secure development; Change management |
| Operations and monitoring | 8.6, 8.8, 8.9, 8.15 to 8.17 | 8.9, 8.16 | Vulnerability management; Configuration; Logging |
| Resilience and testing | 8.13, 8.14, 8.34 | None | Backup and redundancy |
The seven new controls cover configuration, deletion, masking, leakage, monitoring, web filtering and secure coding. Most software companies already do part of each; the gap is usually a written rule and a record.
02 · Endpoints and identity
Endpoints and identity
The technical side of access: devices, admin rights and sign-in strength.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 8.1 User endpoint devices | Devices that touch company data are protected | Device management with encryption, lock, updates and remote wipe | Compliance report covering every device in the inventory |
| 8.2 Privileged access rights | Admin and other powerful rights are few, approved and watched | Just-in-time admin, separate admin accounts, logged use | List of privileged users, approvals, a review |
| 8.3 Information access restriction | People reach only the data their role allows | Role-based groups in apps and cloud; tenant isolation in the product | Role definitions and a sample of user permissions |
| 8.4 Access to source code | Source code is read and changed only by the right people | Repository access by team; write access limited; no personal forks of private code | Repository member list compared with the engineering roster |
| 8.5 Secure authentication | Sign-in strength matches the risk | Single sign-on with multi-factor everywhere; phishing-resistant keys for admins | Identity provider policy and any exceptions |
03 · Systems and networks
Protection of systems and networks
Keep malicious code and traffic out, and limit the damage when something gets in.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 8.7 Protection against malware | Malware is blocked, detected and cleaned up | Endpoint protection on laptops; image scanning for containers | Coverage report and a sample alert |
| 8.18 Use of privileged utility programs | Tools that can bypass controls are restricted | Debug and admin utilities limited to named engineers, use logged | The allowed list and its log |
| 8.19 Installation of software on operational systems | Software on production is installed through a controlled route | Deploys only through the pipeline; no manual installs on servers | Pipeline settings and a check for drift |
| 8.20 Networks security | Networks and network devices are secured and managed | Cloud network rules as code; office network on separate guest and staff segments | Network rules and their review history |
| 8.21 Security of network services | Network services you use or offer have defined security | Rules for VPN, DNS, load balancers and third-party network services | Service definitions and supplier terms |
| 8.22 Segregation of networks | Groups of systems and users are separated on the network | Separate cloud accounts or VPCs for production; private subnets for databases | Architecture diagram compared with the live configuration |
| 8.23 Web filtering (new in 2022) | Access to harmful websites is limited | DNS filtering or browser protection on managed devices | Filtering policy and coverage |
04 · Data protection
Cryptography and data protection
Three new controls on the life of data, plus the long-standing cryptography control.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 8.10 Information deletion (new in 2022) | Information is deleted once it is no longer needed | Retention periods per data type; automated deletion jobs; customer deletion on request | Retention schedule and proof a deletion job ran |
| 8.11 Data masking (new in 2022) | Sensitive data is hidden where full values are not needed | Masked fields in support tools and logs; pseudonymised data for analytics | Screens or queries showing the masking |
| 8.12 Data leakage prevention (new in 2022) | Unauthorised disclosure of sensitive data is prevented or noticed | Sharing limits in the drive, secret scanning, email rules | Settings and a sample of alerts handled |
| 8.24 Use of cryptography | Encryption is used by rule, and keys are managed | Encryption at rest and in transit; keys in a managed key service with rotation | Cryptography policy, key settings, TLS configuration |
05 · Secure development
Secure development
Nine controls that follow code from requirement to release. Excluding them needs a strong reason if you build anything.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 8.25 Secure development life cycle | Development follows written security rules | A secure development standard tied to the engineering workflow | The standard and evidence it is followed |
| 8.26 Application security requirements | Security needs are stated before building | Security questions in feature specs; customer requirements captured | A sample of specs |
| 8.27 Secure system architecture and engineering principles | Systems are designed on sound security principles | Architecture principles; design review for significant changes | The principles and a recent design review |
| 8.28 Secure coding (new in 2022) | Code is written to avoid common weaknesses | Coding guidelines, code review, static analysis in the pipeline | Pipeline results and a sample of reviewed changes |
| 8.29 Security testing in development and acceptance | Security is tested before release | Automated tests plus periodic penetration tests | Test results and how findings were tracked |
| 8.30 Outsourced development | Outsourced development meets the same rules | Contract terms and code review for agency work | Contract clauses and review records |
| 8.31 Separation of development, test and production environments | Development, test and production are kept apart | Separate accounts and credentials per environment | Environment layout and access lists |
| 8.32 Change management | Changes are requested, reviewed, tested and recorded | Pull requests with approval, tests and a deploy log | A sample of changes traced from ticket to deploy |
| 8.33 Test information | Test data is chosen and protected with care | No raw production personal data in test; synthetic or masked sets | The test data rule and a check of test databases |
06 · Operations and monitoring
Operations and monitoring
The controls that run every day and leave the richest trail of records.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 8.6 Capacity management | Capacity keeps up with demand | Autoscaling, usage dashboards, alerts on limits | Dashboards and a capacity review note |
| 8.8 Management of technical vulnerabilities | Weaknesses are found, ranked and fixed on time | Scanners on code, images and cloud; fix deadlines by severity | Scan results and fixes measured against the deadlines |
| 8.9 Configuration management (new in 2022) | Secure configurations are set, kept and checked | Infrastructure as code, hardened images, drift alerts | Baselines and drift reports |
| 8.15 Logging | Activity is recorded, protected and kept long enough | Central logging with restricted delete rights and a retention period | Log sources, retention settings, access to logs |
| 8.16 Monitoring activities (new in 2022) | Unusual behaviour is spotted and acted on | Alert rules on logs and cloud activity, routed to on-call | Alert rules and a sample of alerts with the response |
| 8.17 Clock synchronization | System clocks agree, so logs line up | Managed time sync on cloud hosts and devices | Time configuration on a sample of systems |
07 · Resilience and testing
Resilience and audit testing
Can you get data back, stay up when a part fails, and test without causing harm?
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 8.13 Information backup | Data and systems can be restored from backup | Automated backups, copies kept apart, scheduled restore tests | Backup settings and the last restore test |
| 8.14 Redundancy of information processing facilities | Enough spare capacity exists to meet availability needs | Multiple availability zones; no single point of failure for core services | Architecture and a failover test |
| 8.34 Protection of information systems during audit testing | Audits and tests on live systems do not disrupt them | Agreed scope, timing and read-only access for auditors and testers | Test plan, approvals and access granted |
Sources: ISO/IEC 27001:2022 Annex A control numbers and names, and which controls are new in that edition; ISO/IEC 27002:2022 for the purpose of the technological controls, described in our own words. The standards are copyrighted and are not reproduced here.
Questions about the technological controls
Does Annex A require a penetration test?
It does not name one, but a pen test is a common way to meet two controls.
Security testing in development (8.29) and technical vulnerability management (8.8) are commonly supported by a periodic penetration test. Your risk assessment decides whether you need one and how often.
Do we need a data leakage prevention product for 8.12?
Not necessarily. The measures must fit the data and the risk.
Many software companies meet 8.12 with settings they already have: limits on external sharing, secret scanning, email rules and alerts. A dedicated product makes sense when sensitive data moves through many channels.
Which technological controls are most often sampled?
The ones with daily records: access, changes, vulnerabilities, logs, backups.
Expect samples of privileged access, changes traced to deploys, vulnerability fixes against deadlines, log retention and alerts, and a restore test. Each leaves a record that is easy to compare with your rule.
We do not develop software. Can we exclude 8.25 to 8.33?
Only if nothing in scope is built or configured by you.
Scripts, infrastructure as code and customised SaaS often count. If you truly build nothing, record the reason in the SoA; otherwise apply the controls at the scale of the work you do.
See which technical controls already leave evidence.
An ISO 27001 gap analysis maps your tools and pipelines to all 34 controls, and shows which ones lack a written rule or a record.