The most common way a from-scratch ISO 27001 effort goes wrong isn't a lack of work — it's the wrong sequence of work. A team downloads a policy pack, fills in a year's worth of templates, ticks Annex A controls against a checklist, and arrives at Stage 2 with a thick binder and a confident expectation of certification. Then the auditor asks where the risk assessment is that justifies any of it, and the program quietly comes apart. ISO 27001 doesn't certify documents. It certifies a management system that operates — and that distinction decides whether the binder is the program or just an artefact of it.
It's a Management System, Not a Binder
ISO 27001 is built on the Plan-Do-Check-Act cycle, and that cycle is the whole point. The requirements that get certified live in Clauses 4 through 10 — context, leadership, planning, support, operation, performance evaluation, and improvement. That's the engine: the part that decides what matters, makes it happen, checks whether it worked, and corrects course. Annex A — the catalogue of information security controls — is the toolbox you draw from once the engine tells you what needs protecting. It is not the standard; it is the inventory of options the standard's risk process selects from.
Teams that treat ISO 27001 as a document set fail for a structural reason, not a sloppy one. The standard certifies a system that operates, not a folder that exists. A folder can be complete and still certify nothing, because completeness was never the test — operation is. An auditor reading Clauses 4 to 10 is looking for a living process with inputs, decisions, evidence and outputs over time. A binder, however well written, is a snapshot of intent. The program is the machine that produced it and keeps running, and that is what the certificate attests to.
Start With Context and Scope
Clause 4 is where a real program begins, and it asks three things in order: understand the organisation and its context, understand the interested parties and their requirements, and then define the boundary of the ISMS. Context means the internal and external issues that bear on information security — your business model, your regulatory environment, your dependencies. Interested parties are the customers, regulators, partners and staff whose requirements the system has to satisfy. Only once those are clear does the scope statement make sense, because scope is the line you draw around what the ISMS actually covers.
Scope is the highest-leverage decision in the entire program, and it deserves more deliberation than it usually gets. Draw it too broad and you pour effort into systems, sites and teams that didn't need certifying, inflating cost and timeline for no commercial return. Draw it too narrow and you carve out exactly the thing a customer's security questionnaire will ask about, leaving a gap that undermines the certificate's value the moment it's scrutinised. Every downstream artefact — the risk assessment, the Statement of Applicability, the controls themselves — is bounded by this one line, so it pays to get it right before anything else is written.
Leadership, Then Risk
Clause 5 comes before the risk work for a reason: without genuine leadership the rest is theatre. It calls for real management commitment — not a signature, but resourcing, attention and accountability — together with an ISMS policy that sets direction and assigned roles with the authority to act. A program that top management treats as a compliance errand for one overworked person will show that thinness everywhere downstream. The standard puts leadership early because every later clause depends on the mandate it establishes.
Clause 6 is the planning core, and the heart of it is the risk assessment and risk treatment process. You identify the information security risks within scope, assess them, and decide how to treat each one — and it is that treatment decision that determines which Annex A controls actually apply to you. This is the inversion most from-scratch programs get backwards. Controls follow risk, not the other way around. You do not start from the Annex A list and ask which ones to implement; you start from your risks and let the treatment plan pull in the controls that address them. A control with no risk behind it is effort spent answering a question nobody asked.
Build the SoA From the Risk Treatment
The Statement of Applicability is the document that connects everything, and auditors scrutinise it more closely than almost anything else in the system. The SoA lists every Annex A control with an explicit include-or-exclude decision, and — crucially — a justification for that decision that traces back to the risk treatment plan. A control is in because a treated risk required it; a control is out because, for a stated reason, no risk within scope did. An SoA that reads like a filled-in template, with every control marked applicable and no line of reasoning behind it, tells an auditor immediately that the risk assessment underneath is missing or cosmetic.
| Phase | Clause | What you build |
|---|---|---|
| 1. Context & scope | Clause 4 | Scope statement, interested parties, ISMS boundary |
| 2. Leadership | Clause 5 | ISMS policy, roles, management commitment |
| 3. Risk | Clause 6 | Risk assessment, risk treatment plan, SoA |
| 4. Operate | Clauses 7–8 | Controls, competence, documented information |
| 5. Check & improve | Clauses 9–10 | Internal audit, management review, corrective action |
The failure pattern is almost always the same: policies written before the risk assessment, an SoA that doesn't trace to any risk, controls marked "implemented" with no evidence they actually operate, and no internal audit or management review on record. Each one looks like progress and proves nothing — and Stage 2 is designed to find exactly these gaps.
Operate It Before You Certify
There is a requirement no amount of documentation can shortcut: you need a period of operating records before Stage 2 is meaningful. Concretely, that means at least one internal audit completed, at least one management review held, and evidence that your controls have actually run over a stretch of time — logs, tickets, review minutes, the residue of a system in use. These aren't bureaucratic boxes; they're the inputs the Check and Act parts of the cycle depend on, and Stage 1 will already be looking for whether they exist.
Stage 2 assesses effectiveness, not existence. The auditor is not checking whether a policy says access reviews happen quarterly; they're checking whether the last few quarterly access reviews actually happened and produced a record. A program switched on the week before the audit can describe everything it intends to do and demonstrate none of it, because there's nothing behind the intentions yet. The ISMS has to have been running long enough to leave a trail, which is why certification is the end of a period of operation, not the start of one.
Assign an Owner, or It Decays
An ISMS is a living system, and like any living system it needs tending or it dies. That means a named owner with real authority — someone whose job explicitly includes running it, not a committee that meets when it remembers to. It means a review cadence: internal audits and management reviews on a schedule, risk assessments revisited, controls re-checked. And it means a living evidence trail that keeps accumulating, so the next audit has something to look at. Without those three things an ISMS quietly rots back into the very state that fails the first surveillance audit a year later.
The mindset shift that separates durable programs from one-off certification scrambles is simple: the certificate is the start of the obligation, not the end. The day you pass Stage 2 you have committed to operating a management system continuously, and the surveillance audits that follow exist to confirm you are. A program built to clear a single audit and then left alone will be visibly decaying by the first surveillance visit, because an ISMS that isn't operated isn't an ISMS — it's a binder again.
Program Theatre vs. Program Substance
The distance between something that looks like an ISMS and something that is one comes down to a handful of recurring tells. The pattern is consistent enough to read at a glance:
| Looks like an ISMS | Is actually an ISMS |
|---|---|
| ✗ Policies written before the risk assessment | ✓ Risk assessment first, policies built on it |
| ✗ An SoA copied from a template | ✓ An SoA traced to real, treated risks |
| ✗ Controls implemented on paper | ✓ Controls with evidence they operate |
| ✗ No internal audit before Stage 2 | ✓ Internal audit and management review on record |
| ✗ Annex A treated as the whole standard | ✓ Clauses 4–10 run as the management system |
| ✗ No named owner after certification | ✓ An ISMS owner and a review cadence |
| ✗ A binder finished once | ✓ A system operated continuously |
Final Thought
Building an ISO 27001 program from scratch is less about writing than about sequencing. Context and scope set the boundary; leadership supplies the mandate; the risk assessment decides what matters; the SoA records why each control is in or out; operation generates the evidence; and an owner keeps the whole thing alive after the certificate is framed. Done in that order, the documents are the by-product of a working system. Done in reverse — documents first, risk and operation as an afterthought — you get a binder that looks finished and proves nothing.
The test: if Stage 2 were next month, could you show an internal audit, a management review, and an SoA that traces every control to a risk — or only a folder of policies? If it's only the folder, the program isn't behind on paperwork; it's missing the management system the standard actually certifies, and no amount of last-minute writing will produce the operating record that's now too late to create.
Frequently Asked Questions
With context and scope (Clause 4), not policies. Scope decides cost and effort, and everything downstream — the risk assessment, the SoA, the controls — depends on it. Policies written before the risk assessment usually have to be redone.
No. Annex A is the toolbox; the management system in Clauses 4 to 10 is what's actually certified. Auditors test the system — the risk process, internal audit, management review and improvement — at least as hard as individual controls.
Long enough to generate records — typically a few months covering at least one internal audit and one management review — because Stage 2 assesses whether controls operate effectively over time, not just whether they exist.
Usually sequence: a binder of policies with no underlying risk assessment, an SoA that doesn't trace to risks, controls that exist on paper but produce no operating evidence, and no internal audit or management review on record.