The UK Government publishes its Secure by Design self-assessment as a spreadsheet — an official Excel or Google Sheets template, maintained throughout delivery.
The problem begins when a completed tracker is mistaken for a fully implemented Secure by Design approach.
Secure by Design is a continuous approach to improving how cyber security is built into digital services and technical infrastructure. The tracker shows how confidently a team is following that approach. It does not assign accountability, make risk decisions, design controls, test them or keep the supporting evidence current — and it was never intended to.
Secure by Design applies to central government departments and their arm’s-length bodies delivering digital services and technical infrastructure, including new services and services undergoing significant change.
Since 1 April 2026, the Digital Assurance Playbook has replaced the former digital and technology spend-control approval process. It asks organisations to demonstrate that initiatives are following their Secure by Design approach as part of proportionate, organisation-led assurance.
The approach is built around ten mandatory principles. Delivery teams are responsible for applying them throughout the service lifecycle, with support from security professionals and other relevant specialists.
The supporting activities can be tailored to the organisation, service and risk profile; the ten principles remain mandatory.
Together, the principles address accountability, technology selection, risk, architecture, control design, operational visibility, resilience and secure change.
The official self-assessment is organised around the delivery phases of discovery, alpha, private beta and public beta or live. It should be maintained as part of normal delivery and reviewed through the organisation’s governance arrangements.
Its purpose is to show the current confidence position for each phase and identify activities that still require attention.
The profile is weighted rather than calculated as a simple count of “Yes” answers, so high confidence does not require every response to be positive.
But the profile measures adherence to the approach. Accountability, risk decisions, architecture, supplier requirements, testing and supporting evidence all have to exist in the delivery process itself — not merely as entries in the tracker.
This is why the guidance is so careful about what a good score means:
“A high Secure by Design confidence profile does not necessarily mean that your service is secure.”
— UK Government Security, ‘Tracking Secure by Design progress’
That distinction matters: a high profile indicates confidence in the delivery approach, not an independent conclusion that every security risk has been controlled. It does not prove that the threat model is complete, controls are effective, testing covered the relevant attack paths or residual risks were accepted by the appropriate owner.
For a single service with a stable team, the official tracker is entirely appropriate — and it spares departments from buying tooling just to follow the policy. The strain appears when separate project trackers become the organisation’s main operating model across a portfolio.
A name in a cell does not show who completed the activity, who reviewed the evidence, who accepted the resulting risk or who remains accountable after the service changes.
A response may remain marked as complete while the supporting architecture, test results, supplier evidence or control implementation changes elsewhere.
When the tracker is reviewed mainly before assurance or release, missing activities are discovered after important design, procurement or delivery decisions have already been made.
“N/A” does not explain why an activity was considered unnecessary, who approved that conclusion or whether compensating controls were required.
Separate project trackers make it difficult to identify repeated weaknesses, common dependencies, constrained specialist resources or systemic supplier problems across multiple services.
Good Secure by Design implementation is an operating model, not a product or a completed document. It should be proportionate to the service’s risks and revisited whenever the service, suppliers, architecture or threat picture changes.
The self-assessment should be consistent with the risk register, architecture reviews, supplier evidence and security-test results. It should not present a more favourable position than the underlying evidence supports.
The tracker enables lightweight, continuous assurance discussions, but it does not replace the organisation’s existing security-assurance arrangements. Independent internal assurance should still review the evidence where appropriate.
Technology can make the official approach easier to operate at scale. It should improve ownership, traceability, workflow and portfolio visibility without replacing the policy or inventing a separate assessment method.
A supporting platform is most valuable where multiple services, contributors and evidence sources need to be managed consistently. Its role is to strengthen traceability and oversight around the official approach — not to create a replacement framework.
The real test is whether Secure by Design changes delivery decisions.
Did the business case recognise the service’s security implications? Were the threats understood before the architecture was chosen? Were supplier requirements set before contracts were awarded? Were controls designed around risk and tested before exposure? Can risk owners see what remains, and will the position be reassessed when the service changes?
When those questions can be answered with credible evidence, Secure by Design is working as intended — regardless of whether the official tracker is maintained in Excel, Google Sheets or a supporting platform.
Occasional, practical notes on UK public-sector cyber risk and compliance. No spam, unsubscribe anytime.
More from the E2ERisk team on running Secure by Design as a living part of delivery.