Use this the day the auditor's request list arrives, before anyone forwards it to the team; the audit lead confirms receipt and the timeline with the auditor within one working day. You get three files in a new folder, ./evidence-request-list-builder/: a spreadsheet you can open in Excel with one line per auditor request, its owner, due date and status (request-tracker.csv); a short brief per owner saying exactly what to collect and by when (owner-briefs.md); and the list of questions to ask the auditor, for the audit lead to send (clarifications.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The auditor decides what is sufficient.

Inputs to gather

Read the request list as the auditor sent it, the audit plan or engagement letter, any earlier evidence index, and the organisation chart. Ask the reader, in one message: the auditor's due date for each batch, whether the auditor will select samples themselves or expects the company to, how evidence is handed over (portal, shared folder, screen share), and who reviews evidence internally before it leaves.

Step 1: normalise every request

One row per request in the tracker spreadsheet (request-tracker.csv), with: the auditor's reference and wording, copied unchanged; the team's reading of it in one plain sentence; the artefact type (document, configuration, record, population, sample item, walkthrough); the period it must cover; the format the auditor asked for. The costliest fieldwork mistake is answering the request you assumed instead of the one written.

Step 2: split, classify and spot populations

Split compound requests: "provide the access review and evidence that removals were actioned" is two artefacts with possibly two owners. Then mark each request:

Population: the auditor wants a complete list (all leavers in the period, all production changes, all incidents) to sample from. The deliverable is the full list plus the query or report that produced it, from the system of record. Pull leavers from HR, not the identity provider; changes from what was deployed, not tickets. A population from the system being tested hides its own failures. Where two systems could each hold the population, pull both and reconcile; the person who left in HR but is still active in the identity provider is what the auditor will find on a cross-check.
Sample: the auditor has picked items; each needs the specific records for that item.
Standing document: a policy, procedure, plan or register; check the version in force during the period.
Walkthrough: someone shows the process live; book the person and the system.
As at a past date: configuration as it stood on an earlier date. A re-export today cannot recreate it; the state has to come from change records, logs or configuration backups. Say what a current export proves before anyone sends a screenshot from today.