How to Define the Scope of an Access Review Campaign
How to Define the Scope of an Access Review Campaign

TL;DR
- Access review scope determines exactly which identities, applications, accounts, roles, and entitlements reviewers will evaluate.
- Avoid putting every user and every permission into one campaign simply because the data is available.
- Start with the control objective: privileged access, finance applications, inactive users, contractors, specific entitlements, or another defined risk.
- Verify identity matching, application ownership, entitlement quality, reviewer assignment, and exclusions before launch.
- Document why users or access were excluded. An auditor may ask about the population outside the campaign.
- SecurEnds supports campaign templates that can scope reviews by user status, applications, credentials, roles, and entitlements.
The Campaign Has 40,000 Decisions. Most of Them Do Not Need Attention.
Your IAM team launches a quarterly access review.
Every employee is included.
Every connected application is included.
Every role and entitlement is included.
Managers open the campaign and find hundreds of decisions waiting.
Many are routine.
Some permissions are poorly described.
A few users should never have entered the campaign at all.
The highest-risk access is now buried among thousands of low-value approvals.
Technically, the organization has created a comprehensive review.
Operationally, it has created reviewer fatigue.
This is why access review scope should be designed before the campaign begins.
The objective is not to make the review as large as possible. It is to identify the population that supports a specific security, compliance, or governance objective and route those decisions to people capable of making them.
Good scoping improves review quality, completion time, remediation, and audit evidence.
What Is Access Review Scope?
Access review scope defines who and what will be reviewed during an access certification campaign.
Depending on the control, scope can include:
- users
- contractors
- guest accounts
- inactive identities
- service accounts
- applications
- groups
- roles
- credentials
- individual entitlements
- privileged permissions
- specific business units
- selected risk categories
Microsoft’s current access-review model similarly allows organizations to scope reviews to selected resources and populations, including specific applications, groups, guests, everyone with access, inactive users, and particular privileged assignments.
The exact scope should come from the purpose of the review.
Do not begin with:
“What data can our tool pull?”
Begin with:
“What access decision are we trying to validate?”
Start With the Control Objective
Before selecting users or applications, write one sentence describing why the campaign exists.
For example:
Quarterly finance review:
Validate that employees with access to financially significant systems still require that access.
Privileged access review:
Validate administrator and elevated permissions across selected systems.
Contractor review:
Identify contractors whose access is no longer justified.
Inactive-user review:
Review application access associated with identities marked inactive in the system of record.
Entitlement-specific review:
Review all users holding a sensitive payment-approval permission.
A clear objective makes the remaining scoping decisions easier.
Without one, teams often create a large campaign because it feels safer to review everything.
Which Applications Should Be Included?
Not every campaign needs every application.
Choose systems based on the control you are testing.
Consider:
- business criticality
- sensitive information
- privileged access
- compliance relevance
- known access problems
- audit findings
- user population
- entitlement risk
- review frequency
A SOX-focused campaign may concentrate on specific financial applications.
A privileged-access campaign may include administrative roles across directories, cloud platforms, and infrastructure tools.
A contractor review may span applications where third-party access is common.
SecurEnds campaign templates allow organizations to select which applications enter a review and then further narrow the campaign where required.
The key question is:
Does this application’s access support the purpose of this campaign?
If not, putting it in scope may create workload without improving the control.
Which Users Should Be Included?
Once the application scope is clear, determine the identity population.
Possible populations include:
- all active employees
- inactive identities
- contractors
- partners
- administrators
- users in a department
- application-specific users
- privileged users
- service accounts
SecurEnds’ campaign-template documentation allows campaigns to distinguish active and inactive users from the system of record. It specifically describes inactive-user reviews as a way to find identities marked inactive in the source system that still retain application access.
This is useful because different populations often need different review logic.
For example, a campaign targeting inactive users may focus primarily on whether access should exist at all.
A privileged-user campaign may require deeper entitlement-level review.
Do not assume one campaign design works equally well for both.
Should You Review the Application, Credential, Role or Entitlement?
Scoping depth matters.
Consider these three reviews:
Application level:
Does Sarah still need access to the ERP system?
Role level:
Does Sarah still need the Accounts Payable Manager role?
Entitlement level:
Does Sarah still need the ability to approve vendor payments?
These are different control questions.
Application-level reviews are easier for managers but can miss excessive permissions inside the application.
Entitlement-level reviews provide greater precision but can generate large reviewer workloads.
Use the level necessary for the risk.
SecurEnds documents campaign scoping down to specific roles, credentials, and entitlements where required. Its guidance gives the example of reviewing only domain administrators for a particular application.
A practical strategy is to apply deeper review to higher-risk access rather than requiring every manager to evaluate every low-level permission.
Verify Identity Matching Before You Finalize Scope
Campaign scope is only as accurate as the identity data underneath it.
Suppose an application contains 900 accounts.
Only 850 map correctly to identities.
Launching the review without investigating the remaining 50 creates uncertainty.
Those accounts may belong to:
- former employees
- contractors
- shared identities
- service accounts
- duplicate accounts
- users with inconsistent identifiers
Before launch, check:
- matched accounts
- unmatched accounts
- inactive identities
- excluded identities
- service accounts
- duplicate credentials
SecurEnds’ application documentation distinguishes matched, excluded, deleted, purged, and service-account states and notes how those categories affect campaign participation.
Do not use campaign creation as a substitute for identity-data reconciliation.
Define Reviewers as Part of Scope
Scope is not complete until you know who will make the decision.
Different review types may require different reviewers.
Manager review
Useful when the question is whether a person needs application access for their job.
Application-owner review
Useful when the reviewer needs deeper knowledge of application roles or permissions.
Entitlement-owner review
Useful when individual permissions have distinct business ownership.
Specialized control-owner review
Appropriate for particularly sensitive or regulated access.
Microsoft’s access-review guidance similarly supports different reviewer models, including resource owners and other assigned reviewers.
Before launch, verify:
- reviewer is active
- reviewer owns the correct population
- reviewer can understand the access
- fallback or escalation path exists
- self-review conflicts are addressed
Incorrect reviewer assignment can create both campaign delays and weak decisions.
Exclusions Need Governance Too
There are legitimate reasons to exclude identities or access from a campaign.
Examples might include:
- a system account managed under another control
- an application outside the control objective
- a temporary technical population handled separately
- an access type reviewed through another campaign
But exclusions should not happen invisibly.
Document:
What was excluded?
Why was it excluded?
Who approved the exclusion?
Which control covers it instead, if applicable?
SecurEnds specifically advises that campaigns should contain users who need review and supports application-level exclusions. Its documentation also states that excluded-user lists can be exported for auditors.
That is important because an auditor may ask:
“How do you know this campaign included the complete intended population?”
The answer should include both the reviewed population and documented exclusions.
Broad Campaign or Risk-Based Campaign?
Not every campaign needs to review the entire workforce.
A risk-based approach can prioritize access that deserves greater scrutiny.
Possible criteria include:
- privileged roles
- sensitive entitlements
- inactive identities
- terminated identities
- contractor access
- high-risk applications
- access outside expected templates
- administrator groups
Microsoft’s current access-review APIs also support narrower scopes such as inactive users, guest users, specific resources, and privileged assignments.
This does not mean broad campaigns are unnecessary.
Organizations may still need comprehensive periodic reviews.
The better model is often a combination:
Broad periodic review + targeted higher-frequency reviews for higher-risk access
Use a Pre-Launch Scope Checklist
Before starting the campaign, answer these questions:
| Scope Question | Confirm Before Launch |
| What control objective does the campaign support? | Documented |
| Which applications are included? | Confirmed |
| Which identities are included? | Confirmed |
| Which roles/entitlements are included? | Confirmed |
| Are unmatched accounts resolved? | Reviewed |
| Are inactive users handled correctly? | Reviewed |
| Who owns each review? | Assigned |
| Are self-review conflicts addressed? | Confirmed |
| What is excluded? | Documented |
| Can exclusions be explained later? | Yes |
| Is remediation defined? | Yes |
| Can the campaign evidence reproduce the original scope? | Tested |
Do this before sending the first reviewer notification.
Once a campaign is live, changing scope can complicate both reviewer expectations and audit evidence.
SecurEnds’ campaign-template documentation similarly notes that template details can be modified before associated campaigns are launched, while some configuration becomes restricted after launch.
How SecurEnds Supports Access Review Scoping
SecurEnds User Access Reviews supports recurring campaigns across employees, contractors, partners, applications, credentials, and entitlements. Its production product page describes campaign-driven reviews across cloud and on-premises environments.
Its campaign templates provide more specific scoping controls.
Organizations can define:
- active or inactive user populations
- applications included in the review
- specific credentials
- roles
- entitlements
- campaign reviewers
- exclusions
SecurEnds also documents access-template-based reviews, which can help organizations evaluate access against expected access patterns rather than requiring reviewers to assess every entitlement individually.
For teams evaluating SecurEnds, use a real campaign design during the POC.
Instead of asking the vendor to create a generic review, provide:
one business objective + two applications + a defined user population + one sensitive entitlement + an exclusion + multiple reviewer types
Then confirm exactly who appears in the resulting campaign and why.
Best Practices for Defining Access Review Scope
Start with the control objective. Know what access question the review must answer.
Do not scope by connector availability alone. Governance importance should drive application selection.
Use the right review depth. Review high-risk entitlements more precisely where necessary.
Validate identities before launch. Unmatched accounts can create gaps in the review population.
Assign knowledgeable reviewers. Ownership is part of campaign scope.
Separate different populations when useful. Employees, contractors, inactive identities, and privileged users may need different campaigns.
Document exclusions. Make the population outside the review explainable.
Preserve the original scope. Audit evidence should show what reviewers were actually asked to certify.
Frequently Asked Questions
What is access review scope?
Access review scope defines the users, applications, accounts, roles, groups, or entitlements included in an access certification campaign. The scope should reflect the security or compliance objective of the review rather than simply including every available identity and permission.
Should every application be included in every access review?
No. Different campaigns may support different control objectives. A finance review might target financially significant applications, while a privileged-access review might focus on administrator roles across several systems. Broader periodic reviews can be combined with narrower risk-based campaigns.
Should access reviews be performed at application or entitlement level?
It depends on the risk. Application-level reviews answer whether someone should retain access to the system. Entitlement-level reviews examine individual permissions within that system. Higher-risk or privileged access may justify more granular review, while lower-risk access may not require the same depth.
How should inactive users be handled in an access review?
Inactive users can be reviewed as a dedicated population to identify accounts that remain active in target applications even though the authoritative identity source marks the person inactive. This can help identify stale or orphaned access requiring remediation.
Can users be excluded from an access review?
Yes, when there is a legitimate governance reason. However, exclusions should be intentional, documented, and explainable. Record why the user or account was excluded and whether another control governs the access. Exclusion records can also be useful during audit testing.
Who should define access review scope?
IAM or security teams normally coordinate campaign design, but application owners, business owners, compliance teams, and control owners should contribute where relevant. The people defining scope need to understand both the technical access model and the control objective the campaign is intended to support.
Review the Right Access, Not Simply More Access
A larger campaign is not automatically a stronger campaign.
The best access review scope makes the control clear.
You know which identities are being evaluated.
You know which applications matter.
You know how deeply permissions need to be reviewed.
You know who owns each decision.
And you can explain every exclusion.
That gives reviewers a manageable population and gives auditors a defensible record of what the campaign was designed to test.
Before launching your next certification, define the scope first.
Then collect the access, route the right decisions, remediate findings, and preserve evidence around that exact population.
If your team needs more control over campaign design, explore SecurEnds User Access Reviews and evaluate how templates, application selection, identity status, credential and entitlement filtering, reviewer assignment, and exclusions can support your review program.