4.1 Audit Objectives, Scope, and Criteria Establishment

4.1 Audit Objectives, Scope, and Criteria Establishment

Under ISO 19011, Guidelines for auditing management systems, every audit begins with three linked decisions: what the audit is trying to achieve (objectives), which parts of the management system and organization will be examined (scope), and which requirements will be used as the reference for judging conformity (criteria). For an Information Security Management System (ISMS) audit against ISO/IEC 27001, these decisions are not administrative paperwork—they determine sampling intensity, team competence needs, time allocation, and whether findings will be relevant to certification or improvement.

This section explains how a CQI IRCA ISMS Lead Auditor establishes and documents objectives, scope, and criteria so that planning remains coherent when the Statement of Applicability (SoA), cloud services, multi-site operations, and regulatory obligations enter the picture.

---

Why Objectives Come First (ISO 19011 Logic)

ISO 19011 expects the audit client (the party requesting the audit—often management for an internal audit, or the organization contracting a certification body for a third-party audit) to establish audit objectives. The lead auditor then ensures those objectives are achievable given available time, access, and competence.

Objectives answer the question: Why are we auditing? Typical ISMS audit objectives include:

• Determining the extent of conformity of the ISMS (or defined parts of it) with agreed audit criteria
• Evaluating whether the ISMS is capable of ensuring the organization meets applicable statutory, regulatory, and contractual information security obligations
• Evaluating effectiveness of the ISMS in achieving its stated information security objectives and treating risks to confidentiality, integrity, and availability
• Identifying opportunities for improvement of the ISMS
• For certification contexts: supporting a certification decision for a defined certification scope (initial, surveillance, or recertification)

Vague objectives such as "check security" produce unfocused plans. Precise objectives such as "evaluate conformity of the customer-data processing ISMS to ISO/IEC 27001:2022 requirements and the organization's SoA controls applicable to the SaaS platform" allow the team to design interviews, sampling, and technical verification that actually serve the purpose.

Lead auditor responsibility: confirm that objectives are documented, communicated to the auditee, and used as the starting point for scope and criteria—not rewritten ad hoc during fieldwork without client approval.

---

Defining Audit Scope: Boundaries That Can Be Audited

Audit scope defines the extent and boundaries of the audit: physical locations, organizational units, activities and processes, and the period covered. For ISO/IEC 27001, scope has an extra layer of meaning because the organization already defines an ISMS scope under Clause 4.3. The audit scope must be clear relative to that ISMS scope.

Aligning Audit Scope with ISMS Scope

If the organization's ISMS scope statement is ambiguous ("all IT systems" without naming business units or locations), the lead auditor should treat that ambiguity as a planning risk: clarify boundaries with the client before fieldwork, because auditors cannot fairly judge conformity against an unbounded system.

Dimensions of Scope for ISMS Audits

Lead auditors should describe scope along several dimensions:

1. Organizational — business units, subsidiaries, shared service centers, outsourced functions under the organization's control or influence
2. Physical / geographic — offices, data centers, warehouses with information processing, remote-work arrangements to the extent they affect the ISMS
3. Process and activity — e.g., software development lifecycle, incident management, supplier management, HR onboarding/offboarding
4. Technology and information assets — applications, networks, endpoints, cryptographic services, and cloud workloads in scope
5. Temporal — the period for which evidence is sampled (often since the last audit for surveillance, or a defined look-back for internal audits)

Scope creep occurs when fieldwork expands beyond documented boundaries without approved change. Poor scope wording invites creep ("review cloud security" without naming providers, accounts, or regions). Good scope wording enables disciplined sampling.

Interfaces, Outsourcing, and "Shared Responsibility"

ISMS audits frequently touch suppliers and cloud providers. Planning must distinguish:

• What the organization controls directly (and must evidence)
• What is outsourced but still within the ISMS because the organization retains accountability for information security (ISO/IEC 27001 supplier and control themes in the SoA)
• What is outside the audit scope entirely (e.g., a group company with a separate ISMS certificate)

The lead auditor does not "audit the cloud provider's entire global estate" merely because the auditee uses a hyperscaler. Instead, the plan focuses on the auditee's control of its configuration, identity, logging, contractual requirements, and monitoring—unless the certification scope and criteria explicitly include other arrangements.

---

Establishing Audit Criteria: The Benchmarks

Audit criteria are the set of policies, procedures, or requirements used as a reference against which objective evidence is compared. For an ISMS certification or competence-based ISMS audit, criteria typically include:

• ISO/IEC 27001 requirements applicable to the audit type (Clauses 4–10 management system requirements, and control expectations as applicable through the organization's risk treatment and SoA)
• The organization's own ISMS documentation — information security policy, risk assessment and treatment methodology, risk treatment plan, SoA, procedures, and records required by the system
• Applicable legal, regulatory, and contractual requirements that the organization has identified as relevant to its ISMS context (for example sector rules or privacy obligations)—auditors evaluate whether the ISMS addresses what the organization claims is applicable, not invent a legal opinion as counsel
• Selected external control frameworks only where the organization has adopted them through risk treatment and the SoA (for example mapping NIST CSF practices or ISO/IEC 27002 guidance into applicable controls)

The Statement of Applicability (SoA) as Criteria Glue

The SoA is central to ISMS audit criteria. It identifies which Annex A controls (and any additional controls) are applicable, justifies exclusions, and states implementation status. During planning:

• Use the SoA to decide which control themes require deeper sampling
• Treat applicable controls that the organization claims as implemented as part of the criteria for conformity evaluation
• Ensure exclusions have documented, risk-based justification that can be tested
• Remember ISO/IEC 27002 provides implementation guidance; it is not automatically a set of mandatory audit criteria unless the organization's ISMS/SoA makes specific 27002-aligned practices binding

Criteria Must Fit Objectives and Scope

If the objective is limited to "evaluate the design of the risk assessment process," criteria may emphasize ISO/IEC 27001 Clauses 6.1.2 and related documented information, with less depth on every Annex A control. If the objective is Stage 2 certification readiness across the full ISMS, criteria broaden accordingly. Changing scope without revisiting criteria creates false confidence (sampling the wrong requirements) or unfair findings (judging areas never declared in scope).

---

Interdependence and Controlled Change

Objectives, scope, and criteria are interdependent:

• Objectives determine how wide and deep the scope must be and which criteria matter
• Scope constrains what evidence can be gathered and therefore what objectives are realistic
• Criteria define the judgment standard; without agreed criteria, "nonconformity" has no reference

ISO 19011 expects that if objectives, scope, or criteria change during the audit, the change is approved as appropriate and communicated to relevant parties (typically the audit client and auditee). Mid-audit "we will also certify the new acquisition" without re-planning competence, time, and SoA coverage is a planning failure, not agility.

Practical Documentation Outputs

Before detailed scheduling, the lead auditor should ensure the following are clear in the audit program records and/or audit plan inputs:

• Stated objectives in language the auditee understands
• Scope boundaries (in/out list for sites, processes, systems)
• Criteria list (ISO/IEC 27001 edition, key documented information, SoA version/date, relevant external obligations as identified by the organization)
• Known constraints (language, secure-area access, remote vs on-site, confidentiality agreements)

Clear definition of the why, what/where, and against what is the foundation for risk-based planning, team selection, and credible findings. Without it, even skilled auditors produce inconsistent results.