NCSC Principles Based Assurance

Most compliance work asks whether a control is in place. Principles Based Assurance asks something harder: state what is true of your product, explain why it is true, and show the evidence. An accredited assessor records a verdict against each claim, and an unevidenced claim is not a pass.

That difference decides how much work an assessment costs. A control framework tolerates a policy document as evidence of intent. An assurance claim generally does not: the assessor wants the artefact the process itself produced, dated, and checkable without taking your word for it.

It is also why assessments are rarely finished in one round. The usual pattern is a spreadsheet that travels back and forth — the assessor annotates each claim, the vendor gathers more evidence and re-sends everything, and both sides lose track of which version of which artefact supported which claim.

Four patterns account for most of the evidence an assessor sends back, and none of them are about the security of the product:

• Evidence that was pointed at but never produced. A claim cites a process that exists, but no artefact from that process is attached.
• Dead citations. A reference to a document, ticket or dashboard the assessor cannot open, in a submission where nobody checked the links resolve.
• A cadence asserted rather than shown. "We review this quarterly" with one artefact, dated once.
• Implementation artefacts where assurance artefacts were wanted. A design document proves a design was written, not that the product was built to it.

Every one of these is a repeat-evidence problem rather than a security problem. They are what happens when evidence is gathered by hand, once, under deadline.

ContinueOps treats a claim the same way it treats a recovery objective: something you prove on a schedule, not something you assert once.

• Collectors that run where the evidence is. A single static binary is fetched onto whatever runner already builds your software — no image to change — and produces a component inventory, a dependency audit position, an access register, a build-environment configuration export and more, each digested and bound to the claims it supports.
• Anything else attaches as it is. There is no requirement to instrument anything before you start. An existing artefact — a screenshot, a report, a signed letter — can be bound to a claim with a digest on day one.
• Sealed evidence bundles. Each cycle is sealed into a tamper-evident bundle: a Merkle root over every artefact, a post-quantum signature, and RFC 3161 timestamps from independent authorities. The claim mapping travels inside the bundle, so what was collected and what it was collected for cannot drift apart.
• Their spreadsheet, not ours. The assessor's own workbook is read, filled in and returned. Their verdict columns are read and never written. The assessor keeps the process they already have and gets references that resolve, with a digest beside each one.
• A submission that checks itself. The pack that leaves the building carries a short verification script that needs no account, no credentials and no access to us — the assessor runs one command in the folder that arrived.

It does not decide whether a claim is met. Evidence is submitted; the verdict belongs to the assessor, and nothing here is designed to anticipate it.

A timestamp proves an artefact existed at a point in time. It does not prove the artefact is true, and any tool that implies otherwise is one an assessor should be sceptical of.