Summary
- The model connects signals, metrics, evidence, assertions, and decisions to support software assurance throughout delivery.
- It retains a five-stage lifecycle — define, build, validate, release, and operate — with operational evidence feeding subsequent changes.
- Mature implementations could automate some low-risk approvals while keeping exceptions and higher-risk decisions under accountable human governance.
The UK defence establishment has published a methodology for moving software assurance away from periodic document reviews and towards continuous evidence generated by the systems being built and operated.
Cyber & Specialist Operations Command published the 28-page framework on 21 September, proposing an evidence-led approach intended to align governance with modern software delivery.
The methodology starts from a familiar problem: software may be built, tested, deployed, and changed continuously, while approval structures still rely on static artefacts, scheduled reviews, stage gates, and manually assembled documentation.
That produces a timing problem as much as a process problem. Evidence that accurately described a service when an approval pack was prepared may no longer describe it after changes to code, dependencies, configuration, operating conditions, or the threat environment.
The new model organises assurance around five connected concepts: signals, metrics, evidence, assertions, and decisions. Raw observations generated by systems become metrics; those observations are then interpreted in context as evidence; explicit assertions define what needs to be true; and accountable decision-makers determine whether the evidence provides sufficient confidence to proceed.
The paper is careful not to equate telemetry with assurance. A system can generate enormous volumes of monitoring data without answering the governance question that actually needs to be resolved. Evidence only becomes useful when it is connected to a specific assertion, such as whether a service is stable, secure, or ready for release.
That distinction leads to what the command calls “minimum viable evidence”: the smallest credible set of information needed to support a particular assertion with sufficient confidence. The intention is to prevent continuous assurance from becoming continuous bureaucracy.
The lifecycle remains structured around define, build, validate, release, and operate, but the stages are treated as iterative assurance viewpoints rather than one-way gates. Operational evidence from a deployed service feeds into the next change rather than disappearing after a release decision.
The approach does not remove formal governance. Architecture, service management, cyber security, operations, and accountable risk owners remain part of the decision chain. The proposed change is that those functions receive evidence that is more current, traceable, and connected to the state of the system at the time a decision is made.
The methodology also leaves room for automated approval of lower-risk and well-understood changes. That would only apply where evidence thresholds are defined, controls are operating reliably, and exceptions remain visible to human reviewers. Higher-risk changes would continue to require judgement and formal governance.
For large organisations, the difficult part is likely to be the evidence supply chain underneath the model. Build systems, test tools, deployment platforms, observability services, security products, and operational records all generate relevant information, but their output has to be trustworthy, attributable, and linked to the decision being made.
That creates its own control requirements. If assurance depends on automated evidence, the integrity of CI/CD pipelines, test environments, monitoring systems, identity controls, and evidence retention becomes part of the assurance system itself.
The paper is the first part of a three-part approach. Later work is intended to define lifecycle assurance requirements and address adoption, pilots, and wider implementation. Its immediate significance lies in the direction of travel: governance is being treated less as a periodic approval event and more as an ongoing ability to demonstrate the state of a changing system.
