grcskills
Menu

Evidence request list builder

Use this skill when an auditor, assessor or regulator has sent a request list and the team asks "turn the auditor's request list into tasks", "who needs to provide what", "build the evidence tracker", "split the PBC list by owner", "what exactly do they want for this request" or "we have two weeks to send everything". Normalises each request into owned, dated tasks naming the exact artefact, period and source system, separates population requests from sample requests, batches the clarification questions, and writes a tracker plus one brief per owner.

EvidenceISO 27001SOC 2NIS 2DORA

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.

Step 3: assign owners and back-schedule dates

For each row name the owner role, the source system and the person who reviews before release. Set the internal due date at least five working days before the auditor's date for populations and three for single documents, so review and redaction fit. Owners with more than fifteen items will slip; rebalance or tell the reader early. When no owner can be named because no process exists, mark it in the tracker as a control gap for the corrective action owner and tell the reader; never let someone improvise an artefact. "We do not do this yet, here is the plan" survives an audit; an invented spreadsheet does not. Where the right artefact depends on what a framework expects for that area, run a framework lookup before assigning the task, so owners do not collect the wrong thing.

Step 4: batch the clarifications

Collect every unclear request into the question list (clarifications.md), one question each, written so the auditor can answer in a line: "For request 14, should the population include contractors, or employees only?" The audit lead sends them as one batch, not a drip. Mark the affected rows "waiting on auditor" so nobody works on a guess.

Step 5: set the release check

Before any artefact goes to the auditor, check five things: it covers the requested period; it shows who did what and when; it answers the request as written; it carries no secrets, keys, passwords or tokens; and personal data is limited to what the auditor needs (names may be needed for a leaver sample, home addresses never are). Each tracker row carries a release-check column with the reviewer's role. Mark requests from a regulator (a NIS 2 or DORA authority): they rest on supervisory powers, so their release check also goes through counsel or the data protection officer, and scope is agreed in writing before anything is redacted. Review the tracker daily during the response window. Write the owner briefs (owner-briefs.md) with one section per owner: their rows, the exact artefact, the period, the due date and an example of a good submission.

If the output folder exists, ask before overwriting and offer a new subfolder instead.

What good looks like

  • Each owner receives a short list of exact artefacts with dates, not the auditor's full list.
  • Every population has a recorded source query, so the auditor can trust it is complete and the team can rerun it.
  • The common mistake is forwarding the request list verbatim to the team. The tell: owners send the same policy for five different requests, screenshots from the wrong period, and populations exported from the system being tested.
  • Clarifications go out in one batch within the first two days, so the team spends fieldwork collecting, not guessing.
  • The tracker is the single source of truth, readable in one screen per owner.

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-evidence-request-list-builder

Rules

  • MUST keep the auditor's wording of each request unchanged next to the interpretation.
  • MUST record the source system and query for every population.
  • MUST write outputs only inside ./evidence-request-list-builder/ and ask before overwriting.
  • NEVER upload, send or share evidence with the auditor; the reader's team releases it.
  • NEVER include secrets, keys or credentials in any artefact or tracker entry.
  • NEVER send clarification questions to the auditor on the reader's behalf.