Audit Planning: Objectives, Scope, and Criteria

Lesson 2 covered the program level. This lesson zooms into a single audit's own planning — specifically, the three parameters that define what an audit is actually going to check, and why getting any one of them vague or wrong undermines everything that follows.

The three defining parameters

Every audit — first-, second-, or third-party — needs three things explicitly defined before it begins:

1. Objectives — why the audit is happening. Examples: determining conformity for certification, verifying corrective actions from a prior audit closed effectively, or assessing a supplier's security posture before contract renewal.
2. Scope — what is covered: which sites, business units, systems, processes, and time period. Foundation's own scope-statement lesson covers the ISMS's own scope; an audit's scope is a related but distinct concept — it can be narrower than the full ISMS scope (e.g., auditing only the incident management process this cycle) or match it exactly.
3. Criteria — the specific requirements the audit findings will be judged against: the relevant clauses of ISO/IEC 27001, applicable Annex A controls per the organization's own SoA (Implementer, lesson on the SoA), plus any additional criteria like internal policies, contractual requirements, or applicable law.

Why criteria can't just be "the standard"

A common planning mistake: writing "ISO/IEC 27001" as the criteria and considering that sufficient. This misses that the specific, applicable requirements differ by organization — an SoA that excludes a control (legitimately, as covered in Foundation) means that control isn't a valid audit criterion for this organization, while a client's own additional internal policy might genuinely be a valid, explicitly agreed-upon criterion beyond the standard itself. An auditor who doesn't establish precise criteria before starting risks two failure modes: auditing against a control the organization legitimately excluded (an invalid finding), or missing that a stricter internal policy commitment was also a valid thing to check against.

Setting an appropriately bounded scope

Scope should be tightly matched to the objective — not defaulted to "everything," and not narrowed so much that the objective can't actually be met. A second-party supplier audit whose objective is "assess security of the specific service we're contracting" doesn't need to scope in the supplier's entire unrelated business lines; but a certification audit whose objective is "verify the client's ISMS meets all applicable clauses and their own SoA" cannot legitimately narrow scope to only the parts the client would prefer to show off. Scope decisions should trace back to the stated objective, the same discipline the SoA lesson in Implementer applied to control applicability decisions.

Selecting the audit team

Once objectives, scope, and criteria are set, the program manager (Lesson 2) selects an audit team whose collective competence matches what this specific audit needs — for example, an audit covering a cloud-hosted SaaS company's ISMS needs at least one team member with real cloud infrastructure competence, not just generic ISMS auditing experience. Team selection also has to respect the independence principle from Lesson 1: no team member should be assigned to audit an area they have a conflict of interest in, regardless of how well their technical competence otherwise fits.

What a planning gap looks like in practice

The most common real-world planning failure isn't a total absence of objectives, scope, or criteria — it's vagueness in one of them that only becomes a problem once the audit is underway. "Objective: check if they're doing OK" isn't a real objective. "Scope: the company" isn't a real scope for an organization with multiple business units and locations. "Criteria: ISO 27001" isn't real criteria without reference to the organization's own SoA and any additional agreed requirements. Each of these vague versions looks superficially fine on a planning document, but leaves the audit team without a clear, defensible basis for their eventual conclusions.