Borrowed blueprints¶

An organisation without an information security management system, told to build one, reaches for a standard the way a first-time house builder reaches for someone else’s plans. It is a reasonable instinct. The plans are complete, the terminology is shared with every auditor and customer who will ever ask questions, and “the standard requires it” unlocks budget that “I am worried about this” never has. The blueprint is borrowed for good reasons. The cost is forgetting it is borrowed.

What the blueprint buys¶

A standard is a completeness check written by people who have watched many organisations fail in many ways. It names the parts a security programme needs, points at the ones enthusiasm tends to skip (asset inventories, management review, decommissioning), and gives a board a fixed external reference point that does not move when internal politics do. For an organisation starting from little, that scaffolding is worth having. Few of the expensive failures in this territory come from the standard itself.

An ISMS shaped like the standard¶

The expensive failures come from the transfer. The recurring one is a management system shaped like the document that inspired it rather than like the organisation it is meant to protect: folders arranged by clause number, controls adopted because they appear in Annex A rather than because a risk in the register asks for them, policies written to be shown rather than followed. Documentation arrives before understanding, and then quietly replaces it.

An organisation can get good at this. It learns the vocabulary, passes the audits, and performs its ISMS on demand. The performance is not free: it costs exactly the effort that lived practice would have cost, and buys none of the protection. A management system can survive as documentation and fail as practice, which is the second foundation’s oldest observation wearing a lanyard.

The parts that stay hard¶

The blueprint cannot supply the three things the building actually stands on.

An honest risk assessment. The rational exercise is straightforward; the register it produces is systematically incomplete in predictable ways, because some risks are socially expensive to name and some framings serve somebody’s interests. The three domains material covers why, and no clause requires what it takes to counter it.

A management review that reviews. The standard mandates the meeting. It cannot mandate that leadership reads the inputs, asks the uncomfortable question, or changes a decision because of what it heard. A review that receives information without acting on it satisfies the clause and starves the system.

A bearer who is not alone. Somewhere in the first year, one person becomes the ISMS: writes it, feeds it, translates for it. The standard assumes an organisation carries the system; organisations routinely delegate that to an individual and then describe the result as implemented. What happens when that individual resigns is not in the manual, though it is usually in the risk register of anyone brave enough to add it.

Checklist, not design¶

The escape from the trap is a change of direction. Design the security the organisation’s own risks ask for, in the organisation’s own shape, and then hold the standard against it as a checklist: what did we miss, what would an outsider need to see, what do we call this so an auditor recognises it.

Used that way, the standard verifies the design instead of becoming it. What a standard does to the thing it measures is a pattern with a longer story, traced in the broomstick note on what a standard converts; the short version is that a blueprint makes a fine measuring stick and a poor architect.

The organisations that come out of this well tend to be the ones that could, at any point, explain their ISMS without mentioning the standard at all.

Last updated: 4 July 2026