Audit Evidence Requests: A Playbook for Handling Your Auditor's Request List

Short answer: Audit evidence requests are the itemized asks on your auditor's request list (often called a PBC list, for "provided by client"). To handle them well, give every request one owner and a due date, send complete system-generated populations before samples, keep evidence dated and redacted, answer follow-ups quickly and store everything so next year's audit starts from a template.

Related guides:

• Evidence collection: building an evidence library
• How to prepare for a SOC 2 audit
• Audit management software: PBC lists, findings and multi-framework audit cycles

Key takeaways

• The request list is the working contract of your audit. Treat it as a tracked project with owners, due dates and statuses, not as an email thread.
• Most requests fall into a handful of buckets: policies, system and scope information, populations, samples, configurations and walkthroughs.
• For sample-based testing, the auditor usually asks for a full population first and then picks the sample. A wrong or incomplete population is a common reason for requests to come back with follow-up questions.
• Good evidence is dated, system-generated where possible, complete and scoped. Redact PHI and personal data you do not need to send.
• Respond to follow-ups fast and explain exceptions honestly. Next year, reuse the same request structure so the second audit is mostly a refresh.

What is a PBC list, and what does an auditor request list contain?

A PBC list is the auditor's itemized list of evidence they need you to provide, and it drives almost every day of fieldwork.

Different firms call it different things: PBC list, auditor request list, information request list, or simply "the request tracker." Whatever the name, each line usually includes:

Field	What it tells you
Request ID	A reference you will quote in every reply and file name
Control or topic	Which control, criterion or process the request supports
Description	What the auditor wants, sometimes in very short shorthand
Period or date	The point in time or review window the evidence must cover
Type	Document, population, sample, screenshot, walkthrough or inquiry
Due date	When the auditor expects it, often grouped into waves
Status	Open, submitted, follow-up, accepted

For a SOC 2 evidence request list, the items map to the controls described in your system description. For an ISO 27001 certification audit, they map to your management system documents and the controls you selected for your ISMS. For a HIPAA assessment, they usually follow your risk analysis and your administrative, physical and technical safeguards.

What do auditors typically ask for?

Auditors typically ask for six kinds of evidence, and knowing which kind a request is tells you how to answer it.

1. Policies and procedures. Approved versions with an owner, version number and approval date. Expect requests for evidence that they were reviewed and communicated.
2. Scope and system information. Network or data flow diagrams, an asset or system inventory, a list of subservice organizations and your org chart.
3. Populations. Complete lists of events during the review period, such as new hires, terminations, production changes, access grants, incidents or vendor onboardings.
4. Samples. Supporting records for the specific items the auditor picked from a population, such as the ticket, approval and completion proof for one change.
5. Configurations and settings. System-generated exports or screenshots that show how a control is set, such as MFA enforcement, encryption at rest, logging or backup schedules.
6. Walkthroughs and inquiry. Live sessions where a control owner shows the auditor how a process runs. These still generate follow-up requests, so take notes.

When a request is ambiguous, ask which of these six it is before you start pulling files. "Provide evidence of access reviews" could mean the policy, the population of reviews performed, or the full record of one sampled review.

How do population and sample requests work?

For many operating controls, the auditor asks you for a complete list of every instance in the period (the population), selects a subset (the sample) and then asks you for detailed evidence on those items.

The auditor decides the sample size and selection method using their own professional judgment and firm methodology. Sample sizes vary by firm, control frequency and risk, so we do not quote them here. Your job is to make the population trustworthy.

What a good population looks like:

• Complete. It covers the entire review period, start date to end date, with no gaps.
• System-generated. Exported directly from the source system (HR platform, ticketing tool, identity provider, cloud console), not retyped into a spreadsheet.
• Reproducible. You can explain how it was pulled: the system, the filter or query, who ran it and when. Auditors often test that a population is complete and accurate before they rely on it, so it helps to include a screenshot of the query or report parameters.
• Unfiltered by you. Do not remove items you think are "not relevant." If something should be out of scope, flag it with a reason and let the auditor decide.
• Consistent with other lists. Terminations in the HR export should line up with deprovisioned accounts in your identity provider. Mismatches become questions.

When the sample comes back: pull the full trail for each selected item. For a sampled change, that might be the ticket, the peer review or approval, the test result and the deployment record, each with timestamps showing the right order. For access controls, each sampled review should show the reviewer, the decision on each account and the completed removals, as described in our guide to quarterly access reviews.

Who should own each request, and how fast should you respond?

Every request needs one named owner who can actually produce the evidence, plus one audit coordinator who tracks the whole list.

We suggest setting up the following roles before fieldwork starts:

Role	Responsibility
Audit coordinator	Owns the tracker, triages new requests within a day, checks quality before submission and chases owners
Control owners	Produce evidence for their area (engineering, IT, HR, security, legal)
Executive sponsor	Unblocks owners and approves responses to exceptions
Auditor contact	Clarifies ambiguous requests and confirms when items are accepted

Practical turnaround rules we recommend:

• Agree on a response target with your auditor at kickoff, and on how requests will be delivered (portal, shared folder or tracker). One channel only.
• Acknowledge each new request quickly, even if the evidence will take longer, so the auditor can plan around it.
• Batch submissions by request ID rather than sending files one at a time.
• If something will be late, say so before the due date and give a new date.

What makes evidence acceptable the first time?

Evidence is accepted the first time when it is dated, sourced, complete, scoped to the request and stripped of data the auditor does not need.

Use this checklist before you mark any item as submitted:

• Dated. The timestamp, report date or system clock is visible. Screenshots should show the date and, where possible, the URL or system name.
• System-generated where possible. Exports and native reports beat manually built spreadsheets. If a manual list is unavoidable, say how it was built.
• Inside the review period. Evidence for an audit that covers a review period must come from that period, not from today.
• Complete. Populations cover the whole window. Multi-page records include every page.
• Labeled. File names start with the request ID, for example REQ-042_change-ticket_2026-03-14.pdf.
• Redacted. Remove PHI, customer data, secrets and personal data the auditor does not need.

On redaction for HealthTech teams: the HIPAA Privacy Rule's minimum necessary standard generally requires covered entities, and business associates under their agreements, to take reasonable steps to limit uses, disclosures and requests of protected health information to the minimum necessary for the purpose. Whether the standard applies to a given audit disclosure depends on the circumstances, but the same principle is good practice for all audit evidence: most controls can be tested without patient names or record contents. Replace identifiers with a record ID, crop screenshots to the setting being tested and never paste credentials or API keys into evidence. If the auditor genuinely needs to see sensitive data, use a screen share walkthrough rather than sending copies.

How should you handle follow-ups and exceptions?

Answer follow-ups quickly and specifically, and when a control did not operate as designed, explain it with facts instead of trying to bury it.

Follow-ups are normal. Typical reasons include a missing date, a population that does not reconcile with another list, a sample missing one step, or evidence that shows the control but not who performed it. Reply in the same thread as the original request ID, state exactly what you are adding and update the tracker.

When a sample shows a real gap, such as a terminated employee whose access was removed late or a change deployed without recorded approval:

1. Confirm the facts with the control owner before responding.
2. Explain the cause in plain language: what happened, why and how it was found.
3. Show compensating evidence if it exists, such as logs showing the account was not used after the termination date.
4. Describe remediation, both the fix for that item and any process change.
5. Let the auditor decide how it is reported. Do not pressure them to drop it.

Our guide to SOC 2 exceptions covers how exceptions appear in a report and how buyers tend to read them. A clearly explained exception with a credible remediation plan is usually much easier to discuss with customers than a pattern of missing evidence.

How do you reuse this year's evidence next year?

Turn this year's request list into next year's evidence calendar, so the second audit becomes a refresh rather than a rebuild.

Once the report or certificate is issued:

• Archive the final tracker with every request, the accepted evidence and the auditor's comments.
• Map recurring requests to controls, not to people, so the list survives staff changes. Our guide to SOC 2 evidence collection covers what to keep for each control.
• Build saved queries for every population you exported, so next year you rerun them instead of rebuilding them.
• Schedule periodic evidence, such as access reviews, backup restore tests and policy reviews, on a calendar so it exists before the auditor asks.
• Keep records long enough. If you handle ePHI, HIPAA's Security Rule requires documentation of required policies, procedures and actions to be retained for six years from creation or the date it was last in effect, whichever is later (45 CFR 164.316(b)(2)). Align your evidence retention with that where it applies.

If you run SOC 2, ISO 27001 and HIPAA together, tag each piece of evidence with every control it supports. One access review export can often answer requests in all three audits, which is where most of the time savings come from. Remember that reused evidence still has to fall inside each audit's own review period.

How SecureSlate helps

SecureSlate gives you one place to run the auditor request list instead of a tangle of spreadsheets and email threads.

• Audit management to track every request with an owner, due date, status and attached evidence.
• Multi-framework control mapping across SOC 2, ISO 27001, HIPAA, HITRUST and more, so one piece of evidence can support several audits.
• Agentless, read-only cloud integrations and a device agent that help produce system-generated configuration evidence.
• Access reviews with recorded reviewer decisions, a frequent source of sample requests.
• Vendor risk management, risk management and custom frameworks and controls for the rest of a typical list.

Start your free SecureSlate trial

FAQ

What does PBC stand for in an audit?

PBC stands for "provided by client" (sometimes "prepared by client"). A PBC list is the auditor's itemized list of documents, populations, samples and other evidence the audited organization needs to supply during the engagement.

What is the difference between a population and a sample request?

A population request asks for a complete list of every occurrence of an event during the review period, such as all new hires. A sample request asks for detailed supporting evidence for specific items the auditor selected from that population.

Should we send PHI or customer data to our auditor?

Usually not. Redact or replace identifiers with record IDs and crop screenshots to the control being tested. If an auditor needs to see sensitive data to test a control, a live walkthrough is generally safer than sending copies.

How long should we keep audit evidence?

Keep it at least until the next audit cycle so you can reuse its structure, and longer where a regulation requires it. HIPAA, for example, requires covered entities and business associates to keep required Security Rule documentation, such as policies, procedures and documented actions, for six years; it does not set retention for medical records, which state law governs. Check your auditor's and customers' contractual requirements too.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.