grcskills
Menu

Internal audit checklist from scope

Use this skill when an internal auditor has one process or area to audit and needs a working checklist built from the company's own documents, or asks "build an internal audit checklist", "audit questions for access management", "what do I test in the supplier process", "audit plan for this area", "how many samples should I take", "internal audit of our data protection process" or "test our incident process against what the policy says". Turns each commitment in the company's policies and procedures into a test with a question, a record to inspect, a sample and a pass criterion, adds framework-specific checks through a lookup, and writes a checklist file the auditor fills in during fieldwork.

Audit prep and responseISO 27001ISO 42001GDPRNIS 2DORA

Use this for one process or area per run (access management, change, suppliers, incident handling, data subject requests, AI system release). You get two files in a new folder, ./internal-audit-checklist-from-scope/: the audit checklist the internal auditor works through during fieldwork, one test per line with blank result columns (<area>-checklist.md), and a draft request package listing the records each owner must provide before fieldwork (<area>-requests.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The auditor performs the tests and grades the results; the skill does neither.

Inputs to gather

Read the audit programme entry for the area, its governing policies and procedures, the risk register entries it treats, the controls mapped to it, the previous audit report and open findings, and any incidents traced to it. Ask the reader in one message: the audit period (usually the last 6 to 12 months), the systems in scope, who owns and who operates the process, who the auditor is and whether they own or run any part of it, and how much fieldwork time is booked. If so, record the arrangement and any compensating review at the top of the checklist.

Step 1: extract the company's own commitments

Read the governing documents line by line and pull out every statement of the form "we do X, within Y, by Z": a timeframe, an approval, a review, a record. Each becomes a candidate test. Note commitments that cannot be tested because they are vague ("access is reviewed regularly"); those are findings in their own right, about the document.

Step 2: add the framework layer

For each framework the area is audited against, run a framework lookup on what the framework expects from this process, and add a test for anything the company's documents do not already cover. For the public-law frameworks, tie tests to the article where the obligation sits: for example the records of processing (GDPR Article 30), the cybersecurity risk-management measures (NIS 2 Article 21), the ICT risk management framework (DORA Article 6). Keep framework tests in a separate block so the auditor can see which come from the company and which from the framework.

Step 3: write each test

For each test, fill in:

  • Question to ask the owner, open and about practice ("walk me through the last leaver"), not "do you follow the policy".
  • Record to inspect: the system report, ticket, log or signed document that proves it, with where it lives.
  • Population and sample: the full list the sample is drawn from, and the size. Rule of thumb for internal audit: under 10 items, test them all; 10 to 50, test 5 to 10; above 50, test 10 to 25, weighted to riskier items (privileged accounts, emergency changes, critical suppliers). Always include the most recent item and one item from the start of the period. If the booked time forces samples below this, write the smaller size and the reason as a scope limitation for the report.
  • Pass criterion: what the record has to show, taken from the commitment ("access removed within one working day of the leaving date in the HR system").
  • Trace direction: forward (from the trigger to the record, which tests the process happens) or backward (from the record to the trigger, which tests nothing happens without authorisation). Include both for access and change. Where inspection cannot show the control blocks anything, propose one or two re-performance tests (a removed account trying to sign in, an unapproved change in a test path) for the auditor to run with the owner told first; the agent never runs them.
  • Result, evidence reference, finding grade: left blank for fieldwork.

End the checklist with a blank summary block for the auditor: tests performed, passed and failed, scope limitations, findings with grade and owner, and whether the area does what its own documents say. It becomes the audit report and the input to management review.

Step 4: add the observations nobody writes down

Add three standing tests to every checklist: does the process owner know the documented process (interview, not quiz), does what the system shows match what the document says, and were previous findings for this area closed with evidence that the fix worked. For a management system certification, add the management-loop tests: objectives defined and measured, this audit planned in the programme, findings routed to corrective action with a root cause, results reaching management review.

Step 5: build the request list

Collect every record the tests need into the draft request package (<area>-requests.md), grouped by owner, with the period and the format (system export with query parameters, not a hand-made list), and a short covering note per owner. The audit owner reviews the package and sends it to owners about a week before fieldwork, so populations are complete before sampling.

What good looks like

  • Every test traces to a sentence in the company's documents or to a framework lookup result, and the checklist shows which.
  • Populations come from the system of record. A sample drawn from a list the owner typed proves only that the list exists.
  • The common mistake is a generic checklist of framework topics phrased as yes or no questions. The tell: every answer is "yes", no record is inspected, and the audit finds nothing the team did not already know.
  • Sample sizes and selection are written down before fieldwork, so the result can be repeated and defended.
  • A good checklist for one area is 15 to 30 tests and fits the booked time; more than 40 means the area should be split.

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-internal-audit-checklist-from-scope

Rules

  • MUST state for every test whether it comes from the company's documents or from a framework lookup.
  • MUST define population, sample size and selection method before fieldwork starts.
  • MUST write outputs only inside ./internal-audit-checklist-from-scope/ and ask before overwriting an existing file.
  • NEVER fill in results, grades or conclusions; those belong to the auditor after fieldwork.
  • NEVER let the auditee choose the sample items.
  • NEVER send the request package or contact owners yourself; the audit owner reviews and sends it.
  • NEVER copy personal data from records into the checklist; reference records by id.