ISO 27001 Readiness: A Practical Guide

ISO 27001 is frequently bought as a badge and then discovered to be a management system. That mismatch is the source of nearly every stalled certification programme: the controls get implemented, but the machinery the standard actually assesses — risk process, internal audit, management review, continual improvement — was never built, and the auditor is assessing the machinery.

This guide sets out what certification requires, in the order it has to happen.

What ISO 27001 actually is

ISO/IEC 27001 is the international standard for an information security management system. The certifiable requirements are in clauses 4 to 10 of the main body of the standard. Annex A lists 93 reference controls, which you select from based on your risk assessment — you are not required to implement all of them, but you are required to justify each inclusion and exclusion.

This distinction matters more than any other in the standard. Clauses 4–10 are mandatory. Annex A controls are selected. An organisation that implements every Annex A control but cannot demonstrate a risk process, internal audit and management review will not certify. An organisation that implements two thirds of Annex A, with documented justification, routinely does.

The 2022 revision

The 2022 edition restructured Annex A from 114 controls in 14 domains into 93 controls in four themes, and introduced 11 new controls reflecting how organisations now operate — among them threat intelligence, information security for use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding. The transition period for organisations certified against the 2013 edition ended on 31 October 2025, so new and existing certifications now run against the 2022 edition.

Step 1 — Define the scope

Scope is the first and most consequential decision in the programme. It determines how much has to be controlled, documented, audited and maintained — permanently. Scope is defined in terms of the organisational units, locations, services, systems and information involved, and it has to account for interfaces and dependencies with anything outside it.

A narrower scope is not a trick; it is legitimate and normal, provided it is honest. A SaaS company frequently certifies the platform, the teams that build and run it, and the supporting corporate functions — and excludes an unrelated business line. What is not legitimate is drawing a scope that excludes the systems your customers actually care about, because the certificate names the scope, and a sophisticated customer reads it.

Step 2 — Establish context, leadership and objectives

Clauses 4 and 5 require you to identify interested parties and their requirements, define the ISMS scope, obtain demonstrable leadership commitment, publish an information security policy, and assign roles and responsibilities. Clause 6 requires measurable information security objectives with plans to achieve them.

"Demonstrable leadership commitment" is assessed by talking to leadership. Auditors interview senior management, and a management team that cannot describe the organisation's security objectives or its major risks is a finding. Signing the policy is necessary; it is not sufficient.

Step 3 — Run the risk assessment

The risk assessment is the engine of the whole standard, and everything downstream refers back to it. It must be a defined, repeatable process — the same inputs should produce comparable outputs when a different person runs it — and it must produce documented results.

A workable process:

1. Identify what you are protecting. Information assets, systems, and the services that depend on them.
2. Identify risks to confidentiality, integrity and availability, with realistic threat scenarios rather than a generic threat list.
3. Assign owners. Every risk needs a named owner with authority to accept or treat it.
4. Analyse and evaluate against defined likelihood and impact criteria, and against a documented risk acceptance threshold agreed in advance.
5. Decide treatment — modify, avoid, share, or accept — and document who accepted what, because accepting a risk is a decision the standard permits and auditors will look for evidence of.

The most common weakness here is a risk register produced once for the audit and never revisited. The standard requires risk assessment at planned intervals and when significant changes occur; a register whose last modification date is eleven months old tells the auditor exactly what happened.

Step 4 — Produce the Statement of Applicability

The Statement of Applicability (SoA) is the single most scrutinised document in the certification. It lists all 93 Annex A controls and, for each one, states whether it applies, the justification for including or excluding it, and whether it is currently implemented.

Two rules make the SoA survive audit. First, justifications must be specific to you: "not applicable — the organisation operates no on-premises data centre; all infrastructure is cloud-hosted under A.5.23" is a justification, whereas "not applicable" alone is a nonconformity waiting to happen. Second, the SoA must trace back to the risk assessment: controls are included because a risk called for them, and an auditor will follow that thread in both directions.

Step 5 — Implement controls and produce the mandatory documentation

The standard requires certain documented information regardless of your risk profile. In practice the mandatory set is:

• ISMS scope
• Information security policy
• Risk assessment and risk treatment process
• Statement of Applicability
• Risk treatment plan
• Information security objectives
• Evidence of competence of people doing security work
• Results of risk assessments and of risk treatment
• Evidence of monitoring and measurement
• Internal audit programme and its results
• Results of management review
• Records of nonconformities and corrective actions

Beyond these, you document what your own controls require — access control procedures, supplier management, incident response, change management, secure development. The test an auditor applies is not whether a document is impressive but whether it describes what the organisation actually does. Template documentation describing practices you do not follow is worse than no documentation, because it creates a written record of a control you are failing to operate.

Step 6 — Operate long enough to have evidence

This is the step organisations try to compress, and the one that sets the floor on the timeline. Certification assesses effectiveness, and effectiveness is evidenced by records produced over time: access reviews performed, incidents logged and closed, training delivered, suppliers assessed, backups tested, changes approved, risks reviewed.

Three months of operation is a common practical minimum before a Stage 2 audit; more is safer. There is no way to generate this retrospectively — an auditor sampling twelve months of change records will notice that all of them were created in the same week.

Step 7 — Internal audit and management review

Both are mandatory, both must happen before certification, and both are commonly underestimated.

Internal audit must cover the ISMS against the standard and against your own requirements, on a planned programme, conducted by someone objective with respect to the area being audited. In a small organisation, that usually means an external internal auditor — which is permitted — or a colleague from an unrelated function. What is not permitted is the person who built the ISMS auditing their own work.

Management review is a documented meeting at which leadership reviews defined inputs: audit results, the status of corrective actions, performance against objectives, feedback from interested parties, risk assessment status, and opportunities for improvement. The output must include decisions. Minutes recording that a review took place, with no decisions, are a nonconformity.

Step 8 — The certification audit

External certification is carried out by an accredited certification body — accredited by a national body such as UKAS in the United Kingdom or ANAB in the United States. The audit has two stages.

Stage 1

A readiness review, largely of documentation. The auditor checks that the ISMS exists, that scope, policy, risk assessment, SoA and mandatory documents are in place, and that internal audit and management review have been performed. The output is a report identifying anything that must be resolved before Stage 2. It is normal for Stage 1 to identify gaps; that is what it is for.

Stage 2

The certification audit proper, assessing whether the ISMS is implemented and effective. The auditor samples evidence, interviews staff across the organisation, and tests whether what the documents describe is what happens. Findings are raised as major nonconformities (which must be resolved before certification), minor nonconformities (which need a corrective action plan), or observations.

Afterwards

Certificates run on a three-year cycle, with surveillance audits — typically annual — and a full recertification audit at the end of the cycle. The management system is expected to keep operating throughout: risk reassessment, internal audit, management review and improvement continue whether or not an auditor is due.

Realistic timelines

Cost varies with size, scope and complexity, and splits into three parts that are worth budgeting separately: internal effort (usually the largest and most often ignored), consultancy support if used, and certification body fees, which are priced on auditor-days and recur annually through the cycle.

Where programmes go wrong

• Treating it as a documentation exercise. The auditor interviews staff. If the people operating a control cannot describe it, the document does not save you.
• Buying a template pack and filling in the company name. Templates are a starting point. Shipped unedited, they describe an organisation that does not exist, and every gap between document and reality is a finding.
• Scoping too broadly at the start. An over-wide initial scope adds work everywhere, permanently. Certify a defensible scope, then extend it at recertification.
• Skipping internal audit or management review. Both are mandatory and both are checked at Stage 1. Neither can be produced retrospectively with any credibility.
• Leaving no owner after certification. The system has to run continuously. Programmes with no owner after the certificate arrives fail their first surveillance audit.
• Confusing certification with security. A certificate says a defined set of controls was assessed on a date. It does not say your systems cannot be broken into — which is why the standard itself expects technical testing, and why the testing evidence feeds directly back into the ISMS.

What certification does and does not tell a buyer

Read as a customer, an ISO 27001 certificate tells you three things: an accredited third party assessed this organisation, against a defined scope printed on the certificate, within a defined validity period. That is genuinely meaningful — it is far more than a self-assessment — and it is also narrower than it is often presented as.

It does not tell you that the certified organisation has no vulnerabilities, that the specific service you are buying is in scope, or that controls were operating on any particular day between audits. If you are relying on someone's certificate, read the scope statement, check the expiry, and verify it with the certification body — certificates are sometimes cited long after they have lapsed.

Related reading

• SecIQ compliance consulting — how we support ISO 27001, SOC 2, PCI DSS, GDPR and NIS2 programmes.
• How to scope a penetration test — the testing evidence an ISMS needs.
• Building an incident response playbook — Annex A incident management, made operational.