ISO 27001 Annex A Technological Controls: 8.1 to 8.34 Explained
The Technological theme is the largest single group in ISO 27001:2022 Annex A: 34 controls, more than Organizational's 37 only because Organizational is split across governance topics while Technological concentrates entirely on systems. For a cloud-native SaaS company, this is where most of the actual implementation work lives, and it is the theme with the heaviest overlap with SOC 2 CC6 and CC7.
Quick answer. ISO 27001:2022 Annex A has 34 technological controls, numbered 8.1 to 8.34. They cover endpoint and access, vulnerability and configuration management, data protection and resilience, logging and monitoring, network security, and secure development. Auditors focus most on 8.8 (vulnerability management) and 8.9 (configuration management) because both require continuous evidence, not a one-time snapshot.
Here they are grouped into six areas by what a team actually builds and operates, rather than the standard's flat numbering.
Endpoint, Access, and Authentication (8.1-8.5)
- 8.1 User endpoint devices
- 8.2 Privileged access rights
- 8.3 Information access restriction
- 8.4 Access to source code
- 8.5 Secure authentication
What auditors look for: a documented device management policy (MDM enrollment, disk encryption, screen lock), a named and reviewed list of privileged accounts, restricted source code access tied to role, and enforced MFA for authentication, not just an available option. This is the technological side of the access controls described in Annex A 5.15-5.18.
Vulnerability and Configuration Management (8.6-8.9)
- 8.6 Capacity management
- 8.7 Protection against malware
- 8.8 Management of technical vulnerabilities
- 8.9 Configuration management
Common gap
Common gap: running a vulnerability scan once, right before the audit, and calling it evidence. Auditors expect a documented cadence (monthly is common for external-facing systems) with remediation SLAs by severity, and evidence the SLA was actually met across the full audit period, not just that a scan ran.
What auditors look for: endpoint protection deployed fleet-wide, a documented scanning cadence with remediation SLAs, and configuration baselines for production systems (infrastructure as code counts) with a process for detecting drift from baseline.
Data Protection and Resilience (8.10-8.14)
- 8.10 Information deletion
- 8.11 Data masking
- 8.12 Data leakage prevention
- 8.13 Information backup
- 8.14 Redundancy of information processing facilities
What auditors look for: a documented data retention and deletion schedule (including how deletion requests are fulfilled), masked or pseudonymized data in non-production environments, tested backups with a defined restore process, and redundancy appropriate to your availability commitments. 8.10 and 8.11 are both new in 2022 and are frequently missing from a first-time SoA because they were previously implied rather than named.
Logging and Monitoring (8.15-8.19)
- 8.15 Logging
- 8.16 Monitoring activities
- 8.17 Clock synchronization
- 8.18 Use of privileged utility programs
- 8.19 Installation of software on operational systems
What auditors look for: centralized logs with defined retention, an active monitoring process (not just log collection with no one watching), synchronized clocks across systems so logs can be correlated, restricted use of admin-level utilities, and a controlled process for installing software on production systems rather than ad hoc installs by whoever has access.
Network Security and Cryptography (8.20-8.24)
- 8.20 Networks security
- 8.21 Security of network services
- 8.22 Segregation of networks
- 8.23 Web filtering
- 8.24 Use of cryptography
What auditors look for: documented network architecture showing segmentation between production and development, security requirements defined for any network service you rely on (including third-party APIs), and a cryptography policy covering what gets encrypted, with which algorithms, and how keys are managed. TLS 1.2+ in transit and encryption at rest are the baseline most auditors expect by default.
Secure Development (8.25-8.34)
- 8.25 Secure development life cycle
- 8.26 Application security requirements
- 8.27 Secure system architecture and engineering principles
- 8.28 Secure coding
- 8.29 Security testing in development and acceptance
- 8.30 Outsourced development
- 8.31 Separation of development, test and production environments
- 8.32 Change management
- 8.33 Test information
- 8.34 Protection of information systems during audit testing
What auditors look for: a documented SDLC with security gates (code review, dependency scanning, secret scanning), separated environments with controlled promotion between them, a change management process with approval and rollback steps, and, if you outsource any development, contractual security requirements on that vendor. 8.34 is easy to overlook: it expects you to protect production systems while a penetration test or audit itself is running, not just after.
The Overlap With SOC 2
If you are pursuing both frameworks, the technological controls are where the reuse is largest. Access controls (8.1-8.5) map to SOC 2 CC6, vulnerability and logging controls (8.7-8.9, 8.15-8.17) map to CC7, and the secure development controls (8.25-8.34) support both CC6 and CC8 (change management). Building this evidence once and mapping it to both frameworks, instead of running two parallel programs, is a large part of what a fractional CISO does. Read the companion post on Annex A organizational controls and the Statement of Applicability for how these controls get documented and justified.
Mapping evidence to 34 technological controls, and keeping it current as your stack changes, is not a project you run once a year. See pricing or book a call.