Picture the week before the audit window opens. You are the operations director, and the assessor has sent over a request list: 20-odd items, each asking you to produce records for a period that already happened. Access reviews. Offboarding records. Change approvals. Evidence that the backup restored cleanly, not that it was scheduled to.
So you do what most teams do. You open the shared drive. You ping the person who handled the contractor offboarding in February and ask if they wrote anything down. You build a folder, name it something hopeful like "SOC 2 evidence final," and start filling it with screenshots taken this morning of settings you are pretty sure were the same back in February.
Here is the quiet problem with that folder. The assessor is not grading how hard you worked the week before. They are checking whether the control operated across the whole period, on the days nobody was watching. A screenshot taken today says nothing about February. The week-before scramble produces a binder that looks like evidence and proves almost nothing. What auditors want is the opposite of a binder: a record that was already being kept.
They are testing the period, not the deadline
A SOC 2 Type II report covers a window of time, often six or 12 months, and the assessor's job is to test whether your controls operated consistently across that window. The American Institute of Certified Public Accountants, which maintains the SOC framework, describes a Type II report as covering the operating effectiveness of controls over a stated period, not a single point in time (see the AICPA SOC 2 overview).
That single fact reframes everything. A control that was "turned on" the day before testing is a control with no operating history. The assessor will ask for evidence spread across the period: a sample of access changes from different months, approvals tied to the requests that prompted them, reviews that carry a date and a name. They are not impressed by volume. They are looking for continuity.
What "good evidence" looks like to a reviewer
A reviewer who has never seen your environment is reading for three things, and none of them is polish:
- A timestamp that lands inside the audit period, not the week of the request.
- An actor, so the record shows who did the thing, not just that it happened.
- A link between the change and the reason for it, so an access grant points back to the request that authorized it.
A screenshot fails on at least two of those. It has no actor, and its timestamp is the day you took it. A clean record passes on all three because the record was written when the work happened, by the person or system that did the work. That is the whole distinction. Evidence is not a document you produce; it is a trace the work leaves behind.
Evidence is a byproduct, or it is fiction
This is the part worth sitting with. If you have to assemble evidence, you do not have evidence. You have a reconstruction, and a reconstruction is only as good as the memory of the people you can still reach.
We run environments; we do not write reports about them, and the pattern we see holds every time: the teams that sail through a SOC 2 review are not the ones with the thickest binders. They are the ones who never built a binder, because the operation recorded itself. When an access change flows through a request that someone approved, the approval, the actor, and the timestamp are already attached. When a policy is owned by a named person who reviews it on a schedule, the review history is already there. The proof falls out of running the environment properly.
SOC 2 is paperwork with consequences. The consequence of running the environment well is that the paperwork is already written.
That is also where the scramble hurts most. The week you spend rebuilding February is a week you are not running anything. Compliance done as an annual event taxes the operation twice: once when you scramble, and again on every ordinary day you spent not keeping the record that would have made the scramble unnecessary.
Where this approach does not fit
Honesty matters more than a clean pitch, so two limits are worth naming. A record that flows through your operation cannot capture a change someone made directly inside a vendor console without going through any process; that change leaves no trace in your records, and no tool invents one after the fact. And if your team genuinely prefers to run the scramble once a year and accept the risk, a records-as-you-go habit is overhead you will resent. The approach pays off only when you treat compliance as a daily operating posture, not a deadline you sprint toward.
The audit is just your ordinary months, written down
Walk back to that request list. The version where you assemble a folder costs you a week and produces evidence that proves the week, not the period. The version where the work recorded itself looks different: you filter to the audit window, read down a record that was kept as you went, and hand over what was already there. The contractor offboarded in February is a logged action with a name and a date, not a memory you are coaxing out of a colleague.
For the operational side of this, the portal's policies and procedures and organization activity log articles show how the record gets kept day to day. The point underneath both is the same one auditors keep trying to tell us: they do not want to see how hard you tried before the deadline. They want to see what was true the whole time.
So before the next request list lands, ask yourself one thing. If the assessor picked a random Tuesday from four months ago, could your environment show what happened on it, or would you be reconstructing it from memory?