1. Purpose
The Periodic Access Review Template is used to formally review user, privileged, contractor, third-party, service, application, cloud, and system access at defined intervals.
The purpose is to confirm that access:
- Remains authorized
- Is still required for business purposes
- Matches the user’s current role
- Follows least privilege
- Does not create unacceptable segregation-of-duties conflicts
- Is appropriately protected
- Has not remained active after a user or engagement has ended
- Is correctly recorded in the Access Rights Register
Core Principle
Collect → Reconcile → Validate → Review → Correct → Verify → Record
2. Review Information
| Field | Details |
|---|---|
| Review ID | |
| Review Period | |
| Review Date | |
| Review Type | User / Privileged / Third Party / Service / Application / Cloud |
| Business Unit | |
| System/Application | |
| Environment | Production / Development / Test / All |
| Reviewer | |
| Review Owner | |
| System Owner | |
| Data Owner | |
| Security/ISMS Reviewer | |
| Previous Review ID | |
| Evidence Repository | |
| Review Status | Open / In Progress / Completed |
3. Review Scope
Clearly define what is included in the review.
Users
☐ Employees
☐ Contractors
☐ Consultants
☐ Interns
☐ Temporary Workers
☐ Third Parties
Access Types
☐ Standard User Access
☐ Privileged Access
☐ Production Access
☐ Cloud Access
☐ Database Access
☐ Source-Code Access
☐ SaaS Access
☐ VPN Access
☐ Customer-System Access
☐ Service/Application Access
☐ Emergency/Break-Glass Access
Systems Reviewed
| System/Application | Environment | Owner | Population | Included |
|---|---|---|---|---|
| Yes / No |
4. Review Objectives
The reviewer should determine whether:
- Every reviewed identity is valid.
- Every access right has a legitimate business purpose.
- Access matches the user’s current role.
- Access remains necessary.
- Least privilege is being applied.
- Privileged access remains justified.
- Temporary access has not exceeded its approved period.
- Contractor and third-party access remains valid.
- Dormant or orphaned accounts have been identified.
- Access records match actual system permissions.
- Segregation-of-duties conflicts are identified.
- Required authentication controls remain effective.
- Unnecessary access is removed.
- Corrective actions are tracked and verified.
5. Review Criteria
Access should be evaluated against:
- Approved business need
- Current job/contractor role
- Access Rights Register
- Identity Register
- User Access Requests
- Access Control Matrix
- Privileged Access Register
- JML records
- Contractor records
- Third-party agreements
- Information classification
- Least-privilege requirements
- Segregation-of-duties requirements
- Authentication requirements
- Production-access requirements
- Organizational security policies
- Applicable contractual or regulatory requirements
6. Information Sources
Use appropriate sources to validate actual access.
| Source | Reviewed | Date | Evidence |
|---|---|---|---|
| Identity Provider/SSO | ☐ | ||
| HR Records | ☐ | ||
| Access Rights Register | ☐ | ||
| Privileged Access Register | ☐ | ||
| AWS IAM/Identity Center | ☐ | ||
| Azure/GCP | ☐ | ||
| SaaS Applications | ☐ | ||
| GitHub/Repository | ☐ | ||
| VPN | ☐ | ||
| Database | ☐ | ||
| Security Platforms | ☐ | ||
| Contractor Register | ☐ | ||
| Third-Party Register | ☐ |
7. Review Methodology
The review should follow:
Step 1 — Collect
Obtain current access information from relevant systems.
Step 2 — Reconcile
Compare actual system access with the Access Rights Register and Identity Register.
Step 3 — Validate
Confirm the user’s role, business need, owner, and approval.
Step 4 — Assess
Determine whether access remains appropriate and follows least privilege.
Step 5 — Identify Findings
Record excessive, outdated, unauthorized, or incorrectly recorded access.
Step 6 — Remediate
Remove or modify inappropriate access.
Step 7 — Verify
Confirm that corrective actions were successfully implemented.
Step 8 — Report
Document the review results and outstanding items.
8. User Access Review Register
| Review Item | User | System | Role | Access | Business Need | Approved | Appropriate | Action |
|---|---|---|---|---|---|---|---|---|
| AR-001 | Yes / No | Yes / No | Yes / No | |||||
| AR-002 | Yes / No | Yes / No | Yes / No |
Recommended decision values:
- Retain
- Modify
- Revoke
- Investigate
9. Detailed Access Review Record
For each access right requiring detailed assessment:
Access Information
| Field | Details |
|---|---|
| Access Right ID | |
| Identity ID | |
| User | |
| Department | |
| Current Role | |
| System | |
| Environment | |
| Assigned Role | |
| Permissions | |
| Privileged | Yes / No |
| Business Purpose | |
| Information Classification | |
| Original Approval | |
| Last Review |
Review Assessment
| Question | Result |
|---|---|
| User still active? | Yes / No |
| Business need still valid? | Yes / No |
| Role still correct? | Yes / No |
| Access level appropriate? | Yes / No |
| Least privilege applied? | Yes / No |
| Privileged access justified? | Yes / No / N/A |
| MFA appropriate/enabled? | Yes / No / N/A |
| Temporary access expired? | Yes / No / N/A |
| SoD conflict identified? | Yes / No |
| Access matches system records? | Yes / No |
Review Decision
☐ Retain
☐ Modify
☐ Revoke
☐ Investigate
Reviewer Comments
10. Employee Access Review
For employee access, verify:
- ☐ Employee remains active
- ☐ Department is correct
- ☐ Job role is current
- ☐ Manager is current
- ☐ Access remains necessary
- ☐ Old role access has been removed
- ☐ Privileged access remains justified
- ☐ Production access remains necessary
- ☐ No unnecessary permissions identified
11. Joiner Review
Identify recently onboarded users.
Check:
- ☐ Access was requested
- ☐ Access was approved
- ☐ Correct permissions were granted
- ☐ MFA was configured where required
- ☐ Least privilege was applied
- ☐ Access was recorded
- ☐ No unnecessary access was granted
12. Mover Review
Identify users who changed roles or departments during the review period.
Check:
- ☐ Previous role identified
- ☐ Previous access reviewed
- ☐ Unnecessary access removed
- ☐ New access approved
- ☐ New access provisioned
- ☐ Privileged access reassessed
- ☐ SoD considered
- ☐ Final access matches new role
A common issue to look for is privilege accumulation, where new permissions are added without removing permissions from the previous role.
13. Leaver Review
Compare access records against HR and contractor records.
Check:
- ☐ Former employees identified
- ☐ Former contractors identified
- ☐ Former third parties identified
- ☐ Accounts disabled
- ☐ SaaS access removed
- ☐ Cloud access removed
- ☐ Repository access removed
- ☐ VPN removed
- ☐ Privileged access removed
- ☐ Physical access removed
- ☐ Tokens/keys addressed where applicable
Any active access belonging to a former user should be investigated immediately.
14. Contractor Access Review
For each contractor:
| Field | Details |
|---|---|
| Contractor | |
| Organization | |
| Sponsor | |
| Contract/SOW | |
| Start Date | |
| End Date | |
| System | |
| Access | |
| Business Need | |
| Approval | |
| Access Expiry | |
| Review Result |
Check:
- ☐ Engagement still active
- ☐ Sponsor still valid
- ☐ Business need remains
- ☐ Access is appropriate
- ☐ Expiry date is correct
- ☐ Privileged access remains justified
15. Third-Party Access Review
Review external personnel such as:
- Auditors
- Consultants
- Support providers
- Managed service providers
- VAPT providers
- Customer representatives
- Integration partners
Check:
- ☐ Relationship remains active
- ☐ Individual is still authorized
- ☐ Internal sponsor is current
- ☐ Contract/SOW remains valid
- ☐ Access remains necessary
- ☐ Access scope remains appropriate
- ☐ Expiry date remains valid
- ☐ Privileged access is justified
16. Privileged Access Review
Privileged access requires additional scrutiny.
Review:
- Cloud administrators
- Database administrators
- Security administrators
- Identity administrators
- Network administrators
- Repository administrators
- CI/CD administrators
- Backup administrators
- Key-management administrators
- Secrets-management administrators
Privileged Review
| User | System | Privileged Role | Business Need | MFA | Approved | Retain/Modify/Revoke |
|---|---|---|---|---|---|---|
Check:
- ☐ Business justification exists
- ☐ Approval exists
- ☐ User still requires privilege
- ☐ Permissions are appropriate
- ☐ MFA is enabled where required
- ☐ Shared privileged accounts are avoided where practical
- ☐ Access is recorded in Privileged Access Register
- ☐ Monitoring is appropriate
- ☐ SoD has been considered
17. AWS Access Review
For an AWS environment, review:
- AWS accounts
- IAM Identity Center assignments
- IAM users where applicable
- IAM roles
- Administrator permissions
- Production access
- Development access
- Database access
- Security services
- Billing access
- Root/emergency access
- Service identities
AWS Review Questions
- Does each user have a valid business need?
- Are AWS roles appropriate for the user’s current role?
- Are production permissions restricted?
- Are privileged roles justified?
- Is MFA enabled where required?
- Are unnecessary IAM permissions present?
- Are former employees/contractors still assigned?
- Are stale IAM users or keys present?
- Are emergency accounts controlled?
18. SaaS Access Review
Review critical SaaS platforms such as:
- Microsoft 365
- GitHub
- Jira
- Salesforce
- HR systems
- Customer support platforms
- Security platforms
- Finance applications
Check:
- Active users
- Administrators
- External users
- Dormant accounts
- Group memberships
- Role assignments
- Application integrations
- API access
- Former employees
- Contractor access
19. Database Access Review
Review:
- Database users
- Application roles
- DBA permissions
- Read/write permissions
- Production access
- Service accounts
- Shared accounts
- Dormant accounts
Check that database permissions match approved business requirements.
20. Source-Code Repository Review
For GitHub or equivalent repositories, review:
- Organization members
- Repository members
- Administrators
- Maintainers
- External collaborators
- Deploy keys
- Tokens
- GitHub Apps/integrations
- Former employees
- Contractors
Confirm that permissions match the person’s current role.
21. Service Account Review
Service/application identities should be reviewed separately.
Check:
- Owner
- Business purpose
- System
- Permissions
- Environment
- Authentication method
- Privilege level
- Last activity where available
- Need for continued existence
- Credential lifecycle
Decision
☐ Retain
☐ Modify
☐ Rotate Credential
☐ Disable
☐ Retire
Actual service credentials should never be recorded in the review report.
22. Dormant and Orphaned Account Review
Identify:
Dormant Accounts
Accounts with no recent activity or apparent business need.
Orphaned Accounts
Accounts where the responsible person, owner, or business purpose cannot be established.
Review Action
Identify → Investigate → Confirm Need → Disable/Correct → Verify → Record
Unknown or unauthorized access should be escalated according to the organization’s security process.
23. Access Against Information Classification
Review whether access is appropriate for the sensitivity of information.
Example:
| Classification | Review Consideration |
|---|---|
| Public | Normal authorized access |
| Internal | Authorized organizational users |
| Confidential | Need-to-know access |
| Restricted | Strictly controlled access |
The organization’s actual classification scheme should be used.
24. Segregation of Duties Review
Consider potential conflicts such as:
- Requester and approver
- Developer and production approval
- Finance preparer and payment approver
- Access administrator and access approver
- Security administrator and independent auditor
Result
☐ No conflict
☐ Conflict identified
☐ Compensating control required
☐ Escalation required
25. Temporary Access Review
Identify temporary permissions approaching or past expiry.
| Access | User | Purpose | Start | Expiry | Current Status | Action |
|---|---|---|---|---|---|---|
Expired access should be removed unless there is an approved extension.
26. Findings Classification
The organization may classify review findings as:
Conforming
Access is appropriate and adequately controlled.
Observation
A condition was noted but does not currently require corrective action.
Improvement Opportunity
A process improvement may strengthen the control.
Nonconformity
A defined requirement or control was not adequately met.
The organization’s audit methodology should define the formal classification criteria.
27. Access Correction Action Register
| Action ID | Finding | User/System | Action Required | Owner | Due Date | Status | Verification |
|---|---|---|---|---|---|---|---|
| Open / Closed |
Possible actions:
- Remove access
- Reduce permissions
- Change role
- Disable account
- Enable MFA
- Remove privileged access
- Update register
- Rotate credential
- Investigate unauthorized access
- Update process
- Perform security review
28. Remediation Verification
Corrective actions should be verified after completion.
For each action:
- ☐ Action completed
- ☐ Actual system state verified
- ☐ Access Rights Register updated
- ☐ Identity Register updated where applicable
- ☐ Privileged Access Register updated where applicable
- ☐ Evidence retained
- ☐ Reviewer confirmed closure
Verified By: ____________________
Date: ____________________
29. Access Review Summary
| Metric | Result |
|---|---|
| Total Identities Reviewed | |
| Total Access Rights Reviewed | |
| Privileged Access Reviewed | |
| Contractor Access Reviewed | |
| Third-Party Access Reviewed | |
| Service Accounts Reviewed | |
| Dormant Accounts Identified | |
| Orphaned Accounts Identified | |
| Excess Access Identified | |
| Access Revoked | |
| Access Modified | |
| Exceptions | |
| Open Actions | |
| Closed Actions |
30. Review Results
Overall Assessment
☐ Access remains appropriate
☐ Minor corrections required
☐ Significant remediation required
☐ Further investigation required
Summary
Key Findings
Key Improvements Required
31. Open Items
| Item | Risk | Owner | Due Date | Status |
|---|---|---|---|---|
Any unresolved high-risk access issue should be escalated according to the organization’s risk and security processes.
32. Exceptions
| Exception ID | Access | Reason | Risk | Compensating Control | Approver | Expiry |
|---|---|---|---|---|---|---|
33. Management Escalation
Significant findings should be escalated where they involve:
- Unauthorized access
- Excessive privileged permissions
- Former employees with active access
- Unknown accounts
- Customer data exposure
- Restricted information
- Critical production systems
- Significant SoD conflicts
- Repeated access-review failures
Escalation should follow the organization’s risk and incident-management processes.
34. Review Approval
Reviewer
Name: ____________________
Role: ____________________
Signature/Approval: ____________________
Date: ____________________
System Owner
Name: ____________________
Approval: ____________________
Date: ____________________
Security/ISMS
Name: ____________________
Approval: ____________________
Date: ____________________
Management, if Required
Name: ____________________
Approval: ____________________
Date: ____________________
35. Evidence Repository
Record where supporting evidence is maintained.
Repository/Location:
Evidence may include:
- Access reports
- IAM exports
- SSO reports
- Access Rights Register
- Identity Register
- Privileged Access Register
- Approval records
- Review records
- Revocation evidence
- Change tickets
- Screenshots/configuration evidence where appropriate
- Corrective-action records
Do not place passwords, API keys, MFA secrets, private keys, or other actual credentials in the evidence repository.
36. Review Frequency
The organization should establish review frequency based on risk.
For example:
| Access Type | Example Review Frequency |
|---|---|
| Standard User Access | Periodic |
| Privileged Access | More frequent |
| Production Access | Risk-based, typically more frequent |
| Third-Party Access | Periodic and on contract changes |
| Temporary Access | At/near expiry |
| Service Accounts | Periodic |
| Emergency Accounts | Periodic and after use |
| High-Risk Systems | More frequent |
These frequencies are examples, not universal ISO 27001 requirements. The organization should define and document its own review criteria.
37. Startup-Friendly Access Review
A startup can perform periodic access reviews without a complex GRC platform.
A practical approach is:
Step 1
Export actual users and permissions from:
- SSO
- AWS
- GitHub
- Critical SaaS
- VPN
- Databases
Step 2
Compare against:
- HR list
- Contractor list
- Identity Register
- Access Rights Register
Step 3
Identify:
- Former users
- Excess access
- Privileged users
- Dormant accounts
- Unknown accounts
- Expired temporary access
Step 4
Assign corrective actions.
Step 5
Remove or modify inappropriate access.
Step 6
Verify the changes.
Step 7
Update the registers.
Step 8
Prepare the review report.
38. AWS SaaS Startup Example
Consider a 40-person SaaS company.
During the quarterly review, the team compares:
HR → Identity Provider → AWS → GitHub → SaaS Applications → Access Rights Register
The review identifies:
- A former contractor still has GitHub access.
- A developer still has an old privileged AWS role from a previous project.
- A service account has no documented owner.
Corrective Actions
- Contractor GitHub access → Revoked
- Old AWS privileged role → Removed
- Service account → Owner assigned and permissions reviewed
The reviewer verifies the actual system state and updates the registers.
This provides a complete trail:
Finding → Action → System Change → Verification → Register Update
39. Common Access Review Mistakes
Avoid:
- Reviewing only the Access Rights Register without checking actual system access.
- Reviewing only employees and ignoring contractors.
- Ignoring third-party accounts.
- Ignoring service accounts.
- Ignoring privileged access.
- Ignoring cloud roles.
- Ignoring SaaS administrator access.
- Ignoring repository access.
- Checking whether an account exists but not what permissions it has.
- Adding new permissions without removing old ones.
- Failing to verify remediation.
- Failing to update registers.
- Treating review completion as sufficient without addressing findings.
- Storing actual credentials in review evidence.
40. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| User Access Management Procedure | Defines access lifecycle |
| User Access Request Form | Evidence of access request |
| Access Rights Register | Primary access population |
| Identity Register | Identity population |
| Authentication Information Register | Authentication mechanisms |
| Access Control Matrix | Expected role-based permissions |
| Privileged Access Register | Privileged population |
| JML Procedure | Joiner/mover/leaver validation |
| Contractor Account Procedure | Contractor review |
| Third-Party Access Procedure | External access review |
| Access Revocation Checklist | Corrective access removal |
| Segregation of Duties Policy | Conflict assessment |
| Asset Return Checklist | Leaver verification |
| Risk Register | Significant access risks |
| Incident Management | Unauthorized access events |
41. ISO 27001 Connection
Periodic access review supports the organization’s implementation of identity, authentication, access-rights, privileged-access, and related information-security controls.
The exact controls and review frequency applicable to the organization should be determined through the organization’s risk assessment and Statement of Applicability (SoA).
The review should demonstrate not merely that access was reviewed, but that inappropriate access was identified, corrected, and verified where necessary.
42. Final Audit Trail
For each review, the organization should be able to demonstrate:
What population was reviewed?
What systems and access rights were included?
What source data was used?
Who performed the review?
How was actual access reconciled?
What inappropriate access was identified?
What corrective actions were taken?
Who verified the corrections?
Were the registers updated?
Were significant risks escalated?
Was the review formally completed and approved?
Final Principle
An access review is not complete simply because someone checked a list. The organization should compare actual access with authorized access, identify unnecessary or inappropriate permissions, correct them, verify the corrections, and retain evidence of the complete review cycle.