Audits overrun less because controls fail than because evidence requests sit in inboxes with no owner, no due date and no record of what was sent. A shared spreadsheet that the auditor, the GRC team and twenty control owners all edit is not a tracker; it is a source of duplicate uploads, missed deadlines and personal data sent to the wrong place. This template gives [Organisation] a ready-to-use procedure and tracker for audit evidence requests, also called provided by client (PBC) lists: the columns, the status workflow, the turnaround targets and escalation, a library of common security and identity requests with where the evidence comes from, and rules for handling what is shared. It is for GRC and compliance teams, internal audit liaisons and control owners preparing for SOC 2, ISO/IEC 27001, SOX IT general controls or regulator reviews. For what makes evidence good enough in the first place, see the Audit Evidence and Continuous Controls Monitoring Guide.
How to use this template
- Run one tracker per audit engagement, owned by a named audit coordinator in [GRC team]. Import the auditor's PBC list into it on day one; do not work from the auditor's file directly.
- Replace the bracketed values: [Organisation], turnaround targets, escalation contacts, the evidence repository and retention period. Targets shown are NHI Mgmt Group recommendations, to be agreed with the auditor at planning.
- Hold the tracker in a system with access control and history (a GRC platform, ticketing tool or a restricted workbook with version history). Each control owner sees and edits only their rows.
- Reuse the request library in section 6 to prepare evidence before the PBC list arrives. Most requests repeat each year.
1. Purpose and scope
1.1 This procedure governs how [Organisation] receives, assigns, prepares, reviews, submits and records evidence requested by external auditors, internal audit, certification bodies, customers performing due diligence and regulators.
1.2 It applies to every request, whether it arrives as a PBC list, an email, a portal task or a question in a meeting. Requests made verbally are logged by the coordinator before work starts.
1.3 Regulator requests also follow [Organisation]'s regulatory engagement procedure and require [Legal] review before submission.
2. Roles
| Role | Responsibility |
|---|---|
| Audit coordinator | Owns the tracker, logs and assigns requests, chases owners, is the single channel to the auditor, runs the weekly status meeting |
| Control owner | Prepares evidence for assigned requests by the internal due date; explains how it was produced |
| Evidence reviewer | Second person in [GRC team] who checks each submission against section 5 before it is sent |
| Data owner or privacy lead | Approves any submission containing personal data or confidential customer information |
| Escalation sponsor | [CISO or CIO], who resolves blocked or overdue requests |
| Auditor | Raises requests and queries through the agreed channel only; selects samples from populations [Organisation] provides |
3. Tracker columns
3.1 Every request is one row. Split compound requests ("all access review evidence") into one row per control and period before assigning.
| # | Column | Content and example |
|---|---|---|
| 1 | Request ID | Auditor's reference plus internal ID: PBC-024 / AER-2026-024 |
| 2 | Request text | Exact wording from the auditor, unedited |
| 3 | Control reference | Internal control ID and framework reference, for example AC-07 mapped to the relevant SOC 2 criterion or ISO/IEC 27001 Annex A control |
| 4 | Request type | Population, sample evidence, policy or procedure, configuration, walkthrough, inquiry follow-up |
| 5 | Period covered | [1 Jan to 31 Dec 2026] or point in time |
| 6 | System or scope | Identity provider, production cloud account, HR system |
| 7 | Control owner | Named person, not a team |
| 8 | Evidence reviewer | Named person, not the control owner |
| 9 | Date received | Date the auditor raised it |
| 10 | Internal due date | Auditor due date minus the review buffer in section 4 |
| 11 | Auditor due date | Agreed date |
| 12 | Status | From the workflow in section 4 |
| 13 | Population source | System, query or report name, parameters, run date and run by |
| 14 | Completeness check | How the population was reconciled to the source (record counts, control totals) |
| 15 | Samples selected | Sample IDs chosen by the auditor and the date selected |
| 16 | Evidence location | Link to the folder in the evidence repository, never an attachment |
| 17 | Data classification | Public, internal, confidential, personal data; approver if confidential or personal |
| 18 | Queries | Count and link to the query thread |
| 19 | Submitted date and accepted date | For measuring turnaround |
| 20 | Exception or finding | Whether the evidence revealed a deviation, with link to the issue log |
4. Status workflow and turnaround
4.1 Each row moves through these statuses only. The coordinator updates status; owners propose changes through comments.
| Status | Meaning | Target time in status (our recommendation) |
|---|---|---|
| Logged | Received, not yet split or assigned | [1] working day |
| Assigned | Owner and reviewer named, owner has acknowledged | [2] working days to acknowledge |
| In preparation | Owner gathering evidence | Up to internal due date |
| In review | Reviewer checking against section 5 | [2] working days |
| Submitted | Sent to auditor through the agreed channel | Auditor's response time |
| Queried | Auditor has asked a follow-up; returns to In preparation | [3] working days to answer |
| Accepted | Auditor confirms the request is satisfied | Closed |
| Blocked | Cannot proceed (system access, missing data, disagreement on scope) | Escalate within [1] working day |
4.2 Set the internal due date at least [3] working days before the auditor's date so review can happen. Rows overdue by [2] working days go to the owner's manager; by [5] working days, to the escalation sponsor.
4.3 Hold a weekly status meeting during fieldwork with the auditor, reviewing overdue, blocked and queried rows only.
5. Evidence preparation and review rules
5.1 Populations must be complete and traceable. Record the system, the query or report and its parameters, when it was run and by whom, and how the count was reconciled to the source. PCAOB AS 1105 requires auditors to test the accuracy and completeness of information the company produces, or the controls over it, so evidence without this lineage will be queried.
5.2 Prefer system-generated records over screenshots, and originals over copies or conversions. AS 1105 treats evidence obtained directly, from independent sources and in original form as generally more reliable. Where a screenshot is unavoidable, show the system clock, the user and the filter applied.
5.3 Expect the auditor to examine documents, interview people and test mechanisms. These are the three assessment methods in NIST SP 800-53A Rev. 5, and requests usually map to one of them; prepare the walkthrough or test environment as well as the documents.
5.4 Name each file with the request ID and, where applicable, the sample ID: PBC-024_S07_ticket-48211.pdf.
5.5 Supply only what was asked. Over-supplying widens scope and may expose personal data. Redact personal data not needed for the test, with the privacy lead's approval for anything left in.
5.6 The reviewer confirms before submission: the evidence answers the request text; it covers the full period; populations reconcile; sample items match the auditor's selection; classification and approvals are recorded; and nothing out of scope is included.
6. Request library: common security and identity requests
6.1 Prepare these before the PBC list arrives. Exact wording varies by auditor and framework.
| Request | Typical evidence | Where it comes from |
|---|---|---|
| Joiners in the period and their access approvals | HR starter list, access tickets with approval before provisioning date | HR system, ticketing tool, identity governance tool |
| Leavers in the period and access removal | HR leaver list, account disable timestamps per system | HR system, identity provider sign-in and audit logs |
| User access reviews | Review campaign records, reviewer decisions, evidence that revocations were applied | Identity governance tool or review workbooks |
| Privileged account population | List of admin role holders with justification and last review | Identity provider role assignments, PAM tool |
| Non-human identities with production access | Service accounts, API keys and workload identities with owners and last rotation | Cloud IAM, secrets manager, NHI inventory |
| MFA enforcement and exceptions | Policy configuration export, list of excluded accounts with approvals | Identity provider, MFA exception register |
| Change management sample | Change tickets with approval, testing and deployment records | Ticketing tool, CI/CD pipeline logs |
| Vulnerability remediation | Scan results, tickets, closure within SLA, approved exceptions | Scanner, ticketing tool |
| Backup and restore testing | Restore test records with dates and outcomes | Backup platform reports |
| Security incidents | Incident log, sample incident records and post-incident reviews | Incident management tool |
| Logging and monitoring | Log source inventory, retention settings, alert review records | SIEM |
| Security awareness training | Completion report for the period against the staff population | Learning platform, HR system |
| Third-party reviews | Supplier inventory, risk assessments, assurance reports reviewed | Third-party risk tool |
6.2 For machine identities and AI agents, see Audit Readiness for AI Agents and NHIs for the evidence auditors increasingly ask for.
7. Sharing, access and retention
7.1 Share evidence through [the auditor portal or a restricted repository folder with read-only auditor access], never by email attachment. Grant auditor accounts access for the engagement period only and remove it at closure.
7.2 Do not give auditors standing access to production systems. Where direct observation is needed, use a screen share or a time-limited read-only role that is logged.
7.3 Retain the tracker and evidence for [7 years or the period your regulator or contract requires], then delete according to the records schedule.
8. Closure and lessons learned
8.1 At engagement close the coordinator records: requests by status, median turnaround from Logged to Accepted, requests queried more than once, overdue requests by owner, and findings raised.
8.2 Requests queried more than once, or that needed manual collection, become candidates for automated evidence collection before the next cycle. See the Compliance Automation Guide.
Implementation guidance
- Agree the mechanics at planning: submission channel, request format, due dates, query process and who in the audit team may raise requests.
- Prefill from last year. Load the previous cycle's accepted requests and pre-assign owners, so most rows start at Assigned on day one.
- Pilot the workflow on one internal audit before an external engagement, and fix the columns people leave blank.
- Measure: share of requests accepted first time, median turnaround, overdue requests per week, query count per request, and evidence prepared before the PBC list arrived.
- Map for audit: NIST SP 800-53 Rev. 5 CA-2 Control Assessments and CA-7 Continuous Monitoring; NIST CSF 2.0 GV.OC-03 (legal, regulatory and contractual requirements understood and managed); CA-5 Plan of Action and Milestones for findings that arise.
Common failure patterns to avoid: one row per vague request so nobody knows when it is done; owners named as teams; populations exported with no query or run date; evidence emailed as attachments and lost; screenshots without timestamps; and the same request rebuilt manually every year.
Related NHI Mgmt Group resources: Audit Evidence and Continuous Controls Monitoring Guide · Audit, Assurance and Compliance Guide · Compliance Automation Guide · GRC Platform Buyer's Guide