Attestation Is Not Evidence: Closing the Continuous-Proof Gap

Every compliance program produces a stack of attestations. A signed vendor questionnaire. A SOC 2 report in a shared drive. A policy someone acknowledged in a training portal. They all say the same underlying thing: on some date, a party claimed a control existed. None of them say the control was working the day you were breached. That distance, between what was attested once and what is true continuously, is where a great deal of risk quietly lives.

What an attestation actually proves

An attestation is a claim, captured at a point in time, usually by the party being assessed. A vendor security questionnaire is a self-attestation: the vendor grades its own homework. Even a SOC 2 Type II report, which is real and serious work, covers a review window that closed before you opened the document, and it samples evidence rather than observing every control on every day. At its best, an attestation proves that a control existed and was exercised during a sample. It does not prove the control is operating right now.

That is not a criticism of auditors. It is the nature of the instrument. A photograph is proof of a moment, not proof of the months that followed it.

Why the gap matters

Threats move continuously. Attestations do not. Credentials leak, a firewall rule drifts, multi-factor authentication gets switched off on a service account "just for the migration," a certificate expires on a Friday. A vendor's posture on the day you signed the contract says very little about its posture on the day it is breached. Our own research found that third-party involvement in breaches doubled to 30% in a single year, and most vendor programs still run on a point-in-time questionnaire completed at onboarding and never revisited. The breach does not check whether you have a signed attestation on file.

The three ways attestation quietly fails

• Drift. The claim was true on signing day and false three months later, and nobody re-checked. This is the common case, and it is invisible until an incident makes it visible.
• Self-report bias. Most vendor attestations are self-assessments. The party with the most to lose from a bad answer is the party writing the answer.
• Sampling. Even independently audited controls are sampled, not watched continuously. A control can pass its sample and fail in the gaps between.

What continuous evidence looks like

The alternative is not more paperwork. It is a different kind of proof. Instead of "do you enforce MFA?", which is a claim, continuous evidence is the live signal: MFA is enforced on every administrative account right now, checked against the identity provider today. It is the difference between a control's description and its telemetry.

In a program, that looks like three shifts:

• High-consequence controls are tied to system signals you can query on demand, not to answers in a spreadsheet.
• Evidence refreshes on its own between reviews, rather than being reassembled once a year in a fire drill before the audit.
• Vendor risk watches a vendor's actual, ongoing security posture, not the attestation it wrote at onboarding.

This is the idea our engagements are built on: the register and the evidence stay current between reviews rather than aging in a document nobody reopens until something breaks.

Attestation still has a job

To be fair to the paperwork: attestations are not worthless, and this is not an argument to throw them out. A contract's breach-notification clause and audit rights are attestations, and you want them. A SOC 2 report is a meaningful signal that a vendor has done real work. The point is narrower and more useful than "attestations are bad." It is this: stop mistaking a claim for proof of a live control, and close the distance between the two.

How to close the gap

• Map your highest-consequence controls to a live signal you can pull on demand, and treat the ones you cannot verify as risks, not as passes.
• Replace annual vendor questionnaires with continuous monitoring of the signals that actually matter for your critical vendors.
• Treat "we attested to that" as the beginning of verification, not the end of it.
• Keep your own internal evidence, the risk register, access reviews, and incident records, as first-party proof that does not depend on anyone else's word.

Compliance was always meant to be a proxy for security. When the proxy is a claim made once and filed away, the proxy drifts from the thing it was supposed to represent. Continuous evidence is how you keep the two pointed at each other.

Frequently Asked Questions

What is the difference between attestation and evidence?

An attestation is a claim that a control exists, captured at a point in time and usually made by the party being assessed. Evidence is proof that the control is operating, ideally drawn from a live system signal. Attestation tells you what someone said; evidence tells you what is true now.

Is a SOC 2 report not enough on its own?

A SOC 2 Type II report is a strong signal, but it covers a review window that has already closed and samples controls rather than observing them continuously. It proves diligence during the audit period. It does not prove a control is working today, which is why it should be paired with ongoing verification for the controls that matter most.

What is continuous compliance?

Continuous compliance ties controls to live system signals so their status is verified on an ongoing basis rather than reconstructed once a year for an audit. It shifts the question from "did we attest to this?" to "is this control operating right now, and can we show it?"

How do we move from attestation to evidence?

Start with your highest-consequence controls: map each to a signal you can query on demand, replace point-in-time vendor questionnaires with continuous monitoring for critical vendors, and treat any control you cannot currently verify as an open risk rather than a completed checkbox.