1. Report Information
| Field | Details |
|---|---|
| Report ID | ARR-YYYY-XXX |
| Review Period | |
| Review Date | |
| Organization / Business Unit | |
| System / Application | |
| Environment | Production / Test / Development |
| System Owner | |
| Data Owner | |
| Access Review Owner | |
| Security Reviewer | |
| Review Frequency | |
| Previous Review Date | |
| Next Review Date | |
| Report Status | Draft / Final / Closed |
2. Purpose
The purpose of this Access Review Report is to document the results of the periodic review of user and privileged access to organizational systems and information.
The review determines whether access:
- Remains authorized
- Is still required for business purposes
- Matches the user’s current role
- Follows the Access Control Matrix
- Follows least-privilege principles
- Is appropriately protected
- Does not create unacceptable segregation-of-duties conflicts
- Has been removed where no longer required
The report provides evidence that access rights are periodically reviewed and that identified issues are tracked to closure.
3. Scope
The review covers the systems, users, roles, and access rights defined below.
Systems Reviewed
| System | Environment | Owner | Criticality | Classification |
|---|---|---|---|---|
| Corporate Identity / SSO | Production | IT | High | Confidential |
| AWS Production | Production | CTO | Critical | Restricted |
| GitHub | Production | Engineering | High | Confidential |
| Customer Support | Production | Support | High | Confidential |
| HR System | Production | HR | High | Confidential |
Replace these examples with the organization’s actual systems.
4. Review Objectives
The review objectives are to verify that:
- Users are authorized.
- Access remains business justified.
- Access matches current job responsibilities.
- Excess permissions are identified.
- Privileged access remains justified.
- Former employees and contractors do not retain access.
- Mover-related access changes have been completed.
- Temporary access has not exceeded its approved duration.
- Third-party access remains valid.
- MFA and other required security controls are applied.
- Segregation-of-duties conflicts are identified.
- Review findings are remediated and verified.
5. Review Criteria
Access was reviewed against applicable:
- Access Control Policy
- Access Control Matrix
- User Access Request records
- JML Procedure
- Third-Party Access Procedure
- Privileged Access Register
- Information Classification Policy
- Segregation of Duties requirements
- Contractual requirements
- Security requirements
- Risk assessment and treatment requirements
6. Information Sources
The review was performed using appropriate current access information, such as:
- HR user list
- Employee/contractor list
- Identity Provider / SSO
- Application user lists
- AWS IAM
- Azure/GCP identity records
- SaaS administration consoles
- Database access lists
- Source-code repository permissions
- VPN users
- Privileged Access Register
- Access Control Matrix
- Previous access review
- User Access Requests
- Joiner-Mover-Leaver records
- Third-party access records
7. Review Methodology
The review followed:
Collect → Reconcile → Validate → Assess → Identify Findings → Remediate → Verify → Report
Step 1 – Collect
Obtain current access listings.
Step 2 – Reconcile
Compare system access with HR, contractor, and third-party records.
Step 3 – Validate
Compare access against the Access Control Matrix and approved access requests.
Step 4 – Assess
Evaluate:
- Business need
- Least privilege
- Role appropriateness
- Privileged access
- SoD
- Temporary access
- Third-party access
- MFA
- Dormant accounts
Step 5 – Identify Findings
Document access requiring correction, removal, or further investigation.
Step 6 – Remediate
Responsible owners correct the identified access.
Step 7 – Verify
Confirm that corrective actions were successfully completed.
Step 8 – Report
Issue the final Access Review Report.
8. Review Population
| Category | Population | Reviewed | Findings |
|---|---|---|---|
| Employees | |||
| Contractors | |||
| Third Parties | |||
| Privileged Users | |||
| Service Accounts | |||
| Temporary Accounts | |||
| Total |
9. User Access Review Results
| User | Role | System | Current Access | Required Access | Finding | Action | Status |
|---|---|---|---|---|---|---|---|
| User A | Developer | AWS Prod | Admin | Read/Log Access | Excess Privilege | Reduce Access | Closed |
| User B | Support | CRM | Write | Write | None | No Action | Closed |
| User C | Former Employee | GitHub | Write | None | Former User | Revoke | Closed |
| User D | Auditor | Audit Repository | Read | Temporary Read | Valid | Retain Until Expiry | Open |
10. Access Review Summary
Overall Review
| Metric | Result |
|---|---|
| Total Users Reviewed | |
| Total Systems Reviewed | |
| Total Access Records Reviewed | |
| Access Corrections Required | |
| Access Revocations Required | |
| Privileged Access Findings | |
| Third-Party Findings | |
| Dormant Accounts | |
| SoD Issues | |
| Documentation Gaps | |
| Open Actions | |
| Closed Actions |
11. Findings Classification
Findings should be classified according to organizational criteria.
| Finding Type | Description |
|---|---|
| No Finding | Access is appropriate and supported by evidence |
| Access Correction | Permission needs modification |
| Access Revocation | Access is no longer required |
| Privileged Access Issue | Excessive or unsupported privilege |
| SoD Issue | Incompatible access identified |
| Third-Party Access Issue | External access no longer justified or appropriately controlled |
| Temporary Access Issue | Access exceeded or lacks appropriate expiry |
| Dormant Account | Account appears inactive but remains enabled |
| Documentation Gap | Access may be appropriate but supporting evidence is missing |
| Security Finding | Security control such as MFA requires correction |
12. Detailed Findings
Finding ARR-F-001
Finding Title
Excessive Production Access
System
AWS Production
User/Role
Developer
Observation
The user was identified with elevated production permissions that were greater than the permissions required for the current role.
Expected Condition
Access should be limited to the permissions required for the user’s approved business responsibilities.
Risk
Excessive privileges may increase the potential impact of unauthorized or compromised account activity.
Required Action
Review and reduce the user’s production permissions to the minimum required level.
Owner
CTO / Cloud Administrator
Due Date
DD-MMM-YYYY
Status
Open / In Progress / Closed
Closure Evidence
IAM role/permission update and post-remediation verification.
13. Privileged Access Review
Privileged access should be reviewed separately or as part of the overall access review.
| User | System | Privileged Role | Business Need | MFA | Logging | Required? | Action | Status |
|---|---|---|---|---|---|---|---|---|
Check:
- Privileged user is authorized
- Business justification exists
- Named account is used
- MFA is enabled
- Permissions remain appropriate
- Logging is enabled where required
- Temporary access has expiry
- Privileged Access Register is current
14. Third-Party Access Review
| Third Party | User | System | Access | Contract Valid | Business Need | Expiry | Action | Status |
|---|---|---|---|---|---|---|---|---|
Verify:
- Contract/SOW remains valid
- User remains engaged
- Access is still required
- Access is least privilege
- Expiry is appropriate
- MFA is enabled where required
- Privileged access remains justified
- Access will be revoked when engagement ends
15. Joiner-Mover-Leaver Reconciliation
Compare current access with HR and JML records.
| Check | Result | Findings |
|---|---|---|
| New joiners received only approved access | Pass / Fail | |
| Former employees have been removed | Pass / Fail | |
| Role changes resulted in access changes | Pass / Fail | |
| Contractor access remains valid | Pass / Fail | |
| Third-party access remains valid | Pass / Fail | |
| Temporary access has appropriate expiry | Pass / Fail | |
| Privileged access was reviewed | Pass / Fail |
16. Dormant and Inactive Accounts
Review accounts that appear unused or inactive.
| Account | System | Last Activity | Owner | Business Need | Action | Status |
|---|---|---|---|---|---|---|
Possible actions:
- Disable
- Remove
- Confirm business need
- Reset/reconfigure
- Transfer ownership
- Retain with documented justification
17. Service Account Review
Service accounts should be reviewed separately from human users.
| Account | System | Purpose | Owner | Permissions | Interactive Login | Credential Control | Required? | Action |
|---|---|---|---|---|---|---|---|---|
Review:
- Business purpose
- Owner
- Permissions
- Credential storage
- Credential rotation
- Interactive login
- Monitoring
- Dependency
- Continued requirement
18. Segregation of Duties Review
Review whether combinations of access create inappropriate conflicts.
Examples:
| Role/User | Access Combination | Potential Conflict | Assessment | Action |
|---|---|---|---|---|
| Developer + Production Admin | ||||
| Requestor + Approver | ||||
| Finance Processor + Approver |
Where full separation is impractical, document the risk and applicable compensating controls.
19. MFA and Authentication Review
| System | User Population | MFA Required | MFA Enabled | Exceptions | Action |
|---|---|---|---|---|---|
| SSO | Yes | ||||
| AWS | Yes | ||||
| GitHub | Yes | ||||
| Security Platform | Yes |
Investigate exceptions rather than treating MFA coverage as a simple percentage target.
20. Access Against Classification
Review whether access is appropriate for the information being accessed.
| Information | Classification | User/Role | Access | Business Need | Appropriate? |
|---|---|---|---|---|---|
| Customer Database | Confidential | Support | Read | Customer Support | Yes/No |
| Production Credentials | Restricted | Developer | Admin | Development | Yes/No |
| Security Logs | Confidential | Security | Read | Security Monitoring | Yes/No |
21. Access Correction Action Register
| Action ID | Finding ID | User/System | Required Action | Owner | Due Date | Status | Verification |
|---|---|---|---|---|---|---|---|
| AC-001 | ARR-F-001 | AWS/User A | Reduce privilege | CTO | Closed | Verified | |
| AC-002 | ARR-F-002 | GitHub/User B | Revoke access | IT | Open | ||
| AC-003 | ARR-F-003 | SaaS/User C | Enable MFA | IT | In Progress |
22. Remediation Verification
Every completed access correction should be verified.
Verification Questions
- Was the requested permission removed?
- Was the correct permission retained?
- Was the user tested where necessary?
- Does the system now match the approved access?
- Was the Access Control Matrix updated if required?
- Was the Privileged Access Register updated?
- Was evidence captured?
Verification Record
| Action ID | Action Completed | Verified By | Verification Date | Evidence | Result |
|---|---|---|---|---|---|
| Pass / Fail |
23. Exceptions
Any unresolved access issue should be documented.
| Exception ID | System | User | Exception | Reason | Risk | Compensating Control | Approver | Expiry | Status |
|---|---|---|---|---|---|---|---|---|---|
Exceptions should not be left indefinitely without ownership and review.
24. Overall Review Conclusion
The conclusion should be based on the documented review results.
Example
The access review was performed for the systems and user population defined in this report. User access was compared against available role, approval, HR, privileged access, and system records. Identified access discrepancies were documented and assigned to responsible owners for remediation. Completed actions were verified where applicable, and unresolved items remain tracked through the corrective action or exception process.
25. Open Items
| ID | Finding | Owner | Due Date | Risk | Status |
|---|---|---|---|---|---|
Open items should be tracked until remediation or formally approved risk acceptance.
26. Management Review / Escalation
Significant access issues should be escalated according to organizational risk and governance requirements.
Examples:
- Unapproved privileged access
- Former employee retaining production access
- Unauthorized customer-data access
- Compromised privileged account
- Significant SoD conflict
- Long-overdue access remediation
- Repeated access-control failures
27. Report Approval
| Role | Name | Signature/Approval | Date |
|---|---|---|---|
| Access Review Owner | |||
| System Owner | |||
| Security/ISMS | |||
| Data Owner, where applicable | |||
| Management, where required |
28. Evidence Repository
Record where supporting evidence is stored.
| Evidence | Reference | Location | Owner |
|---|---|---|---|
| User Access Export | |||
| Access Control Matrix | |||
| Access Requests | |||
| HR User List | |||
| Privileged Access Register | |||
| Access Review Evidence | |||
| Remediation Evidence | |||
| Approval Records |
Sensitive access information should be stored using an appropriately protected location and access restrictions.
29. Review Frequency
Access reviews should be performed at a frequency appropriate to risk.
Examples:
- Standard applications: periodic review
- Confidential information: periodic review
- Production access: more frequent/risk-based review
- Privileged access: more frequent/risk-based review
- Third-party access: based on engagement and risk
- Temporary access: at or before expiry
- High-risk systems: risk-based enhanced review
These are practical examples rather than universal ISO 27001 frequencies.
30. Audit Checklist
Before closing the report:
- Review scope defined
- User population identified
- Current access data obtained
- HR records reconciled
- Access Control Matrix checked
- User Access Requests checked where required
- Privileged access reviewed
- Third-party access reviewed
- Joiner access checked
- Mover access checked
- Leaver access checked
- Dormant accounts reviewed
- Service accounts reviewed
- SoD reviewed
- MFA reviewed
- Findings documented
- Remediation assigned
- Completed actions verified
- Exceptions documented
- Open items tracked
- Report approved
- Evidence retained
31. Relationship with Other ISMS Documents
The Access Review Report provides evidence for the operation of:
- Access Control Policy
- Access Control Matrix
- User Access Request
- User Access Review Checklist
- Joiner-Mover-Leaver Procedure
- Third-Party Access Procedure
- Privileged Access Register
- Access Revocation Checklist
- Employee Offboarding Checklist
- Contractor Offboarding Checklist
- Segregation of Duties Policy
- Information Classification Policy
- Information & Asset Inventory
- Risk Register
Complete Access Governance Chain
Role → Business Need → Access Request → Approval → Provision → Actual Access → Periodic Review → Correction/Revocation → Verification → Evidence
32. ISO 27001 Connection
The Access Review Report provides operational evidence supporting applicable ISO/IEC 27001 requirements relating to:
- Identity management
- Authentication information
- Access rights
- Access restriction
- Privileged access
- Segregation of duties
- Access review
- Supplier/third-party access
- Logging and monitoring where applicable
The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA).
33. Final Audit Trail
The completed report should allow an auditor to answer:
Who had access?
↓
What access did they have?
↓
Why did they need it?
↓
Who approved it?
↓
Does it match their current role?
↓
Was privileged/third-party access reviewed?
↓
Were unnecessary permissions removed?
↓
Were corrections verified?
↓
Is evidence available?
Final Principle
Access should not be considered secure simply because it was approved once. The organization should periodically verify that actual access remains appropriate, necessary, authorized, and consistent with business roles and security requirements—and retain evidence of the review and any corrective actions.