The work program is the contract between planning and fieldwork. Planning produced a risk assessment and a risk and control matrix; fieldwork will produce evidence and workpapers; the work program is the document in between — the one that says, procedure by procedure, what we will actually do, in what order, by whom, within what budget, and to prove what. Done well, it is the reason a three-week audit finishes in three weeks with every risk covered. Done badly — vague steps, no linkage, hours invented at kickoff — it is the reason fieldwork drifts, juniors improvise, review notes multiply, and the last audit day is spent discovering what was never tested.
This guide is the program end to end: what it is and is not, every section of the template and why it exists, the craft of writing procedures someone else could execute, a fully worked program for a user access management review — with linked risks, evidence, and budgeted hours — and the disciplines of budgeting, live execution, and reuse. It completes the template pair with our RCM template guide: the matrix says what could go wrong and what should stop it; the program turns that matrix into a schedule of work.
In this guide
- What the work program is — and what it is not
- The template: every section and why it exists
- Writing procedures someone else could execute
- A fully worked program: user access management
- Budgeting hours honestly
- Running it live: sign-offs, deviations, scope changes
- Program libraries and the copy-forward trap
- The classic failure modes
What the work program is — and what it is not
A work program is an ordered set of procedures, each traceable back to a risk or control worth testing and forward to the workpaper that will hold its evidence. Three boundaries keep the document honest. It is not the RCM: the matrix is the analytical inventory (risks, controls, classifications), while the program is operational — sequenced steps, owners, hours. When the two are merged into one sprawling spreadsheet, the analysis stops being maintained and the steps stop being sequenced. It is not the audit plan: the annual plan decides which engagements happen; the program decides what happens inside one engagement. And it is not the workpapers: the program says “select 25 access grants and trace to approved tickets”; the workpaper shows the 25, the tickets, and the exceptions. The Global Internal Audit Standards make the work program an explicit requirement of engagement planning (Standard 13.6, Work Programs, in the engagement-planning principle of our GIAS reference map) — including the requirement that programs be approved before implementation and adjusted, with approval, as the engagement evolves.
The quality bar for the whole document is the same handoff test we apply to control descriptions: could a competent auditor who was not in the planning meetings pick this up and execute it? Every weakness a program has — vague verbs, missing populations, undefined exceptions — is invisible to the person who wrote it, because the writer carries the missing context in their head. The program exists precisely because the writer and the executor are usually different people, separated by team structure or by six months of time.
The template: every section and why it exists
| Section | What goes in it | Why it exists |
|---|---|---|
| Header block | Engagement name, period covered, program version, preparer, approver, approval date | The approval line is a Standards requirement, and version control matters once the program changes mid-fieldwork |
| Engagement objective | One or two sentences: what opinion or answer this audit exists to produce | Every procedure below must serve it; the objective is the test for cutting scope creep |
| Scope and period | Processes, systems, locations, and dates in scope — and notable exclusions | Exclusions written down at planning cost nothing; discovered at reporting they look like evasion |
| Background | Process summary, key systems, volumes, prior findings, changes since last audit | The ten-minute orientation that saves the executor two days of rediscovery |
| Risk and control linkage | The RCM rows this program covers, by ID | Proves coverage: every key control has a procedure, every procedure has a reason |
| Procedures | The ordered steps — see the whole next section | The program’s engine room |
| Budget and assignments | Hours and owner per procedure or cluster | Turns the program into a manageable schedule; unbudgeted programs discover overruns at the deadline |
| Sign-off columns | Performed by / date / workpaper ref / reviewed by | The completion record — and the first place a QA reviewer looks |
| Change log | Procedures added, dropped, or modified mid-engagement, with approval | Programs legitimately evolve; undocumented evolution is indistinguishable from corner-cutting |
Writing procedures someone else could execute
A procedure step needs five elements, and weak programs are weak because steps are missing two or three of them: the action (a testing verb — inspect, trace, reperform, recalculate, observe, confirm; “review” and “assess” are how programs smuggle in vagueness), the population and source (which records, from which system or report — named, so the executor pulls the same population the writer meant), the selection (full population via analytics, or a sample with its size and method, referencing your sampling standard), the criteria (what “passes” — the attribute being tested, stated so an exception is unambiguous), and the evidence destination (what gets documented, in which workpaper). Compare: “Review user access for appropriateness” — no population, no selection, no criteria, no destination; two auditors would do two different things and both would call it done. Versus: “Obtain the complete list of active accounts from the identity platform as of period end; reconcile count to HR actives; select all privileged accounts and 25 standard accounts; for each, inspect the provisioning ticket and verify access level matches the approved request; document in WP C-2, listing every mismatch as an exception.” Same audit area, but the second step can be executed, reviewed, and defended by someone who has never met the writer — which is the entire point of writing it down.
A fully worked program: user access management
Here is a complete procedures section for a user access management review — the process whose RCM row appears as the sixth worked example in our matrix guide. Scope: ERP and the identity platform, full fiscal year. Every step carries its RCM linkage, budget, and workpaper destination.
| # | Procedure | RCM ref | Hrs | WP |
|---|---|---|---|---|
| 1 | Conduct process walkthrough with the IAM lead covering provisioning, termination, certification, and privileged access; update the RCM where practice has diverged from the documented design before testing begins | All | 4 | A-1 |
| 2 | Obtain the complete active-account extract from the identity platform as of period end; reconcile to HR active headcount; investigate and disposition every unmatched account | C-UA-01 | 6 | B-1 |
| 3 | Select all privileged-access grants and 25 standard grants made during the period; for each, inspect the provisioning ticket and approval, and verify the access granted matches the role requested | C-UA-02 | 10 | C-1 |
| 4 | Obtain the full population of terminations in the period; using analytics, compute days from termination date to access removal for every system in scope; test every removal exceeding the 5-business-day SLA | C-UA-03 | 8 | C-2 |
| 5 | For the full population of administrative accounts, inspect business justification, IT-security approval, and MFA enforcement configuration | C-UA-04 | 6 | C-3 |
| 6 | Run the segregation-of-duties ruleset against current role assignments; investigate every conflict against documented mitigating controls; report unmitigated conflicts as exceptions | C-UA-05 | 8 | C-4 |
| 7 | For two of the four quarterly access certifications, verify the certified population was complete against the account extract, inspect evidence of owner review, and test that flagged revocations were executed within SLA | C-UA-06 | 8 | C-5 |
| 8 | Inventory generic and service accounts; verify each has a named owner, vaulted credentials, and configuration preventing interactive login | C-UA-07 | 5 | C-6 |
| 9 | Inspect authentication configuration (password parameters, MFA scope, session timeout) against the security policy baseline | C-UA-08 | 3 | C-7 |
| 10 | Consolidate exceptions, perform root-cause analysis, draft findings, and hold the closing meeting with the process owner | — | 8 | D-1 |
Sixty-six field hours; with supervision and review at roughly twenty percent, an eighty-hour engagement. Notice the shape. Analytics take the full population wherever the data allows (terminations, SoD, privileged accounts) and samples appear only where evidence is ticket-by-ticket manual — the same layered logic as risk-scored journal entry testing. The walkthrough comes first and explicitly revalidates the RCM, so the program never tests a control that stopped existing. And every procedure states its budget and destination, which means slippage and coverage are visible mid-fieldwork — procedure 4 running double its hours is a Tuesday conversation, not a deadline surprise.
Budgeting hours honestly
Budgets fail in one direction: built backwards from the hours available rather than forwards from the procedures required. The backwards budget produces the silent trim — procedures quietly shrink to fit, nobody decides anything, and the coverage loss surfaces at reporting when it is too late to be a choice. Build forwards instead: estimate per procedure (selection size × minutes per item, plus setup and documentation), sum, add review at fifteen to twenty-five percent, and then compare to capacity. If the total exceeds the box, cut scope explicitly — drop a procedure, shrink a sample against your sampling standard, defer a system — and record the cut in the change log with the risk it leaves on the table. The difference between a trimmed program and a silently trimmed one is that the first is a documented management decision and the second is a QA finding waiting to be written.
Running it live: sign-offs, deviations, scope changes
The program is a live instrument during fieldwork, and three disciplines keep it honest. Sign off in real time: performer, date, and workpaper reference recorded as each procedure completes — a program signed off in one sitting at wrap-up is a reconstruction, and reviewers can tell. Deviate on the record: when a procedure cannot run as written — the population is unavailable, the control changed, the sample makes no sense against reality — the adaptation goes through the change log with approval, exactly as the Standards’ adjust-with-approval requirement anticipates. Silent adaptation is indistinguishable from corner-cutting precisely because, some of the time, it is. Expand deliberately: exceptions trigger the escalation you pre-agreed (extend the sample, pivot to full-population analytics, raise a finding), and anything that grows into a finding should trace cleanly back to the procedure that surfaced it. The program’s sign-off grid, at any moment, should answer the engagement’s most operational question: what is done, what is in flight, and what is at risk of not happening.
Program libraries and the copy-forward trap
Program libraries are worth building — an access review, an AP audit, a payroll audit share most of their procedure skeletons across companies and years, and rewriting them from zero is waste. The trap is storing filled programs instead of patterns. A library entry should be parameterized — the procedure shape with slots for the system name, population source, sample size, and thresholds — so that reuse forces the writer to touch every assumption. Copying last year’s completed program wholesale imports last year’s systems, last year’s SLAs, and last year’s blind spots, and the refresh walkthrough (procedure 1, always) is the immune response: it is where the copied program collides with the process as it exists now. Same rule as the RCM, for the same reason: these documents compound, so what you let into the template propagates for years.
The classic failure modes
| Failure mode | What it looks like | The fix |
|---|---|---|
| Vague verbs | “Review access for appropriateness” — two auditors produce two different tests | Five-element procedure standard: action, population and source, selection, criteria, evidence destination |
| Coverage holes | A key control with no procedure, discovered when the report claims coverage it cannot support | RCM-linkage column plus a completeness check at approval: every key control maps to a step |
| Budget fiction | Hours copied from last year’s total; overrun discovered in the final week | Forward-built per-procedure budgets; weekly burn vs. sign-off tracking |
| Silent deviations | Procedures adapted or dropped in the field with no record | Change log with approval; deviations are decisions, so document them like decisions |
| Copy-forward staleness | The program tests a workflow retired two systems ago | Parameterized library entries; mandatory refresh walkthrough as procedure 1 |
| Reconstructed sign-offs | Every procedure signed off the day before review | Real-time completion discipline; the sign-off grid is the engagement’s status board, not its epilogue |
Final thoughts
The RCM and the work program are the two documents that make audit work repeatable: the matrix holds the thinking, the program turns it into a schedule someone else can run, and the workpapers prove it happened. Write procedures to the five-element standard, budget forwards, deviate on the record, and store patterns rather than filled programs — and each engagement leaves the next one better equipped. If you want the analytical half generated for you, the RCM Workbench builds the starter matrix this program format is designed to execute against — walk the process, fix the matrix, and the program almost writes itself.
Leave a Reply