Most ISO 27001 projects fail not because the controls are hard, but because the organisation treats certification as a paperwork exercise instead of a management system. The 2022 revision of the standard sharpened that distinction. It restructured Annex A from 114 controls into 93, grouped them under four clean themes, and made it harder to hide an immature security programme behind a thick binder of policies nobody reads. This guide walks through what a genuine readiness effort looks like, with the theatre removed.
The ISMS is the product, not the certificate
ISO 27001 certifies an Information Security Management System (ISMS). The certificate is downstream evidence that the system exists and works. Auditors are trained to test whether decisions are made on the basis of risk, whether controls are operated consistently, and whether the organisation improves over time. A polished policy library with no operating evidence behind it is the single most common reason a stage two audit goes sideways.
The clauses that carry the real weight are 4 through 10: context of the organisation, leadership, planning, support, operation, performance evaluation, and improvement. Annex A is a reference list of controls you select from based on your risk assessment. If you start by copying all 93 controls into a spreadsheet and writing a policy for each, you have already inverted the standard. Start with risk, then select controls that treat that risk.
The four Annex A control themes
The 2022 revision organises controls under four themes, which makes scoping and ownership far cleaner than the old fourteen domain structure.
Organisational controls (37 controls)
These cover policies, roles, supplier relationships, threat intelligence, cloud service use, and information classification. This is where governance lives. Two controls were genuinely new in 2022 and tend to trip people up: threat intelligence (5.7) and information security for use of cloud services (5.23). Both require demonstrable process, not just a paragraph in a policy.
People controls (8 controls)
Screening, terms of employment, awareness training, disciplinary process, and responsibilities after termination. Auditors will ask for evidence that a leaver had access revoked promptly, so your joiner-mover-leaver process needs to actually run, not just be documented.
Physical controls (14 controls)
Secure areas, equipment, clear desk and screen, and secure disposal. For cloud-native firms this theme shrinks considerably, but you still own offices, laptops, and the disposal of media. Do not over-claim applicability here just to look thorough.
Technological controls (34 controls)
Access control, cryptography, secure development, logging, vulnerability management, and the new controls for data masking (8.11), data leakage prevention (8.12), web filtering (8.23), and secure coding (8.28). This theme maps most directly onto systems you already run.
The Statement of Applicability is your honest map
The Statement of Applicability (SoA) lists every Annex A control, whether you have included or excluded it, the justification, and its implementation status. It is the document an auditor reads first because it reveals whether you understand your own environment. Excluding a control is completely legitimate when justified. Excluding physical entry controls because all infrastructure is on a managed cloud platform is defensible. Excluding cryptography because it felt like too much work is not.
Write the justifications as if a sceptical auditor is reading them, because one will be. Tie each included control back to a risk in your risk register and to the system or process that operates it.
Risk assessment without the spreadsheet ritual
Clause 6.1.2 requires a repeatable risk assessment process with defined criteria for accepting and treating risk. The failure mode is a one-time spreadsheet that scores forty risks as medium and is never opened again. A working risk assessment identifies assets and threats, assesses likelihood and impact against criteria you defined in advance, and produces a treatment plan that assigns owners and dates.
Keep the methodology simple enough that people will actually repeat it each year and after major changes. A defensible qualitative model with clear criteria beats an elaborate quantitative model that only one person understands.
Mapping controls to systems you already run
Almost every organisation already operates most of ISO 27001 informally. Identity provider enforcing multi-factor authentication, cloud logging, endpoint protection, vulnerability scanning, and code review in pull requests all map directly onto Annex A. The readiness work is mostly about formalising what exists: writing down the policy, capturing the evidence, assigning the owner, and setting the review cadence.
- Access control (5.15, 8.2, 8.3) maps to your identity provider and privileged access management.
- Logging and monitoring (8.15, 8.16) maps to your SIEM, cloud audit logs, and any managed detection service.
- Secure development (8.25 through 8.28) maps to your SDLC, code review, and dependency scanning.
- Vulnerability management (8.8) maps to your scanning cadence and patch process.
A gap assessment that walks each control against the system that implements it will surface the real gaps quickly, usually in evidence collection and review cadence rather than in missing technology. Our team often pairs this with a penetration test and security audit so the technical controls have independent evidence behind them rather than a self-assessment.
Internal audit and the path to stage one
Before a certification body arrives, clause 9.2 requires you to run an internal audit of the ISMS. This is not a formality. A genuine internal audit, run by someone independent of the controls being audited, finds the nonconformities while you can still fix them cheaply. Management review (clause 9.3) then takes those findings, performance metrics, and risk changes to leadership for decisions. Auditors look for evidence that leadership engaged, not that a meeting was scheduled.
The external audit runs in two stages. Stage one reviews your documentation and readiness. Stage two tests whether the ISMS operates in practice over a sustained period, which is why you need several months of operating evidence before you book it.
Takeaways
- ISO 27001:2022 certifies a working management system, so build the system first and let the certificate follow.
- Use the four Annex A themes to scope and assign ownership cleanly.
- Write a Statement of Applicability and risk register an auditor would believe.
- Map controls onto the tools you already run, then formalise evidence and review cadence.
- Run a genuine internal audit and management review before you book stage two.
If you want a readiness assessment that tells you where you actually stand rather than selling you a binder, talk to the Basalt Cyber team about a gap analysis mapped to your existing environment.