Five ways Secure by Design quietly fails

Secure by Design is a security mandate: ten principles, evidenced, with a HIGH confidence profile you have to prove. Run that on an emailed spreadsheet and it does not fail loudly - it fails quietly, in five predictable ways. Here they are, straight from how departments actually run it today.

A security regime, run on a spreadsheet

Secure by Design is about building security into a service and being able to prove it: ten mandatory principles, assessed across the delivery lifecycle, with only a HIGH confidence profile demonstrating compliance. It is a serious security-assurance regime, not a form to file.

And the government’s own tracker for it is an Excel file - one worksheet per phase, every activity a Yes / No / N-A dropdown, the confidence profile a count of the ‘Yes’ answers. In practice the real picture is spread across ten places: the tracker, SharePoint, Teams, Jira, supplier inboxes, a hand-built governance pack, the DPIA tracker, the risk register, Confluence and pen-test PDFs. Run a security regime that way and it breaks in five predictable places.

1. No control

Five versions of the tracker are in circulation and nobody owns completion. There is no portfolio view, so the CISO finds out which projects are red when it is already too late to fix them - and nothing scales beyond a handful of projects. Security assurance without a single source of truth is not assurance; it is hope with a spreadsheet.

2. Evidence chaos

The evidence that proves each control lives in eight different systems. Teams do not share a definition of what ‘good’ looks like, so the same documents are found, attached and lost again every phase, and quality is inconsistent. A control answered ‘Yes’ with nothing behind it is an assertion, not assurance - and an assessor cannot tell the difference from a dropdown.

3. Late governance failure

Because nothing flags a gap early, missing evidence surfaces at the assurance gate, and the governance pack is assembled by hand the night before. Nobody can see what actually stands between the project and a HIGH profile until it is too late to close it calmly. Security decisions then get made under deadline pressure, which is exactly when they are made badly.

4. Weak defensibility

Then the auditor asks the simple question: who approved this N-A, and why? On a spreadsheet, nobody can answer. There is no trail of who answered what, no recorded justification for the exceptions, and the tracker often says one thing while the real assurance artefacts say another. Security you cannot defend under scrutiny is not security you can rely on.

5. Cross-team friction

None of this is only the security team’s problem. Supplier evidence arrives by email the night before the gate, the DPO’s DPIA status is invisible to the people it blocks, and security spends its week chasing Jira, Teams and inboxes. Everyone carries a piece of the pain - and everyone quietly fears the next tool will add to it rather than take it away.

Why it needs a control plane

The root cause of all five is the same: Secure by Design is being run as a document when it is really a policy model, a delivery lifecycle, an evidence system, an assurance workflow, a confidence calculator, a pack generator and an audit record - all at once. No spreadsheet is all of those things.

A control plane is. One live record per project, evidence mapped to every activity and reused across phases, a named owner on each one, gap-to-HIGH visible from day one, every N-A justified and approved, and an append-only trail behind every decision. Secure by Design is not a form to survive; it is how you prove a service was built secure and stayed that way. That is a security job, not a paperwork one.