1. Purpose
The Privileged User Offboarding Checklist provides a structured process for securely removing administrative and elevated access when a privileged user leaves the organization, changes role, loses authorization, or no longer requires privileged access.
The objective is to ensure that:
- Privileged access is revoked promptly
- Administrative accounts are disabled
- Cloud and production access is removed
- Credentials and secrets are protected
- Shared or delegated privileged access is addressed
- Authentication methods are revoked
- Business information is transferred appropriately
- Security evidence is preserved where required
- Privileged access changes are independently verified
- The offboarding activity is fully documented
Core Principle
Identify → Assess → Inventory → Revoke → Rotate → Verify → Transfer → Record → Close
2. When to Use
Use this checklist when a privileged user:
- Leaves the organization
- Is terminated
- Changes to a non-privileged role
- Loses administrative responsibilities
- No longer requires elevated access
- Moves to another department
- Changes employment status
- Completes a privileged project
- Is a contractor or consultant whose engagement ends
- Is subject to an emergency access revocation
It should also be used when privileged access must be removed immediately because of a security concern.
3. Privileged User Information
| Field | Details |
|---|---|
| Offboarding ID | |
| User Name | |
| Employee/Contractor ID | |
| Job Title | |
| Department | |
| Manager | |
| User Type | ☐ Employee ☐ Contractor ☐ Consultant ☐ Other |
| Privileged Role | |
| Business Owner | |
| Security Owner | |
| Offboarding Date | |
| Effective Time | |
| Reason | |
| Risk Level | ☐ Low ☐ Medium ☐ High ☐ Critical |
| Reviewer | |
| Completion Date |
4. Offboarding Trigger
Identify why privileged access must be removed.
☐ Employment termination
☐ Resignation
☐ Role change
☐ Transfer
☐ Privileged responsibilities removed
☐ Contract/project completed
☐ Administrative access no longer required
☐ Security concern
☐ Suspected compromise
☐ Policy violation
☐ Emergency access revocation
☐ Other: __________________________
Trigger Details
5. Authorization and Timing
Confirm who authorized the offboarding.
☐ Manager notified
☐ HR notified where applicable
☐ Security notified
☐ IT/IAM notified
☐ System owners notified
☐ Cloud/platform owner notified
☐ Business owner notified
☐ Risk owner notified where required
Effective Date and Time
Date: ______________________
Time: ______________________
Timezone: __________________
Required Revocation Timing
☐ Immediately
☐ At termination time
☐ End of working day
☐ Scheduled role-change time
☐ Other: ______________________
For high-risk or emergency situations, access should be revoked without unnecessary delay.
6. Privileged Access Inventory
Identify every privileged account and access path associated with the user.
☐ Corporate identity
☐ Domain administrator
☐ Identity administrator
☐ AWS administrator
☐ Azure administrator
☐ Google Cloud administrator
☐ Cloud root-related access
☐ Production administrator
☐ Database administrator
☐ Network administrator
☐ Security administrator
☐ Source-code administrator
☐ CI/CD administrator
☐ SaaS administrator
☐ Endpoint administrator
☐ VPN administrator
☐ Firewall administrator
☐ Backup administrator
☐ Monitoring administrator
☐ Security-tool administrator
☐ API access
☐ Service account ownership
☐ Shared administrative account
☐ Emergency/break-glass account
☐ Other: ______________________
7. Corporate Identity
Verify the user’s primary corporate identity.
☐ Account identified
☐ Account disabled
☐ Password reset where required
☐ MFA methods disabled/revoked
☐ SSO sessions terminated
☐ Active sessions revoked
☐ Group memberships removed
☐ Administrative groups removed
☐ Delegated permissions removed
☐ Recovery methods removed
☐ Recovery email/phone reviewed
☐ Authentication tokens revoked
Verification
8. Identity and Access Management
Review the user’s access through the organization’s IAM platform.
☐ User identified
☐ Privileged roles identified
☐ Role assignments removed
☐ Administrative groups removed
☐ Conditional access reviewed
☐ Temporary privileges removed
☐ Access tokens revoked
☐ OAuth authorizations revoked
☐ API tokens revoked
☐ Sessions terminated
☐ Device trust removed
☐ Authentication devices removed
9. AWS Privileged Access
If the user has AWS access, verify:
☐ IAM user identified
☐ IAM roles identified
☐ AdministratorAccess reviewed
☐ PowerUserAccess reviewed
☐ Custom privileged policies reviewed
☐ AWS SSO/IAM Identity Center access removed
☐ AWS groups removed
☐ Account-level access removed
☐ Cross-account roles reviewed
☐ Cross-account trust relationships reviewed
☐ Access keys disabled/deleted
☐ Temporary credentials expired
☐ MFA device removed where appropriate
☐ Active AWS sessions terminated where possible
☐ CloudTrail activity reviewed where required
☐ Break-glass access reviewed
AWS Accounts
| AWS Account | Role/Permission | Access Type | Action | Verified |
|---|---|---|---|---|
10. Cloud Platform Access
For other cloud platforms:
Microsoft Azure
☐ Azure account access removed
☐ Subscription roles removed
☐ Resource-group roles removed
☐ Privileged Identity Management access removed
☐ Service principals reviewed
☐ MFA/authentication methods addressed
Google Cloud
☐ Google Cloud account removed
☐ IAM roles removed
☐ Project-level permissions removed
☐ Organization-level permissions removed
☐ Service-account access reviewed
☐ Authentication credentials addressed
Other Cloud
☐ Provider: ______________________
☐ Privileged access removed
☐ Roles removed
☐ Credentials revoked
☐ Sessions terminated
☐ Verification completed
11. Production Environment
If the user had production access:
☐ Production systems identified
☐ Production accounts disabled
☐ Production roles removed
☐ SSH access removed
☐ Bastion access removed
☐ VPN access removed
☐ Production database access removed
☐ Production Kubernetes access removed
☐ Production server access removed
☐ Administrative console access removed
☐ CI/CD production permissions removed
☐ Emergency access reviewed
Production Systems
| System | Access | Privilege | Action | Verified |
|---|---|---|---|---|
12. Source Code and Development Platforms
Review privileged access to:
☐ GitHub
☐ GitLab
☐ Bitbucket
☐ Azure DevOps
☐ Source-code repositories
☐ Organization administration
☐ Repository administration
☐ Branch protection administration
☐ Deployment permissions
☐ CI/CD administration
☐ Package registries
☐ Container registries
Verify:
☐ User removed
☐ Organization admin role removed
☐ Repository permissions removed
☐ SSH keys revoked
☐ Personal access tokens revoked
☐ Deploy keys reviewed
☐ Webhooks/integrations reviewed
☐ CODEOWNERS/ownership updated
☐ Secrets ownership reviewed
13. CI/CD and Deployment Access
If the user had deployment privileges:
☐ CI/CD platform identified
☐ Administrator access removed
☐ Deployment permissions removed
☐ Production deployment rights removed
☐ Pipeline administration removed
☐ Pipeline secrets reviewed
☐ Personal credentials removed
☐ API tokens revoked
☐ Signing credentials reviewed
☐ Deployment keys rotated where necessary
14. Database Privileged Access
Review:
☐ Production databases
☐ Development databases
☐ Test databases
☐ Database administrator accounts
☐ Database consoles
☐ Database VPN access
☐ Database credentials
☐ Database API access
Verify:
☐ User removed
☐ Administrative roles removed
☐ Database credentials revoked
☐ Shared credentials rotated where necessary
☐ Connection access removed
☐ Privileged database activity reviewed where required
15. Network and Security Infrastructure
Review privileged access to:
☐ Firewalls
☐ Routers
☐ Switches
☐ VPN
☐ WAF
☐ DNS
☐ Load balancers
☐ Network management systems
☐ SIEM
☐ EDR/XDR
☐ Vulnerability scanners
☐ Security monitoring tools
☐ Email security
☐ Identity security systems
Verify:
☐ Administrative account disabled
☐ Privileged role removed
☐ MFA removed/revoked
☐ API credentials revoked
☐ Shared credentials reviewed
☐ Access logs reviewed where required
16. SaaS Administrative Access
Identify SaaS applications where the user has administrative privileges.
Examples:
- Google Workspace
- Microsoft 365
- Slack
- Jira
- Confluence
- Salesforce
- CRM
- HR systems
- Finance systems
- Security platforms
- Monitoring platforms
- Ticketing systems
☐ SaaS administrator roles removed
☐ User account disabled
☐ MFA removed/revoked
☐ API tokens revoked
☐ OAuth applications revoked
☐ Delegated access removed
☐ Shared administrative access reviewed
17. Privileged Authentication Methods
Review all authentication mechanisms.
☐ Password
☐ MFA application
☐ Hardware security key
☐ Smart card
☐ SSH key
☐ API key
☐ Personal access token
☐ OAuth token
☐ Certificate
☐ VPN credential
☐ Cloud access key
☐ Recovery code
☐ Backup authentication method
Required Actions
☐ Authentication method revoked
☐ Credentials rotated where required
☐ Recovery methods removed
☐ Tokens invalidated
☐ Sessions terminated
18. Secrets and Shared Credentials
Determine whether the user knew or controlled any shared secrets.
Examples:
- Production passwords
- Database credentials
- API keys
- Cloud credentials
- SSH keys
- Encryption keys
- Signing keys
- Service-account credentials
- CI/CD secrets
- Administrative passwords
☐ Secrets identified
☐ Exposure risk assessed
☐ Credentials rotated where necessary
☐ API keys rotated
☐ SSH keys rotated
☐ Service-account credentials reviewed
☐ CI/CD secrets reviewed
☐ Password vault access removed
☐ Secret ownership transferred
Important
If a departing privileged user knew a shared credential that cannot be individually revoked, consider rotating the credential rather than relying only on removing the user’s personal account.
19. Service Accounts
Determine whether the user created, owned, or administered service accounts.
☐ Service accounts identified
☐ Business owner identified
☐ Technical owner identified
☐ Ownership transferred
☐ Personal dependencies removed
☐ Credentials reviewed
☐ Unnecessary accounts disabled
☐ Secrets rotated where required
☐ Documentation updated
Do not automatically disable service accounts without assessing whether business services depend on them.
20. Break-Glass and Emergency Access
If the user had emergency access:
☐ Break-glass account identified
☐ User access removed
☐ Recovery credentials reviewed
☐ Emergency credentials rotated where required
☐ MFA/recovery methods reviewed
☐ Emergency access ownership updated
☐ Access logs reviewed
☐ Emergency access procedure updated
21. Physical Privileged Access
Where applicable:
☐ Data-center access removed
☐ Server-room access removed
☐ Security-room access removed
☐ Restricted-area access removed
☐ Access card disabled
☐ Keys recovered
☐ Security tokens recovered
☐ Biometric access removed
☐ Visitor privileges removed
22. Privileged Devices
Identify devices used for administrative access.
☐ Laptop
☐ Desktop
☐ Privileged workstation
☐ Mobile device
☐ Hardware security key
☐ Administrative console
☐ Other: ______________________
Verify:
☐ Device ownership confirmed
☐ Device recovered where applicable
☐ Device management access removed
☐ Certificates addressed
☐ Stored credentials removed
☐ Browser sessions reviewed
☐ SSH keys addressed
☐ Local administrator access reviewed
23. Information and Knowledge Transfer
Before closure, identify important business or technical information owned by the user.
☐ Documentation identified
☐ System knowledge transferred
☐ Architecture information transferred
☐ Operational procedures transferred
☐ Security documentation transferred
☐ Recovery information transferred
☐ Supplier information transferred
☐ Customer information transferred
☐ Credentials transferred through approved mechanism where required
☐ Ownership updated
Do not transfer passwords or secrets through email, chat, or other unapproved channels.
24. Security Investigation Consideration
Before deleting accounts, devices, logs, or data, determine whether the user is associated with:
☐ Security incident
☐ Policy violation
☐ Suspicious activity
☐ Insider-risk concern
☐ Legal matter
☐ Regulatory investigation
☐ Customer investigation
☐ Litigation hold
☐ Other investigation
If applicable:
☐ Evidence preservation initiated
☐ Account activity preserved
☐ Relevant logs preserved
☐ Device preservation considered
☐ Investigation owner assigned
☐ Legal/HR/Security consulted
Important
Do not destroy potentially relevant evidence simply because the user is being offboarded.
25. Privileged Activity Review
For high-risk or sensitive departures, consider reviewing recent privileged activity.
☐ AWS activity
☐ Production activity
☐ Database activity
☐ Source-code activity
☐ CI/CD activity
☐ Security-tool activity
☐ Administrative changes
☐ Configuration changes
☐ Credential changes
☐ Data-access activity
Review Period
From: ______________________
To: ________________________
Review Result
26. Third-Party Privileged Access
If the user was a contractor or consultant:
☐ Supplier identified
☐ Supplier owner notified
☐ Supplier access reviewed
☐ Supplier accounts disabled
☐ VPN access removed
☐ Cloud access removed
☐ Source-code access removed
☐ Production access removed
☐ Supplier credentials addressed
☐ Supplier equipment recovered
☐ Supplier offboarding confirmed
27. Customer and External-System Access
Review external systems where the user had administrative access.
☐ Customer environments
☐ Customer cloud accounts
☐ Customer support systems
☐ Customer portals
☐ Partner systems
☐ Supplier systems
☐ External security platforms
☐ Access revoked
☐ External owner notified where required
☐ Credentials rotated where necessary
☐ Confirmation obtained where appropriate
28. Final Access Verification
A second person should independently verify privileged access removal for high-risk users.
Verify:
☐ Corporate account disabled
☐ Privileged roles removed
☐ AWS/cloud access removed
☐ Production access removed
☐ Source-code access removed
☐ Database access removed
☐ SaaS administration removed
☐ VPN access removed
☐ API tokens revoked
☐ SSH keys revoked
☐ MFA methods addressed
☐ Shared credentials rotated where necessary
☐ Service-account ownership transferred
☐ Physical access removed
Independent Reviewer
Name: __________________________
Date: __________________________
Signature/Approval: __________________________
29. Validation Test
Where practical, perform a controlled validation.
☐ Login attempt unsuccessful
☐ Privileged console access unsuccessful
☐ AWS/cloud access unsuccessful
☐ Production access unsuccessful
☐ Source-code administration unavailable
☐ Database administration unavailable
☐ VPN access unavailable
☐ SaaS administrator access unavailable
☐ API/token access unavailable
Do not perform unnecessary intrusive testing against production systems.
30. Exceptions
Document any access that could not be removed immediately.
| System | Access | Reason | Risk | Temporary Control | Owner | Due Date |
|---|---|---|---|---|---|---|
Exceptions should have an accountable owner and defined closure date.
31. Evidence Collection
Retain appropriate evidence such as:
☐ Offboarding request
☐ Manager/HR notification
☐ Access inventory
☐ IAM records
☐ Account-disable evidence
☐ AWS/cloud access records
☐ Source-code access records
☐ Production access records
☐ Credential-rotation evidence
☐ Access-review evidence
☐ Security investigation records where applicable
☐ Asset-return evidence
☐ Final verification
☐ Exception approvals
☐ Completion record
Do not retain passwords, API keys, private keys, recovery codes, or other authentication secrets as evidence.
32. Privileged User Offboarding Register
| Offboarding ID | User | Privileged Role | Effective Date | Access Revoked | Reviewer | Status |
|---|---|---|---|---|---|---|
Status
☐ Open
☐ In Progress
☐ Pending Exception
☐ Verification Pending
☐ Completed
☐ Closed
33. Completion Criteria
Privileged user offboarding is complete only when:
☐ All known privileged access has been identified
☐ Required access has been revoked
☐ Authentication methods have been addressed
☐ Shared credentials have been assessed
☐ Secrets have been rotated where necessary
☐ Cloud access has been removed
☐ Production access has been removed
☐ Source-code access has been removed
☐ Database access has been removed
☐ SaaS administrative access has been removed
☐ Service-account ownership has been addressed
☐ Physical access has been removed
☐ Investigation/evidence requirements have been considered
☐ Business information has been transferred
☐ Independent verification has been completed where required
☐ Exceptions have been documented
☐ Evidence has been retained
☐ Offboarding register has been updated
34. Final Approval
User: ______________________________
Privileged Role: ______________________________
Offboarding Effective Date: ______________________________
Completed By: ______________________________
Security Reviewer: ______________________________
Manager/Business Owner: ______________________________
Completion Date: ______________________________
Final Status: ☐ Completed ☐ Completed with Exception
Comments
35. AWS SaaS Startup Example
A SaaS startup’s DevOps engineer is leaving the organization.
The engineer has:
- AWS Administrator access
- Production Kubernetes access
- GitHub organization administrator access
- Production database access
- CI/CD administrator access
- VPN access
- Monitoring administrator access
- Access to production secrets
Offboarding Actions
Before the effective termination time:
- Confirm the approved termination time.
- Identify all privileged accounts.
- Coordinate HR, IT, Security, and the engineering manager.
- Prepare the access-revocation sequence.
- Preserve evidence if an investigation is required.
At the effective time:
- Disable corporate identity.
- Remove AWS IAM Identity Center permissions.
- Revoke privileged AWS roles.
- Disable/delete access keys where appropriate.
- Remove GitHub organization administration.
- Revoke GitHub tokens and SSH keys.
- Remove Kubernetes administration.
- Remove production database access.
- Remove VPN access.
- Remove CI/CD administration.
- Revoke privileged SaaS access.
- Rotate shared production credentials if the user knew them.
After revocation:
- Independently verify access removal.
- Review recent privileged activity if required.
- Transfer technical ownership.
- Update service-account ownership.
- Update the access register.
- Preserve evidence where applicable.
- Close the offboarding record.
Audit Trail
Termination Decision → Privileged Access Inventory → Access Revocation → Credential Rotation → Investigation Check → Independent Verification → Ownership Transfer → Evidence → Closure
36. Startup-Friendly Privileged Offboarding Model
A startup does not need a complicated process, but privileged access must be controlled.
Minimum Process
1. Identify
Who is leaving and what privileged access do they have?
2. Inventory
Check IAM, AWS/cloud, GitHub, production, databases, SaaS, VPN and security tools.
3. Revoke
Remove administrative access at the effective time.
4. Rotate
Rotate shared credentials and secrets where the user knew or controlled them.
5. Verify
A second person verifies that privileged access is no longer available.
6. Preserve
Check whether security, legal, or investigation requirements require evidence preservation.
7. Transfer
Transfer system ownership and operational knowledge.
8. Record
Maintain evidence and close the offboarding record.
37. Common Mistakes
Avoid:
- Disabling only the employee’s email account.
- Forgetting cloud administrator roles.
- Forgetting GitHub/GitLab organization access.
- Forgetting production database access.
- Forgetting VPN access.
- Forgetting CI/CD administration.
- Forgetting API keys and SSH keys.
- Forgetting shared administrative passwords.
- Forgetting service-account ownership.
- Assuming MFA removal alone removes access.
- Failing to terminate active sessions.
- Failing to review cross-account cloud access.
- Failing to check customer environments.
- Deleting evidence before checking investigation requirements.
- Allowing exceptions without an owner or expiry date.
- Having the same person revoke and verify critical access without independent review.
- Assuming asset return means access revocation is complete.
38. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Access Management Procedure | Defines access lifecycle |
| Privileged Access Management Procedure | Defines elevated-access controls |
| Employee Offboarding Policy | Defines overall employee exit requirements |
| Employee Termination Security Checklist | Covers general termination security |
| Access Revocation Checklist | Provides broader access-removal controls |
| Asset Return Checklist | Covers physical/electronic asset recovery |
| Joiner-Mover-Leaver Procedure | Manages user lifecycle |
| Incident Response Procedure | Handles security-related offboarding |
| Evidence Preservation Procedure | Protects investigation evidence |
| Access Review Procedure | Reviews ongoing privileged access |
| Supplier Offboarding Checklist | Handles external privileged users |
| Asset Register | Records organizational assets |
| Access Register | Records user/system access |
| Privileged Access Register | Records elevated access |
| Incident Register | Records security incidents |
| Risk Register | Records significant offboarding risks |
39. ISO 27001 / SOC 2 Connection
Privileged user offboarding supports the organization’s implementation of access control, identity management, authentication, privileged access management, personnel security, and timely removal or adjustment of access.
For ISO 27001, the exact controls and evidence applicable to the organization should be determined through the organization’s risk assessment and Statement of Applicability.
For SOC 2, the checklist can provide evidence that privileged access is removed when no longer required and that access changes are controlled and reviewed.
The checklist itself is not a substitute for the organization’s documented access-control procedures or risk-based control framework.
40. Quick Audit Checklist
☐ Offboarding trigger documented
☐ Effective date/time confirmed
☐ Privileged role identified
☐ Privileged access inventory completed
☐ Corporate identity disabled
☐ MFA addressed
☐ Cloud access removed
☐ AWS access removed
☐ Production access removed
☐ Database access removed
☐ Source-code access removed
☐ CI/CD access removed
☐ VPN access removed
☐ SaaS administrator access removed
☐ API tokens revoked
☐ SSH keys revoked
☐ Shared credentials assessed
☐ Secrets rotated where required
☐ Service accounts reviewed
☐ Break-glass access reviewed
☐ Physical access removed
☐ Customer/external access removed
☐ Investigation requirements considered
☐ Recent privileged activity reviewed where required
☐ Business information transferred
☐ Independent verification completed
☐ Exceptions documented
☐ Evidence retained
☐ Register updated
☐ Final approval completed
41. Final Audit Trail
For every privileged user leaving the organization, the organization should be able to demonstrate:
Who was the privileged user?
Why was privileged access removed?
When was access required to be removed?
What privileged systems did the user have access to?
Was cloud and production access removed?
Were credentials, tokens, keys and shared secrets addressed?
Were service accounts and delegated access reviewed?
Was recent privileged activity reviewed where appropriate?
Was evidence preserved when required?
Was business knowledge transferred?
Who independently verified access removal?
Were exceptions documented and controlled?
What evidence proves the offboarding was completed?
Final Principle
Privileged offboarding is not simply disabling a user account. It is the controlled removal of every administrative pathway that could allow a former or unauthorized privileged user to access, modify, or control organizational systems and information.