CIA Engagement Planning

Start with an answerable objective

An engagement objective states what the engagement is intended to accomplish. It should connect to an organizational objective, risk, or stakeholder need and be specific enough to guide testing. A broad request such as “review customer service” does not establish what the auditor should evaluate.

A sharper objective might ask whether customer refunds are authorized, calculated accurately, and recorded in the correct period. Another might ask whether complaints are escalated within required time limits. The objective determines the data, process steps, locations, and criteria needed.

Avoid writing an objective that presumes the conclusion. “Find evidence of fraud in refunds” is not neutral and can bias the work. A risk-based objective asks whether the process prevents, detects, or responds to unauthorized or inaccurate refunds. If fraud indicators arise, the auditor follows appropriate procedures and escalation without treating suspicion as a predetermined finding.

Define scope as the boundary

Scope describes the boundaries of the work. Common dimensions include business units, locations, systems, transaction types, time period, vendors, employee groups, and interfaces. Scope should be sufficient to answer the objective and proportionate to the risk.

For the refund example, the scope may include online and in-store refunds for a six-month period, the point-of-sale system, the customer-service workflow, and general-ledger posting. If gift-card refunds use a separate system, decide whether that pathway is relevant. Excluding it should be explained rather than assumed.

Scope is not frozen when new facts arise. If a preliminary survey reveals that high-risk transactions use a separate route, reassess whether that process falls within the objective. Document any revision and communicate material effects on timing, resources, or expected assurance. A scope restriction that prevents the objective from being achieved should be elevated rather than concealed.

Select appropriate criteria

Criteria describe the expected condition against which actual practice is evaluated. Sources may include law and regulation, contracts, board-approved policy, management procedures, system control design, risk appetite, or recognized standards. Choose criteria that apply to the entity, process, and period under review.

A finding that “approvals were late” requires an expectation for when approval must occur. If the policy permits emergency post-approval, the auditor must understand the emergency definition and required documentation. The existence of an exception path does not mean all late approvals are acceptable; it means the test must apply the full criterion.

If criteria are ambiguous, inconsistent, or outdated, clarify the authoritative requirement with appropriate stakeholders before drawing a compliance conclusion. Audit should report a weakness in criteria governance when relevant, but should not silently invent a stricter standard and judge management against it.

Understand the process before designing tests

Preliminary work helps the auditor understand flow, systems, handoffs, roles, controls, and data. Review prior audits, risk registers, policies, organizational changes, complaints, incidents, and relevant external requirements. Interview staff and managers, observe operations, inspect records, and conduct walkthroughs.

A walkthrough follows a transaction or event from initiation to final recording. It can reveal manual steps, overrides, approval points, system interfaces, and evidence locations. It provides insight into process design and helps identify where to test. One walkthrough does not prove that the process operated consistently during the full audit period.

Use a process map to surface handoffs and control gaps. For vendor onboarding, map request, due diligence, approval, master-file creation, bank-detail validation, purchase, invoice, and payment. A RACI chart may clarify who is responsible, accountable, consulted, and informed. These tools support understanding; they do not replace verification against actual evidence.

Assess and prioritize risk

Risk assessment evaluates uncertainty that could prevent the objective. Consider likelihood, impact, transaction volume, susceptibility to error or fraud, complexity, recent changes, prior issues, and control dependence. Determine which risks deserve the most attention and why.

Separate inherent risk from residual risk. Inherent risk exists before considering controls; residual risk remains after management’s responses. A process may have high inherent exposure but strong, well-operated controls. Conversely, a moderate inherent risk may remain significant if key controls are weak or bypassed.

Risk ranking should drive scope and procedures, not serve as a decorative matrix. Explain why a high-risk area receives more testing or specialist help. If the risk assessment changes because of new evidence, revise the work program and record the reason.

Identify controls and criteria links

For each prioritized risk, identify preventive, detective, and corrective controls and the person or system responsible. Determine whether a control is designed to address the risk and what evidence its operation should produce.

A dual approval may prevent unauthorized payments; a monthly reconciliation may detect duplicate payments after processing; an incident process may correct errors and recover funds. One control rarely addresses every part of a risk. Map each control to the relevant risk and objective.

Avoid relying on a control description without seeing how it operates. A policy may require separation, but system access may permit one user to request, approve, and create a supplier. Planning should identify which evidence can validate the actual workflow and whether system configuration needs specialist review.

Translate planning into a work program

The work program specifies procedures, sequence, population, period, evidence, selection approach, attributes, assigned staff, and expected documentation. It should be detailed enough to make the work consistent and reviewable.

For a refund authorization objective, a procedure might reconcile a system extract to a ledger control total, select transactions across channels and months, compare each to policy thresholds, inspect authorization evidence, recalculate amounts, and follow exceptions through posting. The sample design and inference should be specified before results are known.

The program remains adaptable. If the extract is incomplete, validate it before testing. If results show a concentration in one store or manager, assess whether expanded work is needed. Changes should remain tied to the objective and be reviewed by the appropriate supervisor.

Plan competence, tools, and timing

The chief audit executive or engagement supervisor should ensure the team has the required skills and resources. Consider subject-matter knowledge, data analysis, information security, language, geographic access, budget, and schedule. If the engagement requires specialized expertise, obtain qualified support or adjust the approach before fieldwork.

A resource plan should reflect complexity and risk. A simple control review may need limited data support; a cross-system cyber review may need technical specialists. Insufficient staffing can lead to inadequate sampling, weak review, or missed evidence. The auditor should communicate constraints rather than silently reduce work below what the objective requires.

Timing should include stakeholder coordination, data availability, fieldwork, review, validation, and reporting. A compressed deadline may require a narrower scope or more resources, but any limitation must be communicated. Do not promise broad assurance when the schedule permits only a small test.

Worked example: inventory adjustments

A manufacturer requests an audit of inventory adjustments after a rise in write-offs. The objective is to determine whether adjustments are authorized, supported, and recorded accurately. Scope covers adjustments above an established threshold, selected warehouses, and the last two quarters. Criteria include inventory policy, delegated authority, and accounting requirements.

The preliminary survey shows warehouse staff enter adjustments while finance approves them, but a system migration changed roles in one site. Risks include unauthorized shrinkage, duplicate entry, and delayed review. The auditor validates the adjustment population against ledger totals, inspects role access, and tests a risk-based selection that includes high-value and post-migration items.

If a selected adjustment lacks approval, the auditor determines whether approval evidence exists in another system and whether the transaction meets an allowed exception. The conclusion describes the supported condition, relevant policy, potential loss exposure, and limits of the sample. The recommendation addresses authorization and monitoring; management selects and owns the fix.

Common planning errors

Starting testing before objective and criteria are clear leads to unfocused work. Choosing a sample from an unvalidated report can omit transactions. Relying on a walkthrough as proof of operating effectiveness overstates what was observed. Using old reports without considering process change can make the risk assessment stale.

Another common error is treating scope as a list of everything that could be examined. Scope should be broad enough to answer the question, not unlimited. Prioritize material risks, explain exclusions, and communicate limitations.

Candidates should also avoid planning only control tests. The objective may require evaluating compliance, accuracy, data integrity, or outcomes as well as control operation. Procedures should cover the assertion the engagement will report.

A planning quality check

Before fieldwork, ask whether another competent auditor could understand the objective, boundaries, criteria, risks, controls, procedures, sample logic, and resource plan from the file. If any step relies on an unstated assumption, resolve or document it.

For each procedure, ask what result would support an effective control, what result would indicate an exception, and what alternative explanation might exist. This planning improves evidence quality and prevents changing the test after seeing the result.

Part 2 assigns half its content to Engagement Planning. Study this domain as a practical sequence: define the question, bound it, establish the benchmark, understand the area, assess risk, map controls, design the program, and resource the work.

Plan for change and uncertainty

A planning file should identify assumptions that could affect the work, such as the completeness of a system report, availability of a subject-matter expert, or whether a policy applies to a location. Build a way to test those assumptions early. If a key assumption proves false, revise scope or procedures and communicate the consequence rather than allowing an invalid plan to continue.