Every security compliance framework asks whether a control exists. Almost none of them can tell you whether it has been operating — across a full population, over an entire audit period, against the threats it was built to stop. ALCOVE is a proposed set of assurance levels for closing that gap.
Assurance Levels for Control Operating Viability & Effectiveness. It is a graduated way to say how much is actually known about a set of security controls — from "someone looked at the design" all the way to "the full population of evidence was assessed, historically, against the threats these controls exist to mitigate."
ALCOVE takes its shape from SLSA, the supply-chain assurance framework: levels give organisations somewhere to start and somewhere to climb, and give the people relying on them a way to ask for a specific rung instead of a yes/no.
Each level is cumulative. Level 4 includes everything below it.
Every security compliance framework is built from the same three parts: a set of requirements controls must meet, an audit methodology for judging how well they meet them, and a reporting artifact that conveys the result. Each part is failing in a way that limits how much assurance the whole thing can possibly provide.
Control requirements are written without explicit reference to the threats they are meant to guard against, so organisations design controls that satisfy the wording without ever being shown to stop anything.
Imagine car safety written this way: “the car implements physical restraint measures to protect passengers against threats from abrupt deceleration events.”
Transactional controls — access requests, provisioning, change tickets — do get tested historically, because a ticketing system leaves a trail. But stateful technical controls like at-rest encryption, EDR and WAFs are assessed only for their current state.
It doesn’t matter whether the audit period is 1 month or 12. A control tested only at the moment evidence was gathered was never really tested over the period.
Modern organisations change their systems dozens to thousands of times a day, and every change can quietly break a control. The report describing those controls is a PDF finalised weeks after the last evidence was reviewed.
Why do we treat a point-in-time report as carrying assurance value more than a week after it was finalised?
Levels are a shared vocabulary. An organisation can name the rung it is on; the people relying on it can require a specific rung instead of accepting a pass/fail. Each level is cumulative — every level contains the one below it.
Control designs assessed for viability.
Demonstrating commitment to pursuing independent third-party assessment of control operating effectiveness.
Level 1 requirements + samples of control evidence assessed for historical transactions or current state.
Providing basic, short-lived assurance about control operating effectiveness.
Level 2 requirements + full populations of control evidence assessed for historical transactions and state.
Providing strong, long-lived assurance about control operating effectiveness.
Level 3 requirements, including control implementations based on Common Threat Mitigations (CTM) to guard against Common Threat Criteria (CTC).
Providing strong, long-lived, threat-informed assurance about control operating effectiveness.
SOC 2 Type I and Type II still exist in this world and still carry their (limited) value. Extending the report types to III and IV lets SOC 2 express the higher rungs.
| Type | Focus | Aligns to |
|---|---|---|
| I | Suitability of controls to meet Trust Services Criteria (TSC) | — |
| II | Suitability & effectiveness of controls to meet TSC | — |
| III | Suitability & comprehensive historical effectiveness of controls to meet TSC | ALCOVE Level 3 |
| IV | Suitability & comprehensive historical effectiveness of controls to meet TSC & protect against Common Threat Criteria (CTC) via Common Mitigation Criteria (CMC) | ALCOVE Level 4 |
Reproduced from the original proposal. Note the naming: the mitigation half of the threat model appears as Common Threat Mitigations (CTM) in the levels table and the worked example below, and as Common Mitigation Criteria (CMC) here. Settling on one name is an open question for the framework.
At Level 4, criteria stop being self-contained assertions and start carrying the threats they exist to stop (CTC) alongside the mitigations known to stop them (CTM). Below is the single worked example from the original proposal: SOC 2’s CC6.6, with the ALCOVE additions marked.
| Trust Services Criteria | Points of Focus | Common Threat Criteria (CTC) | Common Threat Mitigations (CTM) |
|---|---|---|---|
|
CC6.6 The entity implements logical access security measures to protect against threats from sources outside its system boundaries. |
Protects Identification and Authentication Credentials Identification and authentication credentials are protected during transmission outside its system boundaries and protected from unauthorized transmission outside its system boundaries. Credentials are stored in encrypted forms. |
|
Maturity level 1
|
This is the only worked example the proposal contains. A full CTC and CTM catalogue does not exist yet — building one is the substantive work Level 4 implies, and an open invitation.
An audit report still matters — for context about the system, the architecture, the controls and the auditor’s opinion. But alongside it, control operating effectiveness needs metrics that carry current and historical state, the way status pages changed the conversation about uptime.
Trust Center products already publish control indicators. Most of them show only current state, and some remove a control and its green checkmark entirely while it is failing. That is assurance theatre. An honest artifact keeps the failure on the page.
Illustrative. The proposal sketches what an ALCOVE reporting artifact could look like; this is that sketch made live. Each cell is one day. Hover or focus a cell for its state. Note the control that is currently degraded — it stays on the page.
Levels 3 and 4 make demands that no compliance PDF can satisfy: a full population of evidence rather than a sample, a history that cannot be quietly rewritten, and a link from each control back to the threats it exists to stop. Those are infrastructure problems, and open-source infrastructure for them already exists.
Corsair is an open compliance trust-exchange protocol: it takes what your security tools already found and signs it into a cryptographic proof anyone can verify, without an account. It was not designed against ALCOVE — but several of its primitives are exactly what Level 3 requires.
What it already doescorsair diff compares two signed proofs and can fail a build on a regression.The CPOE specification defines a namespaced extension mechanism, which is a clean home for exactly these fields — an ext.alcove namespace carrying assurance level, population size and completeness, transaction-versus-state coverage, and CTC → CTM mappings. ALCOVE supplies the assurance semantics; Corsair supplies the verifiable envelope.
Created and maintained by Ayoub Fandi. Early-stage and openly developed — capabilities above were read from its public specification and source, not from an ALCOVE conformance claim.
ALCOVE is a proposal, not a certification scheme. There is no registry, no accreditation body, and nothing to buy. What there is: a set of levels precise enough to argue with, and a lot of unbuilt work.
What is genuinely openNothing above is technically out of reach. The obstacle is that today’s incentives all point the other way. Organisations are rewarded for cheaper, weaker audits. Auditors are rewarded for not upsetting the client. Third-party risk teams have neither the leverage nor the incentive to say no to a vendor with weak controls.
Everyone in the picture is optimising the same thing: spend fewer resources, get more value. Any framework that ignores that will be adopted by nobody.
The most plausible correction is the party with the most leverage and the strongest appetite for reducing uncertainty — cyber insurance.
Instead of a questionnaire once a year, vendors continuously publish control evidence; insurers price against it; auditors consume it instead of screenshots; and customers get assurance at diligence time and continuously afterwards.
Prior art worth studying: AIUC-1’s AI assurance-plus-insurance framework, and usage-based insurance pricing built on continuous telemetry.
“SOC 2 is dead, long live SOC 2” — the essay that introduced ALCOVE, its levels, and the SOC 2 Type III/IV extension.
Read itALCOVE is one attempt at core value #5: in-depth continuous assurance over shallow periodic monitoring.
grc.engineeringA GRC Engineering method for modelling a control against the threats it faces and the business it runs inside — the kind of reasoning a CTC/CTM corpus would need.
View TICMALCOVE is a proposal published in the open so it can be argued with. What would work, what would not, and what would make it more viable?