ISACA Audit Planning: Risk, Scope, Evidence, and Sampling

Information-systems audit planning is the discipline of turning a broad concern into a defensible examination. The auditor has to know what objective is being assessed, which risks make the work important, what criteria define acceptable control, what evidence can support a conclusion, and how much testing is enough. Weak planning creates one of two failures: an audit that collects large amounts of data without answering a clear question, or an audit that reaches a strong-sounding conclusion from evidence that was too narrow.

The direct ISACA CISA target is the relevant credential destination. The current CISA outline gives the Information Systems Auditing Process domain 18% and explicitly includes risk-based planning, controls, testing and sampling, evidence collection, analytics, reporting, and follow-up. Those are connected activities, not isolated exam terms.

Begin with the audit objective and decision it must support

An objective should describe what the audit is trying to determine. “Review cloud security” is too broad. “Determine whether privileged access to production cloud resources is approved, least-privileged, monitored, and periodically recertified” provides a basis for criteria, scope, populations, tests, and evidence.

Ask who will use the conclusion and what action might follow. Management may need assurance before a regulatory review, the board may need evidence about a high-risk process, or an operational owner may need validation after remediation. The intended decision helps determine the level of evidence and precision the audit requires.

Use risk to build and prioritize the audit universe

The audit universe is the population of processes, systems, entities, locations, and technology areas that could be audited. Risk-based planning prioritizes that universe using factors such as business criticality, data sensitivity, regulatory obligations, change, prior findings, incidents, third-party dependence, financial impact, and management concern.

Risk scoring should support judgment rather than replace it. A new technology may deserve attention despite limited incident history. A stable system may remain high risk because failure consequences are severe. Document the rationale for inclusion and exclusion so later reviewers understand why scarce audit resources were allocated the way they were.

Translate scope into explicit boundaries

Scope defines what is inside the audit and, just as importantly, what is outside. Specify business units, systems, interfaces, locations, time period, control processes, third parties, and relevant technologies. Ambiguous boundaries lead to evidence gaps and late scope disputes.

When a system depends on services outside the initial boundary, decide whether those dependencies must be tested or treated as assumptions. For example, an access-control audit may depend on HR termination data, identity synchronization, privileged-access systems, and cloud audit logs. If those inputs are not reliable, the audit may need to expand or qualify its conclusion.

Choose criteria before choosing tests

Criteria are the standards against which evidence is evaluated. They may come from policy, contracts, regulations, frameworks, technical baselines, or management-approved control design. Without clear criteria, testing can show what exists but not whether it is acceptable.

Resolve conflicting criteria during planning. A local procedure may allow behavior that a regulatory requirement prohibits, or a technical standard may be stricter than the corporate policy. Document which criterion governs the audit conclusion and why. That prevents disputes after findings have already been drafted.

Understand the control before deciding how to test it

Determine the control objective, owner, frequency, inputs, outputs, system dependencies, and evidence produced when the control operates. Separate design adequacy from operating effectiveness. A well-designed approval workflow can still fail if approvers routinely bypass it; a consistently performed control can still be poorly designed if it does not address the underlying risk.

Walkthroughs help auditors understand the process and identify where evidence is generated. They are not automatically sufficient proof of ongoing effectiveness. Use the walkthrough to refine the test population, sampling approach, data request, and expected exceptions.

Plan evidence for sufficiency and reliability

Evidence should be sufficient to support the conclusion and reliable enough to trust. Direct observation, system-generated records, independent confirmations, configuration exports, logs, tickets, approvals, and reconciliations have different strengths. Evidence supplied manually by the control owner may need corroboration, especially when the same person could alter the underlying record.

Plan how evidence will be preserved and traced to the tested item. If a report is used to select a sample, validate report completeness and parameters. If screenshots are used, determine whether they prove a point in time or the whole audit period. Audit planning includes the evidence chain, not just the request list.

Sampling should match the population and control behavior

Sampling is useful when testing every item is unnecessary or impractical. The method depends on the objective, population characteristics, control frequency, expected exception rate, and assurance required. Random or statistical approaches support some conclusions; judgmental selections are useful for high-risk or unusual items but cannot always be generalized to the full population.

Define the population before selecting the sample. Missing or duplicate population records undermine the test. Also decide what happens when exceptions are found: expand the sample, perform targeted testing, investigate root cause, or treat the exception as evidence of a broader control failure. The response should not be improvised after the result is known.

Data analytics can expand coverage but needs validation

Audit analytics can examine full populations for duplicates, unusual access, segregation conflicts, timing anomalies, threshold breaches, or missing approvals. Full-population analysis can improve coverage, but it does not eliminate evidence-quality problems. A query over incomplete or misunderstood data produces precise-looking but unreliable conclusions.

Validate field definitions, data lineage, extraction parameters, time zones, joins, exclusions, and transformations. Retain the query or analytic logic so another reviewer can reproduce the result. Analytics is strongest when it makes the audit test more transparent rather than creating an opaque scoring model.

Plan resources and timing around the real control cycle

An annual control cannot be tested effectively before it occurs, and a month-end reconciliation may require evidence that is not available in the first week of the period. Map fieldwork to the control calendar, system changes, business peaks, vacations, and planned migrations. Poor timing can force avoidable scope limitations.

Match audit skills to the technology as well. Cloud identity, network security, AI governance, ERP access, or application code may require specialists. Decide early whether internal experts, external support, or data-analysis capabilities are needed so the audit does not discover a skills gap after evidence collection has started.

Audit owners need access to evidence, process knowledge, and explanations from management, but the audit plan must preserve independent judgment. Agree communication cadence, data-request channels, escalation for delays, and how factual disagreements will be resolved. Early transparency reduces friction without letting the control owner determine the conclusion.

Discuss scope changes formally. New evidence may reveal a higher-risk area or show that an assumption was wrong. Record why the scope changed, who approved resource impacts, and whether the revised work still supports the original objective. Informal expansion can consume the schedule and weaken the final report.

Evidence may be unavailable because of retention limits, system migration, third-party restrictions, or failed logging. Planning should identify likely limitations and possible alternatives: independent confirmations, backup records, configuration history, ticket systems, sampled endpoints, or compensating evidence.

If the limitation cannot be overcome, determine how it affects the conclusion. A qualified conclusion is stronger than pretending the missing evidence does not matter. Document the limitation early so stakeholders understand what assurance the audit can and cannot provide. Reporting considerations should influence planning.

The final report needs a clear line from objective to criteria, evidence, finding, risk, cause, and recommendation. If the planned work cannot support that line, fix the plan before fieldwork. Decide how severity will be determined, what management response is expected, and what evidence will be required to close findings.

Follow-up is also part of the audit lifecycle. A recommendation is not complete because management accepts it. Plan how remediation will be verified and when risk acceptance requires escalation. This keeps findings from becoming permanent entries that never change the control environment. A good plan makes the audit conclusion reproducible.

The strongest audit plan allows another competent auditor to understand why the subject was selected, what the audit intended to determine, how scope and criteria were defined, why the testing method was appropriate, and what evidence would support or contradict the conclusion. That traceability is the practical meaning of disciplined audit planning.

CISA candidates should therefore connect planning, testing, evidence, analytics, reporting, and follow-up as one chain. Risk determines attention; objective and criteria determine the question; scope and sampling determine coverage; evidence supports the conclusion; and follow-up tests whether the control environment actually improved.

Quality review should be planned, not added at the end.

Audit work benefits from review checkpoints before the final report. A reviewer can challenge whether scope still matches the objective, whether evidence supports the emerging conclusion, whether exceptions are evaluated consistently, and whether sampling decisions remain defensible. Early review is cheaper than discovering a methodological gap after fieldwork closes.

Plan what work papers, analytic logic, evidence references, and supervisory sign-offs are required. A well-organized record lets another auditor reproduce the reasoning and reduces the risk that a valid finding is weakened by poor documentation.

Planning should include criteria for using work performed by other assurance providers. Internal audit, external audit, compliance, security testing, quality teams, and regulators may have examined overlapping controls. Reuse can reduce duplication, but only when the other work is sufficiently independent, competent, recent, and documented for the audit objective. Record what can be relied upon and what still requires direct testing.

Technology change during fieldwork also needs a rule. If a system is migrated, a control is redesigned, or a major incident changes the risk environment, determine whether the original population remains relevant. Update scope deliberately instead of mixing old and new control states into one conclusion without explanation.