An external audit generates dozens to hundreds of evidence requests, each with an owner somewhere in the organization, a due date, and a chance of being rejected and re-requested. Auditors often call this the PBC list, for provided by client. When requests are managed through email threads and shared folders, the same questions get answered twice, deadlines slip quietly, and nobody can say how close the audit is to done. This template gives you a starting structure for tracking requests, owners, due dates, and status. Here is how to run it well.
Columns worth tracking
A status workflow that shows real progress
- Not started: request received and assigned but no work yet.
- In progress: owner is collecting the evidence.
- Internal review: someone other than the owner checks completeness, period, and sensitivity before release.
- Submitted: provided to the auditor, with the submission date recorded.
- Follow-up requested: auditor needs more or different evidence; the clock restarts.
- Accepted: auditor confirms the request is satisfied.
The internal review step is the one teams skip under deadline pressure, and it is the one that prevents the most rework. It also stops over-sharing: screenshots and exports frequently contain customer data or secrets that the auditor does not need.
Populations and samples
For controls that operate repeatedly, such as onboarding, offboarding, change approvals, or access reviews, auditors typically request a complete population for the period and then select a sample to test. Track the population request and each sample item as separate lines. Auditors will also assess the completeness and accuracy of any report you generate, sometimes called information produced by the entity, so record how each population was extracted: the system, the query or filter used, who ran it, and when.
What makes evidence acceptable
SOC 2 versus ISO 27001 evidence patterns
A SOC 2 Type I tests control design at a point in time, while a Type II tests operating effectiveness over a period, so Type II requests lean heavily on populations and samples across months. ISO 27001 certification audits sample evidence too, but also examine management system clauses such as internal audit, management review, and corrective action. The underlying evidence often overlaps: the same access review can support SOC 2 CC6.2 and ISO 27001 Annex A 5.18. Tagging each tracker row with every control it satisfies turns next year's audit, or a second framework, into a reuse exercise. The evidence reuse article and ISO 27001 vs SOC 2 comparison go further.
Mistakes that stall audits
- Assigning requests to shared inboxes, so nobody feels accountable.
- Sending evidence from outside the audit period and waiting a week to learn it was rejected.
- Renaming or merging auditor request IDs, which breaks traceability.
- Providing policies when the request asks for proof of operation.
- Collecting evidence only at audit time, when gaps in the period can no longer be fixed.
- Losing track of follow-ups because they live in email instead of the tracker.
Before fieldwork starts
- Kickoff call held to agree request format, delivery channel, and deadlines
- Every request has a named owner and an internal due date
- Naming convention and folder structure agreed
- Sensitive data handling rules agreed with the auditor
- Populations for recurring controls extracted and reconciled
- Daily or twice-weekly status check scheduled during fieldwork
A spreadsheet tracker is a solid start. Teams that go through audits repeatedly often move to a workflow where evidence is collected continuously from integrated systems and requests are handled in a shared auditor workspace; Asurvo's Audit product covers requests, evidence, findings, and remediation in that way. The audit remediation use case covers what happens after findings land.