Use this once per cycle and again when scope, frameworks or the risk picture change materially. You get three files in a new folder, ./internal-audit-programme-planning/: a short plan document saying what gets audited, why, by whom and how findings are followed up (programme.md), a spreadsheet you can open in Excel showing every audit area against each year of the cycle (coverage-matrix.csv), and a second spreadsheet with the proposed audit dates and auditors (calendar.csv). This skill drafts for a human to review and sign; this skill never marks a control effective. Leadership approves the programme; the skill proposes it.
Inputs to gather
Read the scope statement, the list of processes and controls in scope (applicability statement or control list), the risk register, previous internal and external audit reports with open findings, the incident log, the org chart, and the external audit dates. Ask the reader in one message: which frameworks and how many sites or legal entities are in scope, the external audit or examination window, who could act as auditor (internal staff, a peer from another team, a contracted auditor), and the budget in days.
Step 1: list the audit areas
Group the scope into 8 to 15 auditable areas a person can cover in half a day to two days each: governance and leadership, risk management, people (joiners, movers, leavers, training), access management, change and development, operations and monitoring, incident management, continuity and backup, suppliers, privacy processes, AI system lifecycle, physical sites. Keep the management system processes (scope, leadership commitment, objectives, competence, document control, internal audit itself, corrective action, management review) as their own area; they are audited too. When several management system standards are in scope, add each one's own areas, such as privacy risk assessment or AI impact assessment.
Step 2: rank each area by audit risk
Score each area 1 to 3 on four factors and add them:
- Inherent risk: the highest residual score of the risks the area treats.
- Change: new systems, new teams, reorganisation, new framework since the last audit.
- History: open or repeat findings, incidents traced to the area.
- Evidence weakness: controls that are claimed but thinly evidenced.
Totals of 10 to 12 are audited at least yearly, or twice if a repeat finding is open; 7 to 9 yearly; 4 to 6 at least once per cycle. Check the result against what the framework expects for coverage and frequency with a framework lookup; do not assume.
Step 3: assign auditors and check independence
Nobody audits their own work or a process they run. In a company of 15 to 50 people, the usual answers are cross-auditing between teams, a contracted auditor for areas where everyone is involved (often governance and security operations), or a mix. Record for each area: auditor role, why they are independent of it, and their competence (training, prior audits, framework knowledge), with a pointer to the record that shows it; the certification auditor samples that trail. Where independence cannot be achieved inside, say so and propose the contracted option with an estimate of days.
Step 4: schedule the calendar
Place audits so that findings can be corrected before the external audit or the end of the examination period: finish the yearly round at least six to eight weeks before the external audit and before the management review that must read the results. Avoid release freezes, financial year end and peak seasons the reader names. For a first certification, plan the internal audit round and the management review a full quarter before the main certification audit, so corrective actions show evidence that they work, not only that they closed. For a readiness audit ahead of an attestation examination, test the controls over a sample of the period, not just their design. A readiness review by a consultant is a separate deliverable; it does not replace the internal audit. Allow 1 day of preparation and 0.5 day of reporting per audit day. Put the proposed dates, areas and auditor roles in the calendar spreadsheet (calendar.csv).
Step 5: write the programme
The plan document (programme.md) states objectives, scope, criteria (the frameworks plus the company's own policies), the ranking method, auditor assignments with independence notes, reporting route (findings to the owner, summary to management review), how findings are tracked to closure, and what triggers an unplanned audit (a major incident, a significant change). The coverage spreadsheet (coverage-matrix.csv) lists every area and control group against the years of the cycle, with one column per framework in scope and a fixed set of rows for the management system processes, so gaps in coverage are visible at a glance.
What good looks like
- Every in-scope area is covered at least once in the cycle, and the riskiest ones every year; the matrix shows it without reading the prose.
- Independence is argued, not asserted: the matrix says who audits what and why that person is not marking their own homework.
- The common mistake is a calendar that audits every area once a year in a fixed order with the security lead as sole auditor. The tell: the programme would be identical for any company, and the person who wrote the policies audits them.
- The schedule leaves time to fix findings before the external audit.
- The programme changes when the risk picture changes; it names the triggers that cause an extra audit.
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-programme-planning
Rules
- MUST record for every area who audits it and why that person is independent of it.
- MUST cover every in-scope area at least once in the cycle in the coverage matrix.
- MUST write outputs only inside
./internal-audit-programme-planning/ and ask before overwriting an existing file.
- NEVER assign an auditor to a process they own or operate.
- NEVER approve the programme or commit audit days on leadership's behalf.
- NEVER book meetings or send invitations; the reader schedules the audits.