Setting up an audit programme and schedule | auditchecklists.org Audit Guide

Programme vs. audit vs. plan — get the vocabulary straight

Three words get used interchangeably and shouldn't be. Keeping them distinct is the difference between a programme an assessor respects and a pile of ad-hoc reviews.

Audit — a single engagement against a defined scope and criteria, producing one report. "The Q2 access-management audit."
Audit programme — the standing, multi-period arrangement that schedules all the audits, assigns resources, sets the rules they run under, and guarantees coverage across a full cycle. The programme is a managed thing with an owner, objectives, and a review loop.
Audit plan — the engagement-level plan for one audit: its scope, dates, people, criteria, and approach. One plan per audit.

Step 1 — Decide what to audit

You cannot schedule what you have not listed. The first job is to write down what to audit (your audit scope) — the complete inventory of everything that could be audited: processes, business units, sites, systems, third parties, and individual regulatory obligations. This list is the denominator for your coverage claim.Build it like this:

Pick the spine. For a regulation-driven programme, the regulation's own structure is the natural backbone — each article or clause (or a tight group of related ones) becomes an auditable unit. For an operations-driven programme, use the process map or the org chart. Most mature programmes blend both: obligations cross-referenced to the processes that satisfy them.
Decompose to a useful grain. Too coarse ("GDPR") and you can't schedule or risk-rate it; too fine (every sub-clause as its own audit) and you drown. Aim for units that one engagement can reasonably cover in a few days.
Attach an owner to each unit. Who runs the process / owns the obligation. You'll need this for scheduling and for independence checks later.
Record what each unit depends on. Shared systems, key third parties, upstream processes. Dependencies drive both risk and the order you audit things in.

A starter list of what to audit for a mid-size data-processing function

A 120-person SaaS company building its first GDPR-driven programme lists its scope as twelve auditable units:

Records of processing & data inventory
Lawful basis & consent management
Data-subject rights handling (access, erasure, portability)
Retention & deletion
DPIA process & high-risk processing
Processor management & Article 28 contracts
International transfers
Breach detection & 72-hour notification
Privacy notices & transparency
Access control & security of processing
Staff training & awareness
Governance, DPO & accountability records

Twelve units, each ownable, each auditable in 2–4 days. That is a list you can schedule. "Audit GDPR" is not.

Step 2 — Set frequency by risk, not by calendar habit

The most common programme mistake is auditing everything once a year. Annual-everything spends finite audit effort evenly across units that carry wildly different risk — the breach-notification process and the privacy-notice wording get the same attention, which is wrong in both directions.Replace it with a base cycle plus risk-driven frequency:

Set a base coverage cycle — the period within which every unit gets audited at least once. One to three years is typical. A two-year base cycle means each unit is seen at least every two years even if nothing flags it.
Risk-rate each unit (see risk-based auditing for the scoring method). High / medium / low is enough to start.
Map rating to frequency. A workable default: high-risk units every 6–12 months; medium annually-to-biennially; low once per base cycle.
Reserve capacity for triggered audits. Hold back roughly 15–25% of audit days for unplanned engagements after an incident, a complaint, a major system change, or a regulatory amendment. A programme with no slack cannot respond to events.

Risk rating	Audit frequency	Typical depth
High	Every 6–12 months	Walkthrough + substantive testing + sampling
Medium	Annual to every 2 years	Document review + interview + limited sampling
Low	Once per base cycle (1–3 yrs)	Document review + confirmatory interview

Step 3 — Build a balanced schedule

Once you know what to audit and how often, the schedule lays engagements across the calendar. A good schedule is balanced in three ways: across time, against the business's own rhythm, and against auditor capacity.

Spread the load. Don't let every audit fall in one quarter. Distribute so no period is overloaded and findings have time to be acted on before the next wave.
Audit a process when it is actually running. Schedule the onboarding audit during a hiring period; don't audit year-end controls in July from memory.
Avoid the business's blackout periods. Year-end close, peak season, a major migration — auditing then gets you distracted auditees and an unrepresentative picture.
Name the auditor and check independence now — not on the day. An auditor cannot audit their own area (see roles & responsibilities); catch the clash at scheduling time when you can still swap.
Sequence by dependency. Audit a shared platform before the processes that rely on it, so a platform finding informs the downstream audits.

Weak schedule

"All 12 units audited in November by the compliance manager." Everything lands at once, the auditor owns several of the units personally (no independence), and any finding lands too late in the year to fix. This is a checkbox, not a programme.

Strong schedule

"High-risk units (breach handling, access control, processor management) in Q1 and again Q3; medium units spread across Q2 and Q4; low-risk units once this year; two engagements each handled by an auditor independent of that area; 20% of days unallocated for triggered work." Balanced, independent, responsive.

Step 4 — Document the programme so it's auditable itself

The programme is itself evidence. Write it down in a short standing document that an assessor can pick up cold and understand. At minimum it states:

the programme's objectives and scope — what assurance it exists to provide;
what is audited (the scope) and how units were derived;
the risk-rating method and each unit's current rating;
the frequency rules and the resulting schedule;
the roles — who owns the programme, who audits, how independence is preserved;
the review cadence — when and how the programme itself is reassessed.

Step 5 — Review and adapt the programme

A programme is a living control, not an annual artefact. Feed four things back into it continuously:

Findings — a serious finding in one unit may pull forward the next audit of a related unit, or raise its risk rating.
Incidents and complaints — these are unplanned signals that a unit's risk has changed; they often trigger an out-of-cycle audit.
Regulatory change — an amendment can add a unit to the list of what to audit, or raise an existing unit's priority.
Organisational change — new systems, new processors, reorganisations, acquisitions all reshape what needs auditing.

Record why the programme changed each time. That rationale trail is itself strong evidence of a risk-driven, responsive process — exactly what an assessor is looking for, and exactly what a static annual plan cannot show.

Related guides

This guide explains the method. To apply it across a whole regulation — every obligation scored and traceable — see the audit checklists, each with a free Regulatory Compliance Matrix you can review before buying.