ISO 27001 certification: the roadmap from scope to certificate

ISO 27001 certification rarely starts where people think it starts. Most organizations open the standard at Annex A, see 93 controls and begin ticking them off. That is the fastest way to lose months. A certification auditor does not test Annex A as a list. He tests the main body of the standard, clauses 4 through 10, and uses Annex A only to check whether your risk treatment holds up.

Below is the order in which a certification project does work, with the point at which each step tends to go wrong.

Step 1: define the scope

Clause 4.3 requires you to determine what your management system covers. That is the first real decision of the project and the most expensive one to reverse. The scope determines which processes, locations, systems and people fall inside the ISMS, and the wording ends up on the certificate itself.

There are two ways to get it wrong. Too broad, and you have to produce policy, evidence and internal audits for departments that have nothing to do with your service. Too narrow, and your client reads the certificate, sees that the system holding his data sits outside it, and sends his own questionnaire anyway. When in doubt, ask your largest client or prospect what he wants to see. That question usually settles the scope debate in fifteen minutes.

Determining context also means clauses 4.1 and 4.2. Since the amendment of February 2024, you have to explicitly determine whether climate change is a relevant issue for your organization, and whether interested parties have requirements about it. Anyone whose context analysis was written before 2024 and untouched since has a gap there. The article on the ISO 27001:2022 update covers that change in more detail.

Step 2: establish where you stand

A gap analysis puts what the standard requires next to what you can demonstrate. Demonstrate is the operative word. A process existing is not the same as it being documented, and documentation is not the same as evidence that it runs.

Weight the main body more heavily than Annex A. Risk assessment, objectives, competence, control of changes, internal audit and management review are requirements no organization can avoid. An Annex A control can be excluded with justification. Clause 9.3 cannot.

Step 3: risk assessment and risk treatment

Clause 6.1.2 asks for a process that is repeatable and produces consistent results, with acceptance criteria defined in advance. The 2022 version does not prescribe a method. You can work per information asset, per process, per scenario or per threat, as long as you can explain how you reached your results and the same assessment would lead to the same conclusions later.

Risk treatment determines which controls you need. Only then do you look at Annex A, which holds 93 controls across four themes: 37 organizational, 8 people, 14 physical and 34 technological. Annex A is meant as a cross-check afterwards, to confirm you have not overlooked anything. Starting there makes the risk analysis follow the controls instead of the other way around, and an experienced auditor spots that immediately.

Step 4: the Statement of Applicability

The SoA is the document auditors spend the most time in. Clause 6.1.3 asks three things per Annex A control: is it applicable, is it implemented, and why. The third column is where it goes wrong. An SoA where fifteen exclusions carry the same sentence has not been completed, it has been copied.

A usable justification points to something outside the document: a risk from your own assessment, a contractual requirement, a legal obligation, or the plain fact that you have no development team. The article on the Statement of Applicability explains how to build one.

Step 5: implement, and let evidence accumulate

The standard prescribes a set of documents and records that have to exist regardless: the scope, the information security policy, the risk assessment and risk treatment processes with their results, the SoA, the security objectives, evidence of competence, monitoring and measurement results, the audit programme and audit results, management review results, and the record of nonconformities and corrective actions.

More important than the list is the timing. An auditor does not only establish that a control exists, but that it has operated. That requires records covering a period: access reviews actually performed, changes actually approved, incidents actually handled. A control implemented two weeks before stage 2 offers nothing to sample. So start early with the processes that produce evidence, even if the policy around them is not finished.

Step 6: internal audit and management review

Both are mandatory and both must have taken place before the certification auditor starts stage 2. This is the part that gets underestimated most often, because it demands calendar time rather than technical work.

Clause 9.2 requires an audit programme that is objective and impartial. In practice that means the person who implemented a control does not assess it himself. In a small team that is awkward, and outsourcing the internal audit is the usual answer. An internal audit that only confirms everything is fine is a signal in itself. Zero findings in a first year rarely means there was nothing to find.

Clause 9.3 lists what the management review has to cover: the status of previous actions, changes in context, ISMS performance, audit results, feedback from interested parties, the risk status and opportunities for improvement. The output has to include decisions about improvements and about resources. A line in the minutes noting that the ISMS was discussed will not survive stage 2.

Step 7: choosing the certification body

Certification is performed by a certification body accredited for it. In the Netherlands, the Raad voor Accreditatie maintains the register of bodies assessed against ISO/IEC 17021-1 and ISO/IEC 27006-1. A certificate from a non-accredited party is not worthless, but many procurement departments will not accept it, so check before you sign.

Two practical points. Audit duration is not open-ended: ISO/IEC 27006-1 ties the number of audit days to the number of people doing work within the scope, with adjustment up or down for complexity. A quote well below that deserves a question.

Then there is independence. A body that advised you on building your ISMS may not subsequently certify it. ISO/IEC 17021-1 applies a two-year period. That is not a formality; it is what the value of the certificate rests on. Preparation and certification belong with different parties, which also means your advisor can never hand you the certificate. Only readiness for it. What we do in that preparatory role is described on our compliance page.

Step 8: stage 1 and stage 2

The certification audit comes in two parts.

Stage 1 assesses your documentation and your readiness. The auditor checks whether the scope is coherent, whether the mandatory documents exist, whether the internal audit and management review have been performed, and whether scheduling stage 2 makes sense. The output is usually not a list of nonconformities but a list of concerns. Take them seriously, because they come back in stage 2.

Stage 2 is the substantive audit and takes place largely on site. There the auditor tests whether the system works: he interviews staff, requests evidence, takes samples and compares practice against what has been written down.

Findings are classified as majors and minors. A major is a requirement that is structurally not met; it has to be resolved and verified before the certificate is issued. A minor usually needs an accepted corrective action plan, checked at the next audit. Observations are not nonconformities, but they mark the spot where a minor can appear next year.

If you want to know in advance how you would fare, an audit readiness assessment is the dress rehearsal.

What happens after the certificate

The certificate is valid for three years. During those three years the body returns annually for a surveillance audit, the first of which has to take place within twelve months of the certification decision. Those audits are shorter and cover part of the system, plus fixed subjects such as complaints, changes, internal audit and management review. In the third year a recertification audit reassesses the whole system.

The cycle is continuous, and that is the point of the standard. Organizations that let the ISMS lapse after certification and restart it three weeks before the surveillance audit pay more the second time than the first.

Four patterns that derail certification projects

The scope follows ambition rather than reality. An organization certifies the whole company because it looks better, then discovers at stage 2 that three departments have no evidence at all.

The evidence is younger than the audit. Controls were implemented shortly before stage 2, so there is nothing to sample. The auditor can establish that the control exists, not that it works.

The internal audit was performed by whoever built the system. That is not objective within the meaning of clause 9.2, and it produces no findings you can use.

Nobody owns the system after certification. The ISMS was a project with an end date rather than a process, and the first surveillance audit exposes that.

The same misunderstanding sits behind all four: certification is treated as an end point, while the standard describes a system that keeps running. Choose the scope honestly, start building evidence early, take the internal audit seriously, and stage 2 holds few surprises.