grcskills
Menu

Auditor sample preparation

Use this skill when an external audit, attestation examination or assessment is coming and the team wants populations and evidence ready for the samples the auditor will pull, or asks "prepare for audit sampling", "what samples will the auditor ask for", "get our populations ready", "the auditor wants a list of all changes in the period", "evidence for the leavers sample", "Type II sample prep" or "how do we prove completeness of the population". Lists the populations an auditor is likely to sample, builds each from the system of record with the query that produced it, checks completeness and the evidence behind a dry-run sample, and writes a readiness file per population plus a list of gaps to fix before fieldwork.

Audit prep and responseISO 27001SOC 2PCI DSS

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.

Step 4: dry-run a sample

Pick five items per population yourself at random (not the cleanest ones), plus the earliest item in the period (auditors test whether the control already operated at the start, especially in a first attestation period). Gather the evidence for each as the auditor would want it: the record itself, timestamped, showing the system and the identity of whoever approved or acted. Note for each item: evidence found, where, and anything missing. If two of five fail, the control has an operating problem; write it in the gap list (gaps.md) with an owner and a draft corrective action for the control owner to raise in the company's own process, because fixing evidence for five items does not fix the other items.

Step 5: write the gaps and the readiness index

The gap list (gaps.md) shows each population with missing exports, reconciliation breaks, failed dry-run items and controls with no record at all, each with an owner role and a proposed fix. The index (populations.md) shows every population as ready, ready with explanations, or not ready, and names the person who can pull the evidence for any selected item on the audit day.

What good looks like

  • Each population has a checked query and a count that ties to an independent total. Someone else can regenerate it, but the tie-out to another source is what shows nothing is missing.
  • Reconciliations are done before the auditor does them. The leaver who still had access for three weeks is found and explained, not discovered in fieldwork.
  • The common mistake is preparing a polished evidence folder for hand-picked items. The tell: the team cannot produce evidence within a day for an item the auditor picks at random.
  • Exceptions are written down honestly with their cause and the fix; auditors deal far better with a disclosed exception than one they find.
  • Evidence is original and dated in the period; nothing is created or re-signed afterwards.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-auditor-sample-preparation

Rules

  • MUST record the source system, query and row count for every population.
  • MUST reconcile linked populations and record every unmatched item.
  • MUST write outputs only inside ./auditor-sample-preparation/ and ask before overwriting an existing file.
  • NEVER create, backdate, re-sign or alter evidence to fill a gap; record the gap instead.
  • NEVER pre-select the items the auditor will test or steer their selection.
  • NEVER copy personal data or secrets from exports into the output files; reference records by id and count.