ISO/IEC 27001:2022 groups its 93 Annex A controls into four themes: organisational (37 controls), people (8 controls), physical (14 controls) and technological (34 controls). These four replaced the 14 control domains in the 2013 version of the standard, and once you work with them for a week you will wonder why it was ever done any other way.
From fourteen domains to four themes
The 2013 edition of Annex A spread 114 controls across 14 domains with names like A.9 Access Control, A.12 Operations Security and A.18 Compliance [1]. In practice, many of those domains overlapped. A control about logging could reasonably sit in operations security, communications security or access control, depending on your mood and the day of the week.
The 2022 revision collapsed everything into four themes based on what the control primarily affects [2]. The result is 93 controls: 11 brand-new, 24 merged from pairs or groups that were saying the same thing, 58 updated, and none deleted outright [1]. The mapping is documented in ISO/IEC 27002:2022 Annex B, which is useful during transition audits and largely ignored after that.
We once reviewed a client's Statement of Applicability that still referenced the 14-domain structure six months after they had supposedly transitioned. Their risk register pointed to controls that no longer existed. That is not a minor paperwork issue; it is a major nonconformity at Stage 2 because the SoA must reference the current version of Annex A [3].
The four themes
| Theme | Control range | Count | What it covers |
|---|---|---|---|
| Organisational | 5.1 - 5.37 | 37 | Policies, roles, asset management, access rules, supplier relationships, incident management, business continuity, compliance |
| People | 6.1 - 6.8 | 8 | Screening, terms of employment, awareness and training, disciplinary process, post-employment, remote working, reporting |
| Physical | 7.1 - 7.14 | 14 | Perimeters, entry controls, offices, equipment, cabling, maintenance, secure disposal, clear desk, monitoring |
| Technological | 8.1 - 8.34 | 34 | User devices, privileged access, authentication, source code, malware, backups, logging, encryption, secure development, DLP |
Organisational controls (5.1 to 5.37)
Thirty-seven controls sit here, making this the largest theme. These are the controls that shape how your organisation governs information security rather than how a specific server is configured.
Key examples:
- 5.1 Policies for information security. You need an overarching policy, approved by top management, plus topic-specific policies. One page for the overarching policy is fine. Forty pages is a sign that nobody will read it.
- 5.7 Threat intelligence. New in 2022. You are expected to collect and analyse information about threats relevant to your organisation [2]. For a 15-person SaaS company, this might mean subscribing to a threat feed and reviewing it monthly. It does not mean building a SOC.
- 5.23 Information security for use of cloud services. Also new. If you run anything in AWS, Azure or GCP, this control expects you to define acquisition, use, management and exit processes for those cloud services [2]. Most startups already do this informally; the control asks you to write it down.
- 5.30 ICT readiness for business continuity. Another new control requiring you to plan, implement, maintain and test ICT readiness so you can recover services after a disruption [2]. Think of it as the technical side of your business continuity plan.
Supplier management (5.19 to 5.22) also lives here, covering everything from initial due diligence through to monitoring your suppliers' security posture over time.
People controls (6.1 to 6.8)
Eight controls, the smallest theme, covering the human side of information security. The 2022 revision added one new control here: 6.7 Remote working [2], which formalised what every organisation was scrambling to figure out in 2020.
Key examples:
- 6.1 Screening. Background checks on candidates, proportionate to the role, the classification of information they will access and any legal requirements. In the UK, this usually means a basic DBS check for roles with access to sensitive personal data and a right-to-work check for everyone [4].
- 6.3 Information security awareness, education and training. Not a one-off onboarding slide deck. The control expects an ongoing programme, relevant to people's roles, with records that it happened. We usually tell founders that a 30-minute quarterly session beats an annual two-hour marathon that everyone forgets by lunch.
- 6.7 Remote working. Covers physical security of the home office, communication security over domestic internet, and the risk of shoulder surfing in coffee shops. You do not need to inspect everyone's spare bedroom, but you do need a policy and some technical controls (VPN, endpoint protection, screen lock).
- 6.8 Information security event reporting. People need a way to report incidents and near-misses, and they need to know that reporting will not get them in trouble.
Physical controls (7.1 to 7.14)
Fourteen controls dealing with the tangible world: buildings, rooms, cables and kit. One new control arrived in 2022: 7.4 Physical security monitoring [2], making explicit what most organisations were already doing with CCTV or access-log monitoring.
Key examples:
- 7.1 Physical security perimeters. Define the boundaries of areas containing information and information processing facilities. For a fully remote startup with no office, the "perimeter" might be the cloud provider's data centres (covered by their own certifications) and the employees' home offices.
- 7.4 Physical security monitoring. Alarm systems, CCTV, access control logs. The control expects continuous or regular monitoring of premises for unauthorised access [2]. If you lease a serviced office, check whether your landlord's security setup satisfies this; often it does.
- 7.9 Security of assets off-premises. Laptops in transit, equipment at a co-working space. Full-disk encryption and a device-management policy go a long way here.
- 7.10 Storage media. How you handle USB drives, external hard drives and backup tapes (if you still have those) through their lifecycle, including secure disposal. The NCSC recommends physical destruction for media that held OFFICIAL-SENSITIVE data or above [5].
Technological controls (8.1 to 8.34)
Thirty-four controls, the second-largest theme and the one that feels most familiar to engineering teams. Seven of the eleven new controls in 2022 landed here, reflecting how much the threat landscape has shifted toward cloud, code and data [2].
Key examples:
- 8.9 Configuration management. New in 2022. Establish, document, implement, monitor and review configurations across hardware, software, services and networks [2]. If you already use infrastructure as code, you are most of the way there.
- 8.11 Data masking. New. Mask personal data and other sensitive information in line with your policies and legal requirements. Relevant if you copy production data into staging environments, which we see at roughly half the companies we audit.
- 8.12 Data leakage prevention. New. Apply DLP measures to systems, networks and devices that process, store or transmit sensitive information [2]. This ranges from email filtering rules to endpoint DLP agents, depending on your risk assessment.
- 8.16 Monitoring activities. New. Monitor networks, systems and applications for anomalous behaviour and take appropriate action [2]. Pair this with 5.7 (threat intelligence) and 8.15 (logging) for a coherent detection-and-response capability.
- 8.28 Secure coding. New. Apply secure coding principles to software development [2]. OWASP Top 10, code review, static analysis, dependency scanning. If your engineering team already does pull-request reviews and runs Snyk or Dependabot, you are covering most of this control.
Themes and risk treatment
Your risk assessment (Clause 6.1.2) identifies the risks, your risk treatment plan (Clause 6.1.3) decides what to do about them, and your Statement of Applicability (SoA) maps those decisions to specific Annex A controls [3].
The four themes do not change this process, but they make it easier to spot gaps. If your risk register is full of threats related to remote working, phishing and insider error, and your SoA has ticked only technological controls, you probably need to look at the people and organisational themes more carefully.
At Calibre, we see SoAs that apply all 93 controls by default and then justify every one. That is technically compliant but misses the point. The SoA is a decision document: which controls apply to your scope, which do not, and why. If control 7.1 (physical security perimeters) does not apply because you have no office, say so and move on.
ISO 27002 and the attribute values
ISO/IEC 27002:2022 provides implementation guidance for all 93 controls and adds five attribute values to each control: control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities (15 categories including governance, asset management, and threat and vulnerability management) and security domains (governance/ecosystem, protection, defence, resilience) [6].
You do not have to use the attributes, but they are useful for filtering controls during the risk treatment process. Want to see every detective control? Filter by attribute. Want to find all controls relevant to the NIST "Detect" function? Same filter. Some GRC platforms now support this natively.
FAQ
No. Annex A is a reference set, not a checklist: your risk assessment determines which controls are relevant to your scope and risk profile, and the SoA records those decisions (applied, not applied, and the justification for each). An auditor will check that the justifications make sense, not that you ticked every box.
No. The transition deadline was 31 October 2025 [7], and any certificate issued against the 2013 version is now void. If you are starting fresh, you must use the 2022 structure from day one.
ISO 27002:2022 mirrors the same 93 controls in the same four themes and provides detailed implementation guidance for each [6]. Think of 27001 Annex A as the checklist and 27002 as the instruction manual.
They are mandatory to consider. If they are relevant to your scope and risks, you must apply them and include them in your SoA. If they are not relevant (for example, 8.28 Secure Coding for a company that does not develop software), you can exclude them with a justification.
All eleven are split across organisational (3 controls: 5.7, 5.23, 5.30) and technological (7 controls: 8.9, 8.10, 8.11, 8.12, 8.16, 8.23, 8.28), plus one physical (7.4) [2].
Sources
- 1.ISO/IEC. (2022). "ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection - Information security management systems - Requirements". https://www.iso.org/standard/27001
- 2.ISO/IEC. (2022). "ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection - Information security controls". https://www.iso.org/standard/75652.html
- 3.ISO/IEC. (2022). "ISO/IEC 27001:2022, Clause 6.1.3 d) - Statement of Applicability". https://www.iso.org/standard/27001
- 4.GOV.UK. (2024). "DBS checks: detailed guidance". https://www.gov.uk/government/collections/dbs-checking-service-guidance--2
- 5.National Cyber Security Centre. (2023). "Secure sanitisation of storage media". https://www.ncsc.gov.uk/guidance/secure-sanitisation-storage-media
- 6.ISO/IEC. (2022). "ISO/IEC 27002:2022, Clause 4 - Structure of this document (Attribute values)". https://www.iso.org/standard/75652.html
- 7.International Accreditation Forum. (2023). "IAF Resolution 2023-17: Transition to ISO/IEC 27001:2022". https://iaf.nu/en/iaf-resolutions/
