plan-and-execute-audit-engagement

Skill: plan-and-execute-audit-engagement

Invoked by: audit-engagement-specialist (primary). Also consulted by internal-audit-lead to confirm a planned engagement is scopeable and resourced before it enters the annual plan.

When to invoke: "draft the planning memo / scope this engagement"; "build the risk & control matrix"; "test of design vs test of operating effectiveness — how?"; "what's the attribute-sample size?"; "are these workpapers sufficient/review-ready?"; any "how do we run this engagement's fieldwork?" question.

Output: the planning memo (objectives/scope/criteria/approach/timing) + the risk & control matrix + the walkthrough result + the test-of-design and test-of-operating-effectiveness plan with sampling approach & sample size + the workpaper/evidence sufficiency note. (Findings + ratings are the sister skill rate-and-report-audit-findings.)

Procedure

1. Restate the engagement in the tree's terms. Capture: the auditable area (from the plan), the objectives, whether it's assurance or advisory, the period under review, the population/data available, and the criteria universe (which policies, regulations, frameworks, or standards define the "should-be").
2. Write the planning memo first. Fix objectives, scope (in and explicitly out), the key risks in scope, the criteria, the approach, the timing/budget, and the stakeholders. No fieldwork before scope and criteria are set — you cannot conclude against a bar you haven't named.
3. Build the risk & control matrix (RCM). For each key risk: name the control(s), the control type (preventive vs detective, manual vs automated, key vs non-key, entity- vs process-level), and the two planned tests — test of design and test of operating effectiveness. The RCM is the engagement's spine.
4. Walk through before you test operation. A walkthrough (one transaction end-to-end) confirms your understanding and the design of the control. A control that fails design can't operate effectively — flag it now rather than sampling a broken design.
5. Traverse the decision tree in ../../knowledge/internal-audit-decision-tree.md for the test approach:
   • automated control with reliable ITGCs → a single (or few) well-tested instance(s) can substitute for a large attribute sample,
   • manual control → attribute sampling: derive the sample size from the population size, the control frequency (annual/quarterly/monthly/weekly/daily/many-per-day), and the tolerable vs expected deviation rate — not a habitual "25",
   • name the selection method (random / systematic / haphazard) and the definition of a deviation,
   • for a quantitative/monetary conclusion consider monetary-unit (dollar-unit) sampling; for full-population testing use data analytics / CAATs.
6. Test and document to the evidence bar. Perform the test of operating effectiveness; capture in the workpaper the objective, the test performed, the population, the sample and selection, the result, the deviations, and the conclusion — evidence must be sufficient, relevant, and reliable (inspection / re-performance / third-party > inquiry alone), with a reference and review trail.
7. Conclude and hand off. State whether the controls over the in-scope risks are designed effectively and operating effectively; route deviations to rate-and-report-audit-findings for 5-C write-up and rating. State the flip conditions (a compensating control found, a population wider than assumed).

Worked example

User: "We're auditing procure-to-pay. Draft the memo and RCM, and how do we test the three-way-match control (~4,000 POs/year)?"

• Planning memo: objective — assurance that P2P controls prevent unauthorized/inaccurate disbursements; scope — PO creation → three-way match → payment for the FY; out of scope — vendor master governance (separate engagement); criteria — the P2P policy, delegation-of-authority matrix, and segregation-of-duties standard.
• RCM: risk "payment without valid PO/receipt" → control "system three-way match (PO ↔ receipt ↔ invoice) before payment", type preventive / automated / key; tests = design (does the config actually block a mismatch?) + operating effectiveness (did it over the year?).
• Walkthrough: push one transaction through; confirm the match is enforced by config, not a manual override.
• Because it's an automated control with reliable ITGCs: test the configuration once plus a small confirmatory sample (e.g. 25 attempts including forced mismatches), rather than an attribute sample sized for a manual control. If ITGCs are weak, revert to a manual-control attribute sample sized from the ~4,000 population, control frequency (many/day), and a 0% tolerable-deviation posture for a key control.
• Workpaper: config evidence + the mismatch-block test screenshots + the conclusion, referenced and review-signed.
• Flip condition: if manual overrides to the match exist, the automated conclusion collapses and the override population needs its own attribute sample.

Guardrails

• Scope and criteria before fieldwork — no conclusion without a named "should-be."
• Walkthrough / test design before testing operation — sampling a badly designed control wastes the sample.
• The sample size is a calculation (population × frequency × tolerable/expected deviation), not a reflexive "25"; for a key control the tolerable deviation is often near zero.
• Automated + reliable ITGCs lets one well-tested instance stand in for a large sample; weak ITGCs force you back to attribute sampling — the ITGC conclusion gates the reliance.
• Evidence is sufficient, relevant, reliable, and in the workpaper — inquiry alone is the weakest evidence; corroborate with inspection or re-performance.
• IA tests and concludes; it does not own or design the control. Keep the engagement independent.
• Volatile claims (framework versions, sample-size tables, regulatory criteria) carry a retrieval date and are re-verified before finalizing. See ../../knowledge/internal-audit-patterns-2026.md.