Keeping Evidence Fresh: The Register That Survives Two Audits

Direct answer: Evidence is an artefact a control produced, with a date, and it goes stale. The structure that survives is a register where every artefact is attached to the controls it proves, has a named owner, and has a refresh date derived from the control's cadence. Collect once and map to every framework that asks, because the same access review record satisfies SOC 2, ISO 27001 and HIPAA at the same time if it is filed somewhere all three can reach.

What counts as evidence

The distinction that matters: a document describing a control is not evidence of the control. A policy saying access is reviewed quarterly evidences nothing. The completed review, dated, naming the reviewer and showing what changed, evidences the control.

Auditors sample. They pick a period, ask for the artefact that control produced during it, and check that it exists, is dated inside the period, and shows the control doing what the description claims. Everything else is context.

The shapes that get accepted are consistent across firms. Exports with timestamps and the person who ran them. Tickets showing a request, an approval and a completion. Signed or acknowledged records for policies and training. Reports from tools with the configuration visible. Screenshots are the weakest form and are accepted mainly where nothing else exists, because they can be taken at any time and show nothing about the period.

Why evidence goes stale

Every artefact has an implicit expiry driven by the cadence of the control it proves. A quarterly access review record covers a quarter. A penetration test report covers a year, and less than that if the environment changed materially. Training completion covers the cycle it was run in, and not the person who joined last month.

Teams get caught because the artefact still exists and looks fine. The file is there, it is titled correctly, and it is fourteen months old. Nothing about the folder tells you it has expired, which is why refresh dates belong on the record rather than in someone's memory.

Structuring the register

Five fields do almost all the work.

The artefact itself, stored somewhere durable rather than in an email thread or a Slack channel with retention limits.

What it evidences, as a list of controls across every framework in scope, not a single one. This is the field that saves the most time later.

Who owns it, by name, meaning who produces the next one.

When it was produced, from the artefact rather than the upload date, because those differ and auditors care about the first.

When it expires, derived from the control cadence, so the register can tell you what is going stale before somebody asks for it.

Collect once, count everywhere

Most companies running two frameworks collect the same evidence twice, in two places, because the two programmes were run by different people at different times. The overlap between SOC 2 and ISO 27001 is substantial, and the overlap between either and HIPAA or PCI DSS on the access, change and monitoring controls is real too.

A quarterly access review record can satisfy SOC 2 CC6.2, ISO 27001 A.5.18 and the HIPAA administrative safeguard on access review in one artefact. Producing it three times is pure waste, and it also produces three slightly different records, which is worse than waste when an auditor notices they disagree.

The mapping is the work. Once it exists, adding a framework becomes an exercise in identifying the genuinely new requirements rather than starting over.

What breaks a register

Evidence collected in a burst before fieldwork, which produces artefacts clustered in one month covering a twelve month period. Auditors notice this immediately and it invites a harder look at everything else.

Artefacts with no owner, which means nobody produces the next one. Free-text titles that differ per framework, which is how you end up with the same document filed twice under different names and a register that cannot tell you your real coverage. And storage that the person who leaves owned personally, which is the most common way evidence is lost outright.

The second audit is the test

The value of a well-kept register does not show in the first audit, where everything was collected recently for the project. It shows in the second, where the auditor asks for evidence covering a twelve month period and the answer is either a register that already holds it, or three weeks of reconstruction that will not fully succeed.

Teams that keep the register current spend fieldwork answering questions. Teams that do not spend it manufacturing a record, which is stressful, expensive, and produces exactly the kind of thin evidence that generates findings.

Our workspace holds the register with the mapping and refresh dates built in, and it is free to use whether or not you work with us. Keeping it current across a year is the part that needs a person, which is what an ongoing retainer covers.

Setting the cadence, and living with it

The refresh date on each row has to come from somewhere, and most people assume the framework states it. Usually it does not. SOC 2 describes an objective and leaves the frequency to you, ISO 27001 mostly says the same, and the intervals in your programme are almost always ones you chose. Once you write quarterly in a policy, an auditor tests you against quarterly, and three reviews in a twelve month period is a finding you created yourself.

Sensible defaults for a company of 20 to 100 people, chosen because they are achievable rather than impressive. User access reviews quarterly for production and administrative systems, annually for low-risk tools. Risk assessment annually, with a documented update when something material changes. Policy review annually with evidence of who approved it. Penetration test annually and after any significant architecture change. Vulnerability scanning monthly at minimum, with a written target for how fast criticals get closed. Backup restore test annually, with the restore time recorded. Vendor reviews annually for anything holding customer data. Incident response exercise annually. Security awareness training at hire and annually thereafter.

Write the interval you can sustain, not the one that sounds rigorous. Moving from quarterly to monthly access reviews quadruples the artefacts you must produce, and a programme that quietly fails its own cadence is worse off than one with a modest cadence it never misses.

Population before sample

The part of fieldwork that catches teams by surprise is not the sample, it is the population. Before an auditor picks five items to test, they ask for the complete list those five came from: all users with production access as of a date, all changes deployed during the period, all new hires, all terminations, all vendors onboarded. Then they test whether that list is complete, usually by tracing it back to the system that generated it and cross-checking against an independent source.

A population somebody typed into a spreadsheet by hand will not survive that test. If your list of terminations comes from memory and the auditor finds a payroll record for someone not on it, every conclusion drawn from that population collapses, and the retest costs more than getting it right did. Generate populations from the system of record and keep the export, with its timestamp and the account that ran it, alongside the sample evidence. This is the field most registers omit and the one that decides whether fieldwork is smooth.

The same logic applies to change management. An auditor asking for all production changes in the period is asking your deployment tooling, not your engineering manager, and if those two disagree the disagreement is the finding.

What automation genuinely covers

Compliance platforms are good at a specific slice: continuous configuration checks against cloud accounts, identity providers and endpoint tools. They will tell you MFA is off for a user, an S3 bucket is public, or a laptop is unencrypted, and they will hold that state with a timestamp. That is real value and it removes a category of manual screenshotting.

What they do not cover is the majority of what an auditor samples. The access review still needs a human to look at a list and make removal decisions. The risk assessment needs judgement. The vendor review needs somebody to read a subservice organisation's report and record what they concluded, including the complementary user entity controls that landed back on you. Training, policy approval, incident exercises and management review are all human outputs, and a platform showing green on those usually means somebody ticked a box inside it rather than that the control ran.

The false green is the failure mode to watch. A dashboard at 98 percent creates a feeling of coverage that stops people asking whether the underlying artefacts exist. Treat the platform as one source feeding the register, not as the register.

When you find a hole in the period

Every programme eventually discovers a quarter with no access review, a month with no scan, or a policy that lapsed. The instinct is to produce the missing artefact now and date it plausibly. Do not. Backdating is the one thing that turns a control exception into a question about the integrity of everything you handed over, and auditors are practised at spotting artefacts created in a burst.

The honest handling is straightforward and usually survives with less damage than people fear. Record what happened, when the gap started and ended, and what the exposure was. Run the control now and keep the real date on it. Write a short remediation note describing the cause and the change that prevents recurrence, such as a named owner where there was none, or a calendar entry with a reminder. Then raise it with the auditor before they find it, because a self-identified and remediated exception reads very differently from a discovered one.

You may still take a finding. A qualified opinion on one control with a documented remediation is something buyers accept. A report where the auditor stopped trusting the evidence is not.

When the owner leaves

The most common way a register decays is a departure rather than neglect. The person who ran the access reviews leaves, the reviews sit unassigned for two quarters, and nobody notices until fieldwork. Owners should be recorded as roles as well as names, so reassignment is an edit rather than an investigation, and the offboarding checklist for anyone owning controls should include their register rows. The same applies to storage: artefacts held in a departing engineer's personal Drive folder are the ones lost outright.

When you should not buy tooling or help for this

If you run one framework, have fewer than 30 people, and roughly a dozen recurring controls, a folder structure with a naming convention and a shared calendar will hold this together fine. Paying four or five figures a year for a platform to manage twelve rows is poor value, and the discipline problem it claims to solve is not one software fixes.

If your audit is a fortnight away and evidence is missing, buying a platform now makes things worse, because implementation competes for the same hours as collection. Collect what exists, be honest about what does not, and implement tooling after the report is issued.

Where a person genuinely helps is narrower. Running two or more frameworks and wanting the mapping built once. Facing your first Type II period, where twelve months of continuous evidence is a different discipline from a point-in-time assessment. Or carrying a register that has already drifted and needs somebody to reconstruct what is real before the next cycle. That maintenance across a year is what an ongoing retainer is for, and if you are mapping a second framework onto an existing programme, our ISO 27001 work starts from the evidence you already hold rather than from a blank register.