Audit Objectives, Scope, and the Audit Program

Planning one audit

The annual plan says which areas get audited this year. Before each audit starts, the auditor plans it in detail.

Objectives: what must the audit conclude?

Objectives are questions the audit must answer. They come from the risks found in planning, and they’re agreed before the tests are designed. Everything else (scope, tests, sample sizes, evidence) is chosen because it helps answer them.

Good objectives are specific:

• Are changes to the payroll system authorised, tested and approved before going live?
• Can only authorised staff access customer data in the CRM?
• Can critical systems be recovered within the agreed recovery times?

“Review payroll IT” is not an objective. Review it for what? Nobody could say when the audit is finished.

Scope: where are the boundaries?

Scope says what’s in and what’s out:

• which systems and infrastructure
• which business processes and locations
• which time period (for example, the last 12 months)
• what’s deliberately excluded, and why

The auditor sets the scope, based on risk. Exclusions are documented and justified.

The audit program: how will we test it?

The audit program is the step-by-step list of tests. It:

• links every test to an objective
• says what evidence is needed
• assigns who does what, and by when
• becomes the record of work performed, which supervisors review

Standard programs or last year’s program are good starting points, but they must be tailored to this year’s risks and systems. Rolling last year’s program forward without thinking is a weakness. And the program can change during the audit if new risks or failures turn up.

Resources and timing

The auditor also plans:

• the skills needed, including outside experts if the team lacks them
• timing, so key people and systems are available
• communication: an opening meeting, status updates, who gets the report
• requesting access and data in advance

When someone blocks the scope

If access is refused, records are missing or time is cut, the auditor:

1. tries to resolve it with the auditee
2. escalates, using the charter’s authority, to audit management and then the audit committee
3. looks for alternative procedures that give the same assurance
4. if it still can’t be resolved, reports the limitation and how it affects the conclusion

Example. Halfway through a cloud security review, the provider refuses to share configuration exports. The auditor asks for its SOC 2 report as alternative evidence. It covers only part of the scope, so the final report states that no conclusion could be reached on logging settings.

How the exam asks about it

In short

• Audit objectives say what the audit must conclude. They're set first, before scope, tests or sample sizes.
• Scope sets the boundaries: which systems, processes, locations and time period.
• The audit program is the step-by-step list of tests that meet the objectives. It's also the record of work done.
• Programs are tailored to the current risks; copying last year's without review is a weakness.
• Planning also covers people, skills, experts, timing and communication with the auditee.
• If the scope is restricted and it can't be resolved, the limitation must be reported.

Exam traps

• Objectives come first. Tests are chosen to meet the objectives, not the other way round.
• A generic program used without tailoring to the area's risks is a weakness.
• Management restricting the scope doesn't make the restriction acceptable. Report it.
• The auditor sets the scope, based on risk, not on what the auditee is comfortable with.

Slides

Click the slide and use the arrow keys. F toggles full screen.