The work got done. Someone removed the contractor's access the day they left. Someone ran the quarterly access review and fixed the two accounts that should not have existed. The pull request was reviewed before it merged. Then the auditor asks for proof of each of those things, with a date on it, and nobody can find any.
If you run compliance on top of being the founder or the CTO, you may know how the rest of that week goes. You message engineers late at night for screenshots. You search Slack and old tickets for anything that shows a control was working months ago, and you find out that the one useful version of the evidence lives in somebody's head. Founders and first compliance hires describe the same week in public forums, often as the part of the audit they dread most.
In most cases the controls ran and left no record an auditor can use. That is a process problem, and a fairly cheap one to fix if you start before the audit period instead of during its last week.
Why proof gets lost
Most of the work behind SOC 2 controls happens inside the systems you already run. Access changes happen in your identity provider. Code review happens in GitHub. Offboarding happens across a dozen admin consoles in an afternoon. Each of those systems records something, but nobody thinks of the record as the deliverable. The person doing the work is thinking about the work.
Three habits make it worse.
First, nobody owns the evidence. A control has a policy and an implementation, and the person who implemented it assumes someone else is collecting the proof. When the request arrives, it lands on whoever is running the audit, who did not do the work and does not know where the trail is.
Second, evidence gets created after the fact. A screenshot taken in October of a setting that was configured in March proves the setting exists in October. If your report covers a period of time, the auditor needs to see that the control operated during that period, and a fresh screenshot cannot show that.
Third, the record is incomplete. An export with no date, a screenshot cropped so tightly that the system and account are gone, or a staging list filed under a production control all look like evidence until someone reviews them closely, and the auditor will.
What an auditor needs from a piece of evidence
It helps to know which kind of report you are getting. A SOC 2 Type 1 report covers your description of the system and whether your controls are suitably designed, as of a single date. A Type 2 report also tests whether they operated effectively across a review period. For a Type 2, the auditor usually asks first for complete lists of what happened during that period, such as everyone who joined, everyone who left and every change that shipped. They pick samples from those lists and ask you to show what happened for each one.
For each sample, a usable piece of evidence answers four questions without anyone having to explain it:
- When did this happen? A visible date, ideally a system timestamp, not a date typed into a file name later.
- Who did it, and who approved it if approval was required?
- Which system did it come from? The tool, the account or tenant, and the environment. An auditor who cannot tell production from staging will ask, and you will spend a day answering.
- Which control and which instance is this for? "Access removed for the person who left on the 14th" is evidence. "Offboarding screenshot" is a puzzle.
System exports and logs usually answer these better than screenshots, because the system writes the timestamp and the actor for you. When a screenshot is the only option, capture the whole window, including the URL bar, the account name and the system clock or a visible date on the page. Leave filters and search terms on screen so the reviewer can see what population they are looking at.
Ask your auditor early how they want evidence for the controls that have no obvious system of record. Firms differ, and a format question settled before the period starts costs nothing. The same question asked during fieldwork can mean redoing a quarter's worth of work.
Give every control one named owner
Ownership is the change that does the most. For each control, write down one person who is answerable for its evidence. Use a person's name; a team does not answer messages. The owner does not have to do the work every time, but they know when it is due, they know where the proof goes, and they are the one who notices when it did not happen.
At a company of 5 to 50 people, this list will repeat a few names. That is fine. The CTO might own change management, access control and the infrastructure controls. The person who runs people operations owns onboarding, offboarding and training. Whoever leads the audit owns policies and vendor reviews. The point is that a request for evidence goes to someone who already knows the answer.
Revisit ownership when people change roles or leave. A control owned by someone who left in the spring is unowned, and you usually discover that from the auditor.
Put every control on a cadence
Controls run on three rough rhythms, and each needs a different capture habit.
Event-driven controls run whenever something happens: a hire, a departure, a production change, an incident. These cannot be put on a calendar, so the record has to be part of the task. The last step on your offboarding checklist should be saving the evidence.
Periodic controls run on a schedule: quarterly access reviews, monthly vulnerability scan reviews, backup restore tests. Put each one on a shared calendar with the owner's name on it, and treat the evidence as part of the task. A quarterly access review is finished when the export, the reviewer's decisions and the date are filed. Revoking the accounts does not finish it.
Annual controls are the easiest to forget because a year is long enough for the owner to change: policy reviews, risk assessments, penetration tests, security awareness training, disaster recovery exercises. List them with a target month and an owner at the start of the year.
Keep a one-page table with control, owner, cadence and where the evidence lives, and review it once a month. It takes about as long as a standup.
Capture at the time of the work
The habit that ends most of the scramble is filing proof when the work happens, by the person who did it, while the context is still in their head. Some ways to make that the default rather than a favor:
- Add an evidence step to the ticket template for any task that maps to a control. The ticket does not close until the export or screenshot is attached.
- For access reviews, export the user list from the system on the day of the review. Record each keep or remove decision next to the user, with the reviewer's name and the date.
- For offboarding, record the departure date and the time each account was disabled. Most identity providers and admin consoles log this, so an export of that log beats a screenshot.
- For code review, your source control already records who approved what and when. Make sure branch protection requires review, and that you can export the history for any merged change the auditor picks.
- Name files the same way every time: control, system, environment, date. Something like
access-review_okta_prod_2026-07-01.
Track evidence status separately from control status. "The control is implemented" and "we have reviewed proof that it ran this quarter" are different facts, and a tracker that collapses them will show a sea of green right up to the first sample request. Statuses such as requested, received and reviewed make the gap visible while there is still time to close it.
Watch for evidence that has gone stale
Evidence ages. A policy approved two years ago, a pentest report older than the frequency your own policy promises, a training record from before your newest hires joined: each was valid once. Give every piece of evidence a review-by date when you file it, based on how often the underlying control runs, and look at what is coming due each month.
The date matters because of what stale evidence usually means. If the review was due in April and the next record is from August, the control did not run when it should have, and in a Type 2 that missed run is what the auditor can report as a deviation. Renewing the evidence in August does not fill in April. A monthly look at what is coming due is what lets you run the control on time.
Rehearse while the period is still running
For a Type 2, fieldwork often starts after the review period has ended, which is too late to change anything inside it. So rehearse during the period: once partway through, and again a few weeks before it ends. Pretend to be the auditor. Pull the full list of people who joined and left so far and pick a handful of each. Pick some production changes and an access review. Then try to produce the evidence for each one, using only what is filed, without asking anyone.
Every item you cannot produce in a few minutes points at an owner, a cadence or a capture step that is not working. You can fix it then, and the fix covers the rest of the period. The months before the fix stay as they were, which is why the first rehearsal should come early.
Where Keel fits
Keel is a compliance platform built around these habits. Each evidence item can have a named owner and a review-by date. Any item with a date shows as expiring once it is within 30 days of it. For evidence your team files, as opposed to evidence a connector collects, Keel also emails the owner, or the workspace owners and admins when nobody owns it. Controls can carry an owner and a review cadence, with a reminder when a review comes due. When you upload a file, Keel computes its SHA-256 hash on the server and records the time of upload. That timestamp says when the file reached Keel, which is one more reason to file it on the day the work happens.
For systems with an API, Keel has read-only evidence connectors. The Microsoft 365 connector is live and runs the open-source Maester test suite against Entra ID. Connectors for GitHub, AWS, Okta, Google Workspace and Microsoft Entra ID are in preview. They check settings such as two-factor requirements, administrator footprints and password policy.
When fieldwork starts, your auditor can work inside your workspace on a free auditor seat. They issue a request list for the frameworks and audit period in scope. Keel sorts each in-scope control by what you already hold: evidenced already, needs fresher evidence, needs a request, or not applicable. It opens requests only for the two in the middle. A request can state what the evidence must show and the dates it must cover, and Keel flags evidence collected outside those dates. Your team submits; only the auditor can accept a request or return it to your team.