Employee Offboarding Policy

1. Purpose

The Employee Offboarding Policy establishes requirements for securely removing an employee’s access, recovering organizational assets, protecting information, and completing security responsibilities when an employee leaves the organization.

The objective is to ensure that:

Access is revoked in a timely manner.
Organizational information remains protected.
Company assets are returned.
Credentials and authentication mechanisms are addressed.
Confidentiality obligations are reinforced.
Customer and personal information remains protected.
Security risks associated with employee departure are assessed.
Evidence of offboarding is retained.
The organization can demonstrate that the employee’s access ended appropriately.

Core Principle

Identify → Notify → Assess → Revoke → Recover → Protect → Verify → Record → Close

2. Scope

This policy applies to:

☐ Permanent employees
☐ Temporary employees
☐ Interns
☐ Contractors
☐ Consultants
☐ Remote employees
☐ Privileged users
☐ Employees with production access
☐ Employees with cloud access
☐ Employees with source-code access
☐ Other personnel where the organization determines equivalent controls are required

Where contractors or third parties are managed through a supplier process, this policy should operate consistently with the applicable supplier offboarding requirements.

3. Policy Statement

The organization shall maintain a controlled process for employee offboarding.

When employment or engagement ends, the organization shall, as applicable:

Receive and validate the termination notification.
Determine the required timing of access removal.
Identify systems and information accessible by the employee.
Revoke or disable access.
Recover organizational assets.
Address credentials, tokens, keys, and other authentication mechanisms.
Protect organizational information.
Address continuing confidentiality obligations.
Review business ownership and dependencies.
Verify completion.
Retain appropriate evidence.

Offboarding controls shall be proportionate to the employee’s role, access, information handled, and security risk.

4. Offboarding Trigger

Offboarding begins when an authorized notification is received that an employee or other personnel will leave the organization.

Possible triggers include:

☐ Resignation
☐ Termination
☐ Contract expiry
☐ Retirement
☐ End of internship
☐ End of temporary assignment
☐ Redundancy
☐ Organizational restructuring
☐ Other separation
☐ Security-related termination where applicable

5. Offboarding Timing

The organization shall define when access must be removed based on the circumstances.

Normal Departure

Access may be disabled at the agreed end of employment or engagement.

Immediate/Risk-Based Departure

Where there is a heightened security risk, access may need to be restricted or removed immediately.

Examples include:

Suspected malicious activity
Unauthorized access
Serious policy violation
Data-security concern
Privileged access combined with elevated risk
Other circumstances identified by authorized management, HR, Security, or Legal

Actions must be lawful, authorized, proportionate, and consistent with applicable employment and legal requirements.

6. Roles and Responsibilities

HR

Responsible for:

Initiating the offboarding notification.
Confirming the employee’s final working date.
Communicating applicable employment requirements.
Coordinating with relevant stakeholders.
Maintaining appropriate HR records.

Manager

Responsible for:

Confirming business responsibilities.
Identifying systems and information owned by the employee.
Identifying business-critical dependencies.
Approving required knowledge transfer.
Confirming return of business responsibilities.

IT

Responsible for:

Disabling accounts.
Revoking access.
Recovering devices.
Removing authentication mechanisms.
Completing technical offboarding.

Information Security

Responsible for:

Supporting risk assessment where required.
Reviewing privileged or high-risk access.
Addressing security-sensitive credentials.
Supporting security-related departures.
Verifying security controls where required.

Asset Owner/System Owner

Responsible for:

Confirming access removal from relevant systems.
Transferring ownership.
Confirming recovery of business information.

Employee

Responsible for:

Returning organizational assets.
Returning or transferring organizational information.
Completing required knowledge transfer.
Maintaining confidentiality.
Cooperating with the offboarding process.

7. Offboarding Risk Assessment

Determine the employee’s security risk.

Consider:

☐ Privileged access
☐ Production access
☐ Cloud administration
☐ Source-code access
☐ Database access
☐ Customer data
☐ Personal data
☐ Financial information
☐ Security systems
☐ Intellectual property
☐ Administrative credentials
☐ Supplier access
☐ Critical business responsibilities
☐ Key-person dependency
☐ Remote access

Risk Level

☐ Low
☐ Medium
☐ High
☐ Critical

Risk Assessment

8. Access Inventory

Before or during offboarding, identify applicable access.

System/Service	Access Type	Privileged	Owner	Revoked	Date
Email
VPN
AWS
GitHub
SaaS
Database
Production
Other

The inventory should be based on the organization’s access records and role requirements rather than relying solely on employee memory.

9. Identity and Account Deactivation

Where applicable:

☐ Corporate identity disabled
☐ Email disabled
☐ SSO account disabled
☐ VPN account disabled
☐ MFA methods removed
☐ Remote-access accounts disabled
☐ Directory account disabled
☐ Collaboration tools disabled
☐ Application accounts disabled

Accounts should not simply be deleted if records need to be retained for business, legal, audit, security, or compliance purposes.

10. Cloud Access

For AWS or other cloud platforms:

☐ IAM user disabled/removed where applicable
☐ IAM roles reviewed
☐ Privileged access removed
☐ Console access removed
☐ Access keys disabled/revoked
☐ Temporary credentials addressed
☐ MFA associations addressed
☐ Cloud groups reviewed
☐ Resource ownership transferred
☐ Cloud audit records retained as required

AWS Example

Review:

IAM
SSO/Identity Center
Cloud accounts
Production roles
Administrative roles
Access keys
Secrets
CI/CD permissions
Security tooling

11. Source-Code and Development Access

For development personnel:

☐ GitHub/GitLab/Bitbucket access removed
☐ Repository permissions reviewed
☐ Organization membership removed
☐ Branch-protection administration reviewed
☐ CI/CD access removed
☐ Deployment permissions removed
☐ Package registry access removed
☐ Code-signing credentials reviewed
☐ SSH keys addressed
☐ API tokens revoked

12. Production Access

For employees with production access:

☐ Production accounts disabled
☐ Administrative roles removed
☐ Database access removed
☐ Emergency access reviewed
☐ VPN access removed
☐ Bastion/jump-host access removed
☐ Kubernetes/container access removed where applicable
☐ Cloud production roles removed
☐ Service ownership transferred

High-risk production access should receive enhanced verification.

13. Privileged Access

For privileged personnel:

☐ Administrator accounts disabled
☐ Privileged roles removed
☐ PAM access removed
☐ Break-glass access reviewed
☐ Shared credentials reviewed
☐ Credentials rotated where necessary
☐ API keys revoked
☐ SSH keys revoked
☐ Certificates reviewed
☐ Secrets reviewed
☐ Ownership transferred

If a departing employee knew a shared secret that remains in use, the organization should assess whether rotation is necessary.

14. SaaS Access

Review relevant SaaS applications, including:

Microsoft 365/Google Workspace
Slack/Teams
CRM
HR systems
Finance systems
Project-management systems
Security platforms
GRC platforms
Customer-support systems
Code repositories
Cloud-management platforms

☐ Account disabled
☐ Application access removed
☐ Group memberships removed
☐ Ownership transferred
☐ API tokens revoked
☐ MFA methods removed
☐ Shared resources reviewed

15. Organizational Information

Before closure, determine what organizational information the employee possesses.

Consider:

☐ Documents
☐ Customer information
☐ Personal data
☐ Source code
☐ Credentials
☐ Security documentation
☐ Contracts
☐ Business plans
☐ Intellectual property
☐ Email
☐ Local files
☐ Cloud files
☐ Removable media

Information should be returned, transferred, retained, or securely deleted according to organizational requirements.

16. Data Return and Deletion

Where applicable:

☐ Organizational information returned
☐ Business documents transferred
☐ Customer information transferred
☐ Local copies removed where authorized
☐ Personal-device copies addressed where permitted and lawful
☐ Cloud-storage copies reviewed
☐ Removable-media copies addressed
☐ Secure deletion performed where required
☐ Evidence retained

The organization should not instruct employees to delete information that must be preserved for legal, audit, security, or investigation purposes.

17. Organizational Assets

Recover applicable assets.

☐ Laptop
☐ Desktop
☐ Mobile phone
☐ Tablet
☐ Access card
☐ Security token
☐ USB/storage media
☐ Monitor
☐ Headset
☐ Other equipment
☐ Physical documents
☐ Other: ______________________

Asset Return Record

Asset ID	Asset	Condition	Returned	Date	Verified By

18. Device Security

For returned devices:

☐ Device received
☐ Device identified
☐ Asset record updated
☐ Security status checked
☐ Organizational information preserved where required
☐ Device securely wiped/reimaged where appropriate
☐ Encryption maintained
☐ Device reassigned or securely disposed

Device handling should preserve evidence if the device is associated with an investigation.

19. Mobile Device Offboarding

Where applicable:

☐ Corporate account removed
☐ MDM enrollment addressed
☐ Organizational applications removed
☐ Organizational data protected
☐ Device returned or BYOD access removed
☐ Remote-wipe considered where appropriate
☐ Certificates removed
☐ Authentication tokens revoked

20. Physical Access

Remove physical access where applicable:

☐ Building access card
☐ Office access
☐ Data-center access
☐ Server-room access
☐ Restricted-area access
☐ Visitor privileges
☐ Physical keys
☐ Security tokens

Verification

21. Email and Collaboration

Determine whether the employee’s business communications need to be retained or transferred.

☐ Mailbox disabled
☐ Mail retention applied
☐ Business communications transferred where appropriate
☐ Shared mailbox ownership transferred
☐ Calendar ownership reviewed
☐ Distribution groups updated
☐ Collaboration memberships removed
☐ Automated forwarding disabled or reviewed

Any monitoring or access to employee communications should follow applicable law, privacy requirements, employment requirements, and organizational procedures.

22. Business Ownership Transfer

Before departure, identify responsibilities that must be transferred.

Examples:

Customer accounts
Supplier relationships
Projects
Production systems
Cloud resources
Security processes
Contracts
Documentation
Reports
Scheduled jobs
Administrative ownership

Ownership Transfer

Responsibility	Previous Owner	New Owner	Transfer Date	Verified

23. Knowledge Transfer

Where appropriate:

☐ Documentation transferred
☐ System knowledge transferred
☐ Operational procedures transferred
☐ Customer information transferred
☐ Supplier information transferred
☐ Security responsibilities transferred
☐ Critical contacts transferred
☐ Outstanding issues transferred

Knowledge transfer should not require the departing employee to disclose passwords or other prohibited secrets.

24. Secrets and Credentials

Identify credentials that may need to be rotated.

☐ Shared passwords
☐ API keys
☐ Access keys
☐ SSH keys
☐ Certificates
☐ Database credentials
☐ Service credentials
☐ CI/CD secrets
☐ Encryption keys
☐ Recovery credentials
☐ Vendor credentials

Rotation Required?

☐ Yes
☐ No
☐ Under Assessment

Rotation Evidence

25. Customer and Supplier Access

Review external relationships managed by the employee.

☐ Customer portals
☐ Supplier portals
☐ Partner systems
☐ External collaboration platforms
☐ Third-party administration
☐ Shared credentials
☐ Customer communication channels

Transfer ownership and revoke access as appropriate.

26. Confidentiality

The departing employee should be reminded of continuing confidentiality obligations where applicable.

Confirm:

☐ Confidentiality obligations communicated
☐ NDA/contract requirements reviewed
☐ Intellectual-property obligations reviewed
☐ Customer confidentiality addressed
☐ Data-protection obligations addressed
☐ Return/deletion obligations communicated

Legal review should be obtained where necessary.

27. Intellectual Property

Review organizational intellectual property associated with the employee.

Examples:

Source code
Designs
Documentation
Product information
Research
Business plans
Customer materials
Security architecture
Proprietary processes

☐ Ownership confirmed
☐ Materials returned/transferred
☐ Personal copies addressed where appropriate
☐ Repository access removed
☐ Relevant credentials revoked

28. Security Incident Check

Before closure, determine whether there are unresolved security concerns involving the departing employee.

☐ No known concern
☐ Security event under review
☐ Security incident under investigation
☐ Policy violation under review
☐ Data exposure under review
☐ Other: ______________________

Where an investigation exists, evidence should be preserved before deletion, device wiping, or other actions that could destroy evidence.

29. Security Violation or Investigation

If the employee is associated with an open security investigation:

☐ Investigation owner notified
☐ Evidence preservation requirements identified
☐ Access decision documented
☐ Relevant systems identified
☐ Required logs preserved
☐ Legal/HR review performed where appropriate
☐ Offboarding coordinated with investigation requirements

Offboarding must not unintentionally destroy evidence.

30. High-Risk Departure

Enhanced controls may be appropriate where the departing employee has:

Privileged access
Production access
Customer data
Source-code access
Cloud administration
Security administration
Financial information
Sensitive intellectual property
Access to critical systems

Possible additional actions:

☐ Immediate access restriction
☐ Immediate credential revocation
☐ Session termination
☐ Token revocation
☐ Secret rotation
☐ Enhanced access review
☐ Additional asset verification
☐ Security investigation
☐ Management escalation
☐ Legal/HR review

Controls should remain proportionate, authorized, and lawful.

31. Remote Employee Offboarding

For remote employees:

☐ Remote access disabled
☐ VPN removed
☐ Cloud access removed
☐ SaaS access removed
☐ Device recovery arranged
☐ Mobile device addressed
☐ Physical access addressed
☐ Organizational information reviewed
☐ Shipping/asset-return process completed
☐ Return verified

32. BYOD Offboarding

Where personal devices were authorized:

☐ Organizational accounts removed
☐ Organizational applications removed
☐ Corporate data removed where permitted
☐ MDM controls removed where applicable
☐ Tokens/certificates revoked
☐ Cloud sessions terminated
☐ Access verified

BYOD actions should follow applicable privacy and employment requirements.

33. Final Access Verification

After offboarding, verify that access has actually been removed.

System	Expected Action	Actual Status	Verified By	Date
Email	Disable
VPN	Revoke
AWS	Revoke
GitHub	Revoke
SaaS	Revoke
Database	Revoke
Production	Revoke

The verifier should use actual system evidence rather than relying only on a checkbox from the person who performed the action.

34. Offboarding Completion Criteria

Offboarding should normally be considered complete when:

☐ Employment/engagement status confirmed
☐ Required access revoked
☐ Privileged access revoked
☐ Cloud access addressed
☐ Source-code access addressed
☐ Production access addressed
☐ SaaS access addressed
☐ Physical access removed
☐ Assets returned
☐ Information transferred/returned/deleted as required
☐ Credentials/secrets addressed
☐ Business ownership transferred
☐ Confidentiality obligations addressed
☐ Security concerns assessed
☐ Evidence recorded
☐ Independent/appropriate verification completed

35. Offboarding Record

Employee: _________________________________

Employee ID: ______________________________

Role: _____________________________________

Department: _______________________________

Manager: __________________________________

Last Working Date: ________________________

Offboarding Risk: __________________________

Access Revocation Date: ___________________

Asset Return Date: _________________________

Verification Date: _________________________

Verified By: ______________________________

Final Status

☐ Complete
☐ Complete with Exception
☐ Pending
☐ Escalated

Comments

36. Offboarding Exceptions

If any required action cannot be completed:

Exception: _________________________________

Reason: ____________________________________

Risk: ______________________________________

Compensating Control: _______________________

Owner: _____________________________________

Due Date: __________________________________

Approval: __________________________________

Exceptions should be formally recorded and should not be hidden by marking the offboarding as complete.

37. Offboarding Register

Maintain a record of completed offboarding activities.

Offboarding ID	Employee	Role	Last Date	Risk	Access Revoked	Assets Returned	Verification	Status

38. Metrics

Management may monitor:

Timeliness

Percentage of offboarding completed on time
Average access-revocation time
Number of delayed revocations
Number of overdue offboarding cases

Security

Former accounts remaining active
Privileged access not revoked
Cloud access not revoked
Source-code access not revoked
Credentials requiring rotation
Assets not returned

Quality

Offboarding exceptions
Reopened cases
Failed verification
Security incidents associated with offboarding

39. Periodic Review

The organization should periodically review offboarding effectiveness.

Review:

☐ Recent leavers
☐ Access-revocation records
☐ Privileged access
☐ Cloud access
☐ SaaS access
☐ Asset-return records
☐ Exceptions
☐ Security incidents
☐ Audit findings
☐ Recurring issues

40. AWS SaaS Startup Example

Scenario

A DevOps engineer leaves an AWS-based SaaS startup.

The engineer had access to:

AWS production
GitHub
CI/CD
Production database
Monitoring platform
Slack
VPN
Corporate email

Offboarding Actions

HR: Confirms final working date.

Manager: Identifies responsibilities and replacement owner.

IT: Disables corporate identity, VPN, email, and collaboration access.

Security: Reviews privileged access.

Cloud Administrator:

Removes AWS access.
Revokes access keys.
Reviews IAM roles.
Terminates active sessions where applicable.

Engineering:

Removes GitHub access.
Removes CI/CD permissions.
Transfers repository ownership.

Database Administrator:

Removes production database access.

Asset Team:

Recovers laptop and security token.

Verification

A second person verifies:

AWS access removed
GitHub access removed
CI/CD access removed
Database access removed
VPN access removed
SaaS access removed
Physical access removed

Audit Trail

Termination → Risk Assessment → Access Inventory → Revocation → Asset Recovery → Credential Review → Ownership Transfer → Verification → Evidence → Closure

41. Startup-Friendly Offboarding Model

A small startup can operate a lightweight but effective process.

Step 1 — HR Notification

Notify IT, Security, and the manager.

Step 2 — Access Review

Identify all important access.

Step 3 — Revoke

Disable accounts and remove access.

Step 4 — Recover

Collect devices and other assets.

Step 5 — Protect

Transfer information and address credentials/secrets.

Step 6 — Verify

Have an appropriate person confirm access is actually gone.

Step 7 — Record

Maintain the evidence.

The process becomes more detailed for privileged users, production users, developers, cloud administrators, and employees handling sensitive information.

42. Common Mistakes

Avoid:

Waiting until the last minute to start offboarding.
Relying only on HR’s account list.
Forgetting SaaS applications.
Forgetting cloud access.
Forgetting GitHub/source-code access.
Forgetting VPN access.
Forgetting physical access.
Forgetting API keys and tokens.
Failing to rotate shared secrets.
Failing to transfer business ownership.
Wiping devices before preserving required evidence.
Deleting accounts when records must be retained.
Treating contractor offboarding differently without assessing risk.
Marking offboarding complete without verification.
Allowing exceptions without documented risk acceptance.
Assuming disabled email means all access is removed.

43. Relationship With Other ISMS Documents

Document	Relationship
Human Resources Security Policy	Defines personnel-security requirements
Joiner-Mover-Leaver Procedure	Manages personnel lifecycle
Access Management Procedure	Controls account and access lifecycle
Employee Offboarding Checklist	Operationalizes offboarding
Asset Return Procedure	Controls asset recovery
Personnel Security Audit Checklist	Tests offboarding effectiveness
Security Policy Violation Register	Records relevant violations
Security Investigation Procedure	Handles investigations
Confidentiality Agreement	Defines confidentiality obligations
Information Classification Policy	Defines information protection
Cloud Access Review Checklist	Reviews cloud access
Source Code Access Review Checklist	Reviews repository access
Supplier Offboarding Checklist	Handles third-party departures
Corrective Action Tracker	Tracks offboarding-related remediation
Risk Register	Records significant residual risks

44. ISO 27001 Connection

Secure employee offboarding supports the organization’s ability to protect information when personnel leave or change roles.

The exact form of an Employee Offboarding Policy is not a universally prescribed ISO/IEC 27001 document. The organization should establish appropriate personnel-security, access-control, asset-return, confidentiality, information-protection, and offboarding arrangements based on its:

ISMS scope
Risk assessment
Personnel roles
Access requirements
Information handled
Applicable controls
Legal/regulatory requirements
Customer requirements
Contractual obligations

The organization should be able to demonstrate that personnel access and responsibilities are appropriately addressed throughout the employment lifecycle.

45. Final Audit Checklist

Before closing an employee offboarding case:

☐ Authorized termination notification received
☐ Final date confirmed
☐ Offboarding risk assessed
☐ Access inventory completed
☐ Corporate account disabled
☐ Email addressed
☐ VPN removed
☐ MFA addressed
☐ Cloud access removed
☐ AWS/IAM access reviewed where applicable
☐ Source-code access removed
☐ CI/CD access removed
☐ Production access removed
☐ Database access removed
☐ SaaS access removed
☐ Privileged access removed
☐ API keys/tokens addressed
☐ Shared secrets reviewed
☐ Physical access removed
☐ Assets returned
☐ Organizational information transferred/returned
☐ Confidentiality obligations addressed
☐ Business ownership transferred
☐ Security investigation considered
☐ Required evidence preserved
☐ Exceptions documented
☐ Access revocation independently/appropriately verified
☐ Offboarding record completed
☐ Case closed

46. Final Audit Trail

For every significant employee departure, the organization should be able to demonstrate:

When did the employee leave?
Who authorized the offboarding?
What systems and information could the employee access?
What was the employee’s security risk?
When was access revoked?
Was privileged access removed?
Was cloud and production access removed?
Were source-code and SaaS permissions removed?
Were physical assets recovered?
Were credentials, tokens, and shared secrets addressed?
Was organizational information returned or transferred?
Were confidentiality obligations addressed?
Was any security investigation preserved?
Who verified that access was actually removed?
What evidence proves completion?
Were exceptions and residual risks properly handled?

Final Principle

Employee offboarding is complete only when the organization can demonstrate that the person’s access, information, assets, responsibilities, and security dependencies were appropriately addressed—and that the remaining risk has been identified, treated, and verified.