Use this one to three weeks before an audit, once the audit plan or agenda is known. You get a new folder, ./auditor-interview-prep/, holding a one-to-two-page briefing note for each person the auditor will interview, with the likely questions, the records they should open and how to answer (briefs/<role>.md, one per role), and a timetable of the interview sessions with topics, backups and the coordinator (schedule.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The aim is people who can show what they do, not people who recite policy.
Inputs to gather
Read the audit plan or agenda, the control list or applicability statement with owners, the policies and procedures each role is named in, the last audit report and its findings, and the evidence folder. Ask the reader in one message: which roles the auditor has asked to meet, who is new in their role, which areas had findings before, and who coordinates on the audit day.
Step 1: map roles to what the auditor will test
For each interviewee role, list the processes they own or operate, the controls mapped to them, the risks they own, and any open finding in their area. Leadership gets questions on direction, resources, risk decisions and management review, and each executive should be able to name one decision from the last review and what changed because of it; process owners on how their process runs and how they know it works; engineers and operators on the real steps, the last time they did them and where the record is.
Step 2: write the likely questions
Write 8 to 12 questions per role, in the auditor's style: open, about the last real occurrence, and followed by "show me". Put the audit period at the top of every brief; the last occurrence the person names must fall inside the window the auditor samples from, or they should know why there was none. Examples: "Walk me through the last person who left. Show me when their access was removed." "How do you decide whether a change needs approval? Show me an emergency change from this period." "What did leadership decide at the last review, and what happened next?" For framework-specific topics a role must speak to, run a framework lookup on what the auditor is likely to probe rather than inventing it.
Step 3: list the records each person opens
For each question, name the record that answers it and where it lives, and have the person open it once before the audit. An interviewee who can open the right ticket in thirty seconds needs fewer words than one who describes the process from memory.
Step 4: brief on how to answer
Every brief carries the same guidance:
- Answer the question asked, then stop. Long answers open new lines of questioning.
- Show the record instead of describing it.
- When you do not know: say so, say who knows or where it is recorded, and offer to come back. A guess that contradicts a record is worse than "I will check".
- When practice differs from the document, say what you actually do. The auditor will find the difference anyway; candour turns a possible finding into a conversation.
- Do not speculate about other teams' processes.
- Never create, backdate or tidy a record for the audit. A missing record is a finding to manage; a fabricated one ends trust in everything else.
- If a finding is raised, ask what evidence the auditor saw; do not argue in the interview. Disputes go to the audit coordinator.
Step 5: run a short mock interview
For each role, script a 15-minute mock with four questions from the brief, asked by someone outside the person's team, and for an internal audit never by someone who runs the process being tested. Note where the person could not find a record or contradicted a document; those are items to fix before the audit, in the process or in the document, not in the script.
Step 6: build the schedule
The interview timetable (schedule.md) lists each session: role, time, topics, records to have open, the backup person if the interviewee is absent, and the coordinator who tracks auditor requests made during the session. The coordinator keeps a written request log (request, owner, due time) and reviews it at the end of each audit day; "can you send me that later" is the item most often lost.
What good looks like
- Interviewees speak about the last real occurrence and open the record without help. That is what convinces an auditor.
- The common mistake is coaching people to recite policy wording or memorise answers. The tell: answers sound identical across roles, and the first "show me" stalls the interview.
- The briefs surface real gaps before the audit; a mock that finds nothing usually was too gentle.
- "I do not know, here is who does" is treated as a good answer, and people know that.
- New joiners and backup staff are briefed too; auditors often ask for whoever is available.
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-interview-prep
Rules
- MUST tie every likely question to a record the interviewee can open.
- MUST include the guidance on answering honestly when the person does not know.
- MUST write outputs only inside
./auditor-interview-prep/ and ask before overwriting an existing file.
- NEVER script answers that misstate practice, or coach anyone to hide a gap from the auditor.
- NEVER name individuals in the briefs; use roles.
- NEVER send briefs or invitations to staff; the reader distributes them.