← Insights

Information security

Building an ISO 27001 ISMS without starting from a blank page

July 2026 · 7 min read

Most people meet ISO 27001 as a demand from a customer or an investor: "are you certified?" They then discover that the standard does not ask for a document. It asks for a system - an Information Security Management System, the ISMS - and the certificate is just an accredited body confirming, after its own audit, that the system exists and works. Understanding what the system is made of is the difference between a project that lands and one that stalls for a year.

An ISMS has two halves, and both matter. The first is the management system itself, set out in clauses 4 to 10 of the standard. The second is the set of security controls in Annex A. Miss either half and the audit finds the gap.

The management system: clauses 4 to 10

Strip away the jargon and the six main clauses are a plan-do-check-act loop that any manager would recognise.

• Clause 4 - Context. Who your interested parties are, what they need from you, and where the boundary of your ISMS sits. Scope creep here is scope creep everywhere, so this clause is worth getting right.
• Clause 5 - Leadership. A security policy that management own, with roles and responsibilities that are actually assigned to named people.
• Clause 6 - Planning. The risk assessment and treatment engine, plus measurable objectives. This is where information security stops being aspiration and becomes a decided list of risks and what you are doing about each.
• Clause 7 - Support. Resources, competence, awareness, and controlled documents.
• Clause 8 - Operation. Running the plan - the risk treatment carried out and the day-to-day security work done.
• Clauses 9 and 10 - Check and act. Internal audit, management review, metrics, and corrective action that closes the loop.

Read as a whole, it says: understand your context, decide your risks, treat them, run the operation, then check and improve. The policy points at the procedures, the procedures point at the registers, and the registers hold the evidence. That chain is what an auditor traces.

The 93 controls, and the document that governs them

Annex A of the 2022 edition lists 93 controls across four themes - organisational, people, physical and technological. They are the menu of security measures: access control, cryptography, supplier security, secure development, backup, physical protection and the rest. Crucially, you do not have to implement all 93. You have to make a considered decision about each one, and record it.

That record has a name, and it is the single most important document in the whole system: the Statement of Applicability, or SoA. It lists every one of the 93 controls and, against each, states whether it applies, why, its implementation status, and its owner. It is the first document most auditors open, because it is the map between the abstract standard and your actual organisation. If a control is excluded, the SoA is where you justify it. If it is included, the SoA is where you point to the policy or procedure that implements it.

The Statement of Applicability is the spine of an ISMS: every control decision lives on it, and every piece of evidence hangs off it.

Get the SoA right and the rest of the pack has a home. Get it wrong - a spreadsheet with 93 rows and no cross-references - and you have a list, not a system.

Why a coherent set beats assembling it piecemeal

The tempting route to an ISMS is free downloads: a policy from one site, a risk register from another, a procedure from a third. The problem is not that any single file is bad. It is that they do not agree with each other. The policy references a procedure that does not exist. The risk methodology scores one way and the register scores another. The SoA points to controls that no document actually implements. An auditor finds these seams in minutes, and every seam is a nonconformity.

A set built to one standard removes the seams by design. When the same hand writes the policy, the procedure and the register, the cross-references line up, the terminology is consistent, and the evidence trail is continuous. You spend your time adapting the system to how you really work, not reconciling forty documents that were never meant to sit together.

Start with the core documents and the SoA, decide which controls apply, adopt the policies and procedures that fit, and keep the registers as your live records. That order - context, then risk, then controls, then evidence - mirrors the clauses, and it is the fastest honest route from a blank page to something an assessor can follow.