Skip to main content
Identity Authority
Category: Governance & Compliance

Audit Scope

Also known as: Scope of an Audit, Audit Engagement Scope
Simply put

Audit scope is the defined set of boundaries that determines what an audit will and will not examine. It specifies which systems, processes, policies, and time periods are covered, so everyone involved understands the limits and focus of the review before the audit begins.

Formal definition

In information security and compliance contexts, audit scope delineates the boundaries, extent, and focus of an audit engagement, specifying which systems, services, processes, policies, and reporting periods are subject to examination and, by implication, which are excluded. It establishes how deeply the audit is performed and is typically framed against a chosen reporting framework or compliance standard. In IAM-relevant audits (for example, access reviews and certifications within an IGA program, or attestation engagements such as SOC assessments), scope determines which identity stores, access-control systems, and control activities fall within the assessed boundary. The precise systems, control objectives, and periods included vary by framework, engagement type, and deployment context; details of specific frameworks and their control requirements are out of scope for this definition.

Why it matters

Audit scope is the foundation on which an entire audit engagement rests, because it determines what will and will not be examined before any evidence is gathered. In IAM-relevant audits, such as access reviews and certifications within an IGA program, or attestation engagements like SOC assessments, an imprecise or overly narrow scope can leave critical identity stores, access-control systems, or control activities unexamined, creating a false sense of assurance. Conversely, an unnecessarily broad scope can consume resources and delay findings without improving the quality of the assurance obtained.

Because scope defines the boundaries, extent, and focus of the review, it directly shapes the conclusions stakeholders can draw from an audit report. A control that appears to have passed may simply have fallen outside the assessed boundary, so readers of an attestation report must understand which systems, services, and periods were covered before relying on the results. Clarifying these limits up front prevents misunderstanding among auditors, control owners, and the parties who consume the resulting report.

The specific systems, control objectives, and reporting periods that belong within scope vary by framework, engagement type, and deployment context. For this reason, scoping decisions are typically documented and agreed before fieldwork begins, and the details of any particular framework's control requirements are treated separately from the general concept of scope itself.

Who it's relevant to

Identity Governance Leads
For those running an IGA program, audit scope determines which identity stores, access-control systems, and control activities, such as access reviews and certifications, fall within an assessed boundary. Understanding scope helps ensure that governance controls intended to be evaluated are actually included rather than inadvertently excluded.
Compliance Officers
Compliance officers rely on well-defined scope to frame an engagement against a chosen reporting framework or standard. Because scope establishes what is and is not examined, it shapes the assurance an attestation report can provide and the limits stakeholders must recognize when relying on it.
Security Architects and IAM Engineers
Architects and engineers who operate identity systems need to know which systems, services, and periods will be evaluated so they can prepare relevant evidence. Scope decisions vary by deployment context, so their input helps ensure that the systems in scope accurately reflect the environment under review.
System Administrators
Administrators responsible for the systems under examination benefit from clear scope boundaries because they clarify which systems and reporting periods require evidence collection and control demonstration, and which fall outside the engagement.

Inside Audit Scope

In-scope systems and applications
The specific identity stores, directories, applications, and infrastructure components that the audit will examine, typically enumerated explicitly so that boundaries are unambiguous. What falls outside these boundaries should be marked as out of scope.
Covered identity populations
The categories of principals under review, which may include workforce users, privileged accounts, service accounts, and non-human identities. Different populations often carry different control expectations.
Governance versus enforcement concerns
A distinction between identity governance and administration (IGA) activities such as provisioning, access reviews, certification, and segregation of duties, and runtime enforcement activities such as PDP/PEP/PIP behavior and token validation. Audit scope should state which of these it addresses.
Access control model coverage
Clarification of which access control models are in scope for review, for example RBAC role assignments, ABAC attribute policies, PBAC policy definitions, or ReBAC relationships, since each is evaluated differently.
Time period and evidence sources
The window the audit covers and the artifacts examined, such as access certification records, provisioning logs, authentication logs, and token issuance records. The period typically depends on the audit objective and applicable framework.
Applicable controls and criteria
The control objectives, regulatory requirements, or framework mappings against which in-scope systems are assessed. These criteria shape what evidence is relevant and what constitutes a finding.

Common questions

Answers to the questions practitioners most commonly ask about Audit Scope.

Does defining an audit scope for identity systems mean reviewing every authentication and authorization event across the environment?
No. Audit scope is a deliberate boundary that determines which systems, identities, controls, and time periods are examined. It is common to conflate broad logging coverage with audit scope, but the two are distinct. Collecting authentication and authorization events across an environment is a data-availability matter, whereas audit scope defines which of those systems and controls will actually be evaluated against a given objective or framework. In most deployments, scope is narrowed to the systems relevant to the audit's stated purpose, and events outside that boundary may be logged but remain out of scope for the examination.
Is audit scope the same as the set of access controls being enforced at runtime?
No. Audit scope is a governance and examination concern, not a runtime enforcement concern. It describes what an assessment will cover, whereas runtime enforcement components such as a PDP, PEP, or PIP make and apply access decisions as they happen. An audit may include enforcement points within its scope in order to evaluate whether they operate as intended, but the scope itself does not enforce anything. Blurring these leads to the mistaken assumption that everything a PEP protects is automatically part of an audit, when in fact scope must be defined separately and may include or exclude enforcement points depending on the audit objective.
How do you decide which identity systems and controls belong inside an audit scope?
Scope is typically derived from the audit's objective and any governing framework or regulatory requirement, then mapped to the systems, applications, and identity stores that materially affect that objective. In practice this involves identifying which directories, provisioning flows, access review processes, and enforcement points touch the assets under examination. Depending on configuration and the framework applied, teams often document inclusion and exclusion criteria explicitly so that boundaries are defensible. Systems with no bearing on the stated objective are generally excluded and noted as out of scope.
How should IGA processes such as provisioning and access certification be represented in an audit scope?
Identity governance and administration processes are usually scoped separately from runtime enforcement, because they concern lifecycle management rather than real-time access decisions. When these are in scope, the audit typically examines provisioning and deprovisioning workflows, access review and certification records, and segregation-of-duties controls for the in-scope systems. It is common to state the time period covered, since certifications and reviews occur on a defined cadence, and to identify which populations of identities and entitlements the scope includes.
What should be documented when defining an audit scope to make it auditable and repeatable?
In most deployments, a scope statement records the objective, the frameworks or requirements being assessed against, the specific systems and identity repositories included, the identity populations covered, the time period, and explicit exclusions. Documenting boundaries between what is examined and what is merely logged helps prevent later ambiguity. Recording rationale for exclusions is also common practice, so that subsequent reviewers can understand why certain systems or controls were left out and reassess that decision if conditions change.
How do you keep an audit scope accurate as the identity environment changes over time?
Because systems, integrations, and identity stores change, scope is typically reviewed and reconfirmed at the start of each audit cycle rather than assumed to be static. In practice this means reconciling the documented scope against the current inventory of directories, provisioning connections, and enforcement points, and updating inclusions or exclusions accordingly. Depending on the governance model and framework, changes to the environment such as newly onboarded applications or altered access flows may warrant expanding or re-baselining the scope so the examination continues to reflect the systems that matter to its objective.

Common misconceptions

Audit scope covers authentication and authorization as a single control area.
Authentication (verifying who a principal is) and authorization (determining what a principal may do) are distinct steps, and identification is a separate step again. A well-defined audit scope typically treats these as separate control areas because they rely on different mechanisms and evidence.
If identity lifecycle management is in scope, runtime access enforcement is automatically in scope too.
IGA concerns such as provisioning, access reviews, certification, and segregation of duties are separate from runtime enforcement concerns such as PDP, PEP, PIP, and token validation. An audit may include one without the other, so scope should state each explicitly.
Naming the applications in scope is sufficient to define the audit boundary.
In most deployments a complete scope also specifies the identity populations, the control models under review, the time period, and the evidence sources. Depending on configuration, omitting any of these can leave the boundary ambiguous and produce inconsistent findings.

Best practices

Enumerate in-scope systems, identity populations, and control areas explicitly, and separately state what is out of scope so boundaries cannot be misread.
Distinguish governance activities (provisioning, access reviews, certification, segregation of duties) from runtime enforcement (PDP, PEP, PIP, token validation) in the scope statement, and confirm which are being audited.
Specify which access control models are covered (for example RBAC, ABAC, PBAC, or ReBAC), since each requires different evidence and evaluation techniques.
Define the audit time period and the evidence sources up front, and confirm those sources are retained and accessible for the chosen window.
Treat identification, authentication, and authorization as separate steps when scoping access flows, so that gaps in one are not masked by controls in another.
Map scope to the applicable control criteria or framework, and use qualified language for anything that varies by vendor, profile, or configuration rather than asserting fixed behavior.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide