Audit Planning and Scope Definition

Audit objectives are the questions the audit is designed to answer. They must be stated precisely enough to determine what evidence is required and what a finding means. A vague objective such as "assess information security" does not meet this standard. A specific objective such as "determine whether user access provisioning and de-provisioning controls comply with the requirements of ISO/IEC 27001:2022 Annex A.5.18 and the organization's access control policy" is actionable: it identifies the criterion (Annex A.5.18 and the internal policy), the control area (access provisioning and de-provisioning), and implicitly the evidence required (access request records, joiners/movers/leavers process documentation, system access logs, interview notes).

Objectives are normally derived from one of three sources. First, regulatory or certification requirements mandate specific objectives: a PCI-DSS assessment must address all requirements in the current version of the standard; an ISO 27001 certification audit must verify conformance with all Annex A controls applicable within the defined ISMS scope. Second, risk assessments identify high-priority threats and the controls that address them, generating risk-driven objectives. Third, management or the board may commission objectives based on specific concerns, a recent incident, a new business activity, or a customer requirement.

Scope definition requires understanding the environment before fieldwork begins. The auditor needs to know what assets exist, which are within scope, what controls are supposed to be in place, and what risks the organization has already assessed. Without these inputs, the auditor is setting scope based on assumptions rather than evidence. The standard inputs are: the asset register (or equivalent inventory), the risk register, previous audit findings, the organization's control framework and security policies, and any regulatory or contractual requirements that apply.

The asset register is the primary tool for defining what is in scope. It should list information assets (data sets, applications, services) and supporting assets (servers, networks, facilities, third-party services) with their owners, classifications, and dependencies. An incomplete asset register is itself a finding: assets that are not inventoried are not managed, and controls applied to a known population cannot protect assets outside it. The auditor should cross-reference the register against network diagrams, cloud tenancy configurations, and procurement records to identify assets that may be missing.

The risk register identifies the threats and vulnerabilities the organization has already assessed, and the controls in place or planned to address them. A well-maintained risk register allows the auditor to focus testing on controls that address high-residual-risk scenarios rather than spreading effort uniformly across all controls. Where the risk register is absent or out of date, this too is a finding: risk assessment is a foundational ISMS requirement under ISO 27001 clause 6.1 and a core element of frameworks such as the NIST Cybersecurity Framework.

The two main approaches to scope definition are compliance-based and risk-based. In practice, most audits mix both, but the primary driver determines which controls receive mandatory coverage and which are selected by judgment.

Compliance-based scoping is non-negotiable when the audit objective is to satisfy a regulator or certifier. GDPR supervisory authorities in the EU, the Information Commissioner's Office in the UK, the Office for Civil Rights enforcing HIPAA in the US, and India's Data Protection Board under the Digital Personal Data Protection Act 2023 all expect organizations to demonstrate compliance against specified requirements. The audit scope must cover those requirements in full. A risk-based decision to skip a mandatory control because its residual risk appears low will not satisfy a regulatory inspection.

Risk-based scoping is appropriate for internal audit programmes where the audit function must allocate finite resources across a broad control environment. The internal auditor prioritizes areas of higher residual risk or past failure. This approach requires that the risk assessment feeding the scope decision is current, credible, and covers the relevant threat environment. An internal audit scoped against a three-year-old risk assessment may miss controls that have become critical because of changes in the business or the threat environment. Review Risk Assessment Methodologies for the principal frameworks used as inputs to risk-based scoping.

Before the audit plan can be finalized, the auditor needs a working understanding of the environment: its architecture, its key processes, the technologies in use, and the control points. This understanding is built through a combination of document review and preliminary interviews. It is not a substitute for fieldwork, but it prevents the auditor from producing an audit plan that is structurally incompatible with the actual environment.

The preliminary review typically covers: system architecture diagrams, network topology, data flow diagrams (particularly for data subject to regulatory protection, such as personal data under GDPR or cardholder data under PCI-DSS), the organization's own control documentation (policies, procedures, control matrices), previous audit reports and management responses, and any relevant incident or exception records. For a cloud-hosted environment, the auditor also needs the cloud tenancy configuration, the shared responsibility matrix for the cloud provider in use, and the organization's cloud security baseline.

Not all controls in scope receive the same depth of testing. The audit plan must prioritize based on two dimensions: the criticality of the control to the audit objective, and the assessed likelihood that the control may be ineffective. A control that is critical to the objective and has a history of failure or exception gets the most testing. A control that is peripheral to the objective and has a clean track record gets lighter coverage.

Key controls are typically identified using a control mapping exercise. The auditor maps the audit objectives and criteria (the standard, regulation, or policy) against the controls the organization says it has in place. This produces a list of required controls and indicates which ones address the highest-risk scenarios. For a certification audit, the control framework itself (such as the 93 controls in ISO 27001:2022 Annex A) provides the mapping structure. For a risk-based audit, the organization's risk treatment plan and control register provide it.

The test approach for each key control must be specified in the audit plan. Three testing techniques are commonly used: inquiry (interviews with control owners and operators), inspection (review of documentation, configurations, logs, and records), and observation (watching a control operate in real time). For automated controls, technical testing (vulnerability scanning, configuration review, log analysis) replaces or supplements observation. The plan specifies which technique applies to each control and what the evidence of effectiveness looks like.

The audit plan is the document that operationalizes everything decided in the planning phase. It must be detailed enough to guide fieldwork without requiring constant re-planning, and flexible enough to accommodate findings that redirect the investigation. A plan that is too rigid causes auditors to miss significant findings because the evidence trail leads outside the documented steps; a plan that is too vague provides no structure and makes findings hard to defend.

A complete audit plan contains: the audit objectives and criteria, the scope statement (systems, processes, locations, and time period), the list of key controls to be tested with their test approaches, the evidence collection methods for each test, the assignment of tests to individual auditors, the timeline with milestones, the reporting schedule and format, and the escalation procedure for significant findings identified during fieldwork. The plan is reviewed and accepted by audit management and by the auditee's management before fieldwork begins. Changes to scope during fieldwork require formal amendment of the plan and sign-off by the same parties.