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