concept

Evidence Retention Window

also called Evidence Window, Assurance Retention Horizon

The span for which control evidence has to stay reproducible - the assurance period plus report lag plus the next cycle - which is routinely far longer than the retention anyone set on the systems that hold it.

audit-evidenceretentionobservation-perioddata-minimisationappend-only

In February an assessor asks for the record of every production change since the previous April. The pipeline keeps build logs for 90 days. Nine of the twelve months are already deleted, and no amount of engineering recovers them, because a retention policy set for debugging convenience quietly decided how far back the company can prove anything.

The controls ran correctly every day. The organisation simply cannot show it, and an unprovable control is indistinguishable from an absent one.

Why it matters

A period-based opinion is a claim about every day in the window, not about today. Observation windows run from a quarter to a year, the report is issued weeks to a couple of months after the window closes, and the next window usually opens the day the last one closed. Add those up and the evidence needs retention on the order of 400 to 450 days for an annual report - not 90, and not 365.

Operational logs and control evidence have opposite decay curves. A build log is valuable for a week. A control record is worthless until somebody asks and then decisive, fifteen months later. One retention for both guarantees paying too much for one and too little for the other.

The size asymmetry is the opening. The evidence an assessor needs is a few hundred bytes per event: actor, action, subject, check, outcome, change id, artefact digest, timestamp. The build log around it is megabytes.

Implementation patterns

  • A separate append-only evidence stream, written by the control as it operates rather than assembled on request, with its own retention set from the window and not from the log platform's default.
  • Immutability held outside the assessed team: object-lock storage with the delete permission in another account, so the people under assessment cannot alter the record.
  • A monotonic sequence number per control, so a missing record is a detectable gap rather than silence, and the denominator with every batch - how many items were in scope, not only how many passed.
  • Retention set per control rather than globally. In-scope controls get the window; everything else keeps the short operational retention, which is what keeps minimisation intact.
  • Identifiers and outcomes, not payloads. Where the payload matters, retain a hash for 450 days and the payload for 30.

Industry example

A developer-tools company of JetBrains' shape meets this in its sharpest form: the pipeline records that evidence its change-management control are the same hosted build logs its customers read, and build log retention is tuned to storage cost in the tens of days. The resolution available to anyone in that position is to stop treating them as one thing - emit a small structured control event beside the log, retain the event for the assurance window, and leave log retention where the product wants it.

Failure scenarios

  • A cost-saving project shortens log retention with no owner aware those logs were evidence, discovered at the next assessment when the only remedy is a shorter scope.
  • Retention extended globally to satisfy an assessor, creating a minimisation breach and a large bill to preserve a tiny structured subset.
  • Evidence stored where the assessed team can delete it, so integrity is challenged even though nothing was deleted.

Trade-offs

Choose Gains Pays
One long retention on everything Nothing to build Storage cost and a minimisation problem
Separate evidence stream Cheap, immutable, defensible A second pipeline whose completeness you must prove
Rely on vendor audit trails No build at all Their retention tier and scope decide yours

The second row is almost always right, and its real cost is the completeness proof: an assessor asks how you know the stream holds every instance, and the answer has to be a mechanism.

When not to use it

For a point-in-time assessment, current state is the evidence and a historical stream is overhead. For a control living entirely inside a managed service with its own immutable long-retention trail, point at theirs and build nothing. With no assurance obligation yet, the useful first step is making controls emit structured records at all, so the window can later be extended by changing one setting.

Interview question

Q: Your first period-based assurance report opens in six weeks and will cover twelve months. Which stores would you change the retention on, which would you leave alone, and what would you build instead?

What a strong answer covers: that extending retention everywhere trades an audit problem for a minimisation one; which fields are the evidence for each in-scope control; where immutability and the delete permission sit; the arithmetic giving roughly 450 days; and that the first window may need shortening.

Quick check

Quiz: How long must control evidence be retained for an annual period opinion? — The window plus report issuance lag plus the next cycle, near 400 to 450 days, because the report is relied on after the window closes.

Flashcard: Why is extending application log retention the wrong way to satisfy a twelve-month audit? — It pays long retention on megabytes of payload to preserve hundreds of bytes of control events, and holds personal data past what minimisation allows.