How do you build an audit evidence repository?

What this page is, and what it is not

Audience: a compliance lead or engineering manager assembling evidence for a first audit, or replacing the shared folder that grew organically and now nobody can navigate.

This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file with an auditor. No standard on this page prescribes a folder structure, so nothing here is a requirement — it is a structure that survives an audit, offered as a starting point to adapt. Last verified 10 September 2026.

The organising insight is that auditors do not request evidence by source, they request it by control. A repository arranged by tool — one folder per platform — forces a translation step on every request, and that translation is where the delay and the missing artifacts show up. Arranged by control, a request maps to a location, and a gap is visible as an empty location rather than discovered in a meeting.

• The index is more valuable than the files. A complete control-to-evidence index with some artifacts missing beats a full folder nobody can navigate.
• Capture date and coverage period are different, and both belong in the name. A screenshot taken in September showing a January setting is a different artifact from one covering January to September.
• Evidence goes stale. Without a freshness date per artifact, last year's screenshots quietly become this year's submission.
• Restrict access. An evidence repository is a concentrated map of your security posture, your configurations, and often your people.

Reference repository structure

A working layout. Adapt the names to your frameworks; the shape is what matters — control-first, with period folders underneath, and the index and policies held separately. No standard requires this. Last verified 10 September 2026. Not legal advice.

Control-to-evidence index example

This is the index in miniature. One row per control, with the evidence that supports it, its source, who owns it, how often it needs refreshing, and where it lives. The control identifiers below are illustrative and drawn from published criteria; substitute your own framework and version. Last verified 10 September 2026. Not legal advice.

Self-built repository or a compliance platform

Both work. The choice is about where you want the maintenance burden, not about which is more legitimate. Stated criteria first, so this is a comparison rather than a recommendation: cost of setup, cost of ongoing maintenance, evidence freshness, auditability of the repository itself, portability, and what happens to your evidence if you stop paying. No vendors are named or ranked. Last verified 10 September 2026. Not legal advice.

Repository hygiene

The practices that keep a repository useful in its second year. These are ShipReady Metrics recommendations and common industry best practice, not requirements from any standard on this page.

• One artifact, one authoritative location. Cross-reference from the index instead of copying a file into three control folders.
• Put the coverage period and the capture date in every filename, so an auditor can judge relevance without opening anything.
• Never edit a filed artifact. Supersede it with a new version and keep the old one, because a screenshot edited after filing is worth nothing.
• Redact at capture, not later. Export access lists without unnecessary personal data, and crop screenshots before filing rather than after somebody notices.
• Restrict access to the repository and log it. It is a concentrated description of your posture and your people.
• Track a freshness date and a refresh cadence per artifact, and generate a staleness list before every cycle.
• Record who owns each row of the index by name. Unowned rows are the ones that go stale.
• Freeze closed periods into an archive so prior-period evidence cannot be altered.
• Keep the auditor's request log. Next cycle's list is largely this cycle's, and the log turns a scramble into a checklist.
• Record gaps explicitly in the index rather than leaving locations silently empty. A known gap with an owner is a manageable position; a surprise gap during fieldwork is not.

Which kind of authority this structure carries

Almost nothing on this page is a requirement, and it is worth being explicit about that. Last verified 10 September 2026.

Checklist

A question list for repository hygiene. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.

• Is there a control-to-evidence index that lists every in-scope control, its evidence, its source, and its owner by name?
• Is the repository organised so that an auditor request maps to one location, rather than requiring translation from tool to control?
• Does every filename carry the coverage period and the capture date?
• Is there exactly one authoritative copy of each artifact, referenced rather than duplicated?
• Are complete period populations stored once, separately from the samples drawn from them?
• Does each index row carry a freshness date and a refresh cadence, and can we generate a staleness list on demand?
• Are known gaps recorded in the index with an owner, rather than showing as silently empty locations?
• Is access to the repository restricted and logged?
• Is personal data minimised and redaction applied at capture rather than after filing?
• Are filed artifacts immutable, with supersession instead of editing?
• Are closed periods frozen in an archive?
• Do we keep the auditor request log from the last cycle?
• Do third-party reports have their own expiry tracking, so an attestation does not lapse unnoticed?

What to do now

Ordered so the highest-value artifact comes first. None of these steps determines YOUR obligations or files anything with an auditor.

• Write the index before you move a single file. One row per in-scope control, with evidence, source, owner, cadence, and location — gaps included.
• Create the control-first tree and move existing evidence into it, renaming as you go with coverage period and capture date.
• Export the current period's populations once, into the shared populations location, so every control samples from the same authoritative export.
• Assign an owner by name to every index row. Rows without owners are the rows that go stale.
• Add freshness dates and cadences, then run the staleness list immediately — the first run usually finds year-old screenshots being treated as current.
• Lock down access and turn on access logging, then check who currently has it.
• Freeze last period into the archive so it cannot be edited.
• Recover the last auditor request list into the request log; it is the cheapest preparation available for the next cycle.
• Re-verify the cited criteria annually against the primary sources below and record the date. Ours says 10 September 2026.

Where this shows up in ShipReady Metrics

Only shipped behaviour is described here. This product is not your evidence repository of record. It does not store your files, does not produce a downloadable evidence binder, does not compile a regulator filing pack, and does not issue an auditor's opinion.

If you already have a session: signed-in app → Compliance holds evidence collection, which assembles control-mapped artifacts for starter control subsets from connected sources, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. That timestamped record is a compliance artifact and a useful index-like view of what has been accepted — it is not a forensic chain of custody, and it does not replace the repository holding the underlying exports and reports.

The obligation map lists frameworks your organisation marked in-scope, which is what makes the control set concrete enough to index against. That mark is your organisation's statement, not a legal opinion that a framework applies. Policies live under signed-in app → Compliance → Policies.

ShipReady Passport is a feature-flagged shareable snapshot report. Treat it as a flagged shareable report, not as your audit evidence repository — it does not hold your artifacts and it is not a substitute for the structure on this page.

Primary sources (last verified 10 September 2026)

Each source is labelled by the kind of authority it carries.

ISO/IEC 27001:2022 Clause 7.5 documented information and Clauses 9.2 and 9.3 are certification requirements. AICPA Trust Services Criteria are professional attestation criteria. NIST SP 800-53 Rev. 5 is guidance generally and binding only where a baseline is imposed. Regulation (EU) 2016/679 (GDPR) accountability duties are a legal requirement where the Regulation applies to your processing, and they reach the repository itself where it holds personal data. Not a complete list, and not legal advice.

The retention checklist page in this cluster covers how long each artifact needs to survive, the continuous-collection page covers keeping it fresh, and the prove-a-control page covers what makes the contents sufficient rather than merely present.

Frequently asked questions