Building an evidence library that does not go stale

Evidence has a shelf life and nobody prints it on the tin

A screenshot of your Microsoft 365 admin centre showing multi-factor authentication enforced on every account is a true statement about the afternoon of 14 May 2026. It is not a statement about June, and it is definitely not a statement about the two people who joined in July. The screenshot does not know that. Filed in a folder called “MFA evidence”, it will sit there looking authoritative for as long as everyone leaves it alone.

That is the central difficulty with an evidence library. Artefacts do not decay visibly. An out-of-date policy PDF looks identical to a current one until somebody reads the version history. A penetration test report from two platform migrations ago has the same file icon as one from last month. The library gets larger every year and less trustworthy at the same time, and the person who eventually notices is usually an assessor, in a meeting, with your certificate at stake.

Four ways evidence rots

Nobody owns it. Evidence gets collected by whoever happened to be free during the last audit. Six months later that person has changed role or left, and the artefact belongs to no one. Ownerless evidence is never refreshed, because refreshing it is not on anybody’s list.

It has no expiry. A DBS check, a penetration test, an insurance certificate, a supplier’s ISO 27001 certificate and a backup restore test all have natural lifetimes of between one month and three years. If the record does not carry a date at which it stops counting, the only mechanism for noticing is memory.

It captured a moment rather than a state. Most screenshots prove that a setting was correct once. Controls that depend on population coverage, such as MFA enrolment, device encryption or patch currency, change every time somebody joins, leaves or buys a laptop. A point-in-time capture of a moving number ages badly and fast.

It was gathered for an audit rather than for a control. This is the expensive one. When evidence exists to satisfy an assessor, the collection effort peaks in the fortnight before the assessment and drops to zero afterwards. When evidence is a by-product of running the control, it stays current because the control is running. The two libraries look similar in a folder listing and behave completely differently over time.

What an evidence record actually needs

A file is not an evidence record. A record is the file plus the context that makes it assessable, and that context is small enough to fit in a spreadsheet with seven columns:

• What control or controls it satisfies. Written as a reference, not a description: Cyber Essentials A6.2, ISO 27001 Annex A 8.5, and so on. One artefact often satisfies several, which is the point of recording it properly.
• Who owns it. A named person, not a team or a job title. “IT” has never once refreshed a piece of evidence.
• When it was captured. The date the artefact reflects, which is not necessarily the date the file was uploaded.
• When it expires. Either a hard date (a certificate) or a review interval (a quarterly access review). Anything with no expiry should be justified, not assumed.
• How it was obtained. The exact console, report or query, in enough detail that a different person could repeat it. “Exported from Entra ID, Users, Per-user MFA view” beats “from the admin portal”.
• Whether it is reproducible. If someone can regenerate it on demand, the artefact is a cache and its staleness is cheap to fix. If it cannot be regenerated, such as a photograph of a server room or an approval email, it needs a stricter review cycle.
• Its integrity. A checksum recorded on upload lets you demonstrate later that the file is the one you filed, rather than asking the assessor to take that on trust.

Screenshots and queryable sources are not the same evidence

A screenshot answers “was this true?”. A query answers “is this true?”. Both are legitimate, but they carry different maintenance costs and you should know which one you are holding.

Queryable sources are things like a directory export of accounts and their MFA status, a device management report of encryption and patch levels, a repository’s branch protection settings pulled through an API, a list of users with administrative roles. They can be re-run in seconds, so drift is detectable and the cost of currency is close to zero. Where a control has a queryable source, screenshotting it is a step backwards.

Screenshots and documents are the right answer where no query exists: board minutes approving a policy, a signed supplier contract, a training completion certificate from a system you cannot export from, physical security arrangements. Accept these, but give them shorter review intervals and a named owner, because nothing else will catch them going out of date.

One artefact, several frameworks

If you are working towards Cyber Essentials and expect ISO 27001 or the Defence Cyber Certification later, map evidence to controls rather than to audits. An asset inventory supports the Cyber Essentials scope declaration, several ISO 27001 Annex A controls and the asset management expectations in DCC Level 2. Filed as “CE 2026 evidence pack, item 4”, it will be collected again from scratch next year for a different scheme. Filed against controls, it is reused, and the second framework costs a fraction of the first.

The practical test: could you produce, in one minute, every artefact that touches your joiners and leavers process, regardless of which standard asked for it? If the answer requires opening three folders named after audits, the library is organised around the wrong thing.

A review cadence you will actually keep

Annual review of everything is a fiction. Nobody reviews four hundred artefacts in one sitting with any care. Split the library instead:

• Monthly: coverage figures that move with headcount. MFA enrolment, device compliance, leaver account closure, privileged role membership. These are cheap if the source is queryable and misleading if it is not.
• Quarterly: access reviews, third-party access, backup restore evidence, any artefact whose owner has changed.
• Annually: policies, contracts, insurance, penetration tests, the scope statement itself.
• On event: a new system, an office move, an acquisition or a significant incident invalidates evidence immediately. Add a step to your change process that asks which records this breaks.

Put the next review date in the record, sort the library by that column, and work the top of the list. That single column is the difference between a library that is maintained and one that is periodically rebuilt in a panic.

Where a platform earns its place

All of this works in a spreadsheet and a well-named folder tree, and if that is where you are, the structure above is worth adopting today. The work a tool removes is the repetitive part: pulling the same queries every month, noticing the expiry dates before somebody else does, and keeping the control mapping intact when a framework is added. Apexward Assure runs continuous checks against the tools you already have connected, such as Microsoft 365, GitHub, GitLab and Xero, checksums each artefact on upload, maps it to the controls it satisfies and tracks the expiry for you. Auditors get a scoped role that can read the library and ask questions without being able to change it. The platform is free, so if you want to see what your evidence looks like when it is mapped rather than filed, the compliance module costs nothing to try.