auditor-sample-preparation
Use this four to eight weeks before fieldwork, or as soon as the auditor sends a request list. You get a new folder, ./auditor-sample-preparation/, holding: a one-page index of every list of records the auditor is likely to sample from, marked ready or not ready (populations.md); one short file per list explaining where it came from, how it was pulled and how many items it holds (<population>.md); and a list of the gaps found, each with an owner and a fix (gaps.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The auditor selects the samples; this skill only makes sure the team can answer any selection.
Inputs to gather
Read the auditor's request list if one exists, the control list or description of the system, the audit period, last year's audit report and sample requests, and the evidence folder. Ask the reader in one message: the audit period dates, which systems hold the records (HR, identity provider, ticketing, code hosting, cloud, payments), who can run exports from each, and whether the auditor shared a sampling approach.
Step 1: list the likely populations
Start from the controls that operate per event or on a cycle, because those are sampled. The usual set: joiners, leavers, role changes, access reviews, privileged accounts, production changes and emergency changes, deployments, vulnerabilities and their remediation, security incidents, backups and restore tests, supplier reviews, training completions, policy acknowledgements, and for card data environments, the system components in scope. Add any population last year's auditor asked for. For framework-specific populations, run a framework lookup instead of guessing.
Step 2: build each population from the system of record
For each population, write in its file: the source system, the exact query or report and its parameters (date range, filters), who ran it and when, the row count, and the fields. Prefer a system-generated export to any list a person typed; auditors test completeness and a typed list fails it. Reconcile one population against another where they should match: leavers in HR against accounts disabled in the identity provider; changes merged in code hosting against change tickets. Every unmatched item is either an explanation to write down now or a gap. A population can legitimately be empty (emergency changes often are): keep the query, the run date and the zero-count export, plus the configuration showing the path exists, because an unprovable "we had none" brings a follow-up request. Re-running the same query only shows it is repeatable; a query with a wrong filter returns the same incomplete list every time. Before marking a population ready, prove completeness two ways and record both in the file: someone other than the preparer checks the query logic (date range, filters, status values, whether deleted or archived records are included), and the count is reconciled to an independent source or control total, such as headcount movements from HR or payroll, the total of deployments in the pipeline, the system's own record count, or a finance total.
Step 3: plan for the sample sizes auditors use
Auditors scale samples with how often a control runs and how many items exist; ask the auditor for their approach early. Plan capacity so that any item can be evidenced: for per-event or daily controls expect a few dozen items; for weekly, around ten; monthly, a few; quarterly, two or more; yearly, the single occurrence. Where a population is small, expect it to be tested in full.