Finding that someone who has left still holds working access is an incident in its own right, whether or not anyone has used it yet. The discovery usually comes from an access review, an audit sample, a sign-in alert on a disabled user or a colleague who notices a former team member still in a chat channel. Most cases turn out to be a missed offboarding step, but the response has to establish that rather than assume it, and it has to find every other leaver the same gap affected. This playbook template gives [Organisation] a repeatable response for identity, security and HR teams, with roles, decision points and the evidence to keep. It complements the insider playbooks: where the former employee is shown to have taken data or caused damage, it hands over to them.
How to use this template
- Adopt it as a sub-playbook of [Organisation]'s incident response plan. See the Incident Response Plan Template.
- Treat every finding as two problems: the individual case (one person, one access path) and the control failure (why offboarding missed it, and who else it missed). Sections 3 to 6 handle the first, section 5.3 and section 8 the second.
- Replace the bracketed values ([Organisation], [Name], time limits in square brackets) and agree them with HR and legal before first use. Time limits shown are NHI Mgmt Group recommendations, not regulatory requirements.
- Record every decision in the case log with who decided and on what evidence.
- Prevention lives elsewhere. The Employee Offboarding Security Guide and the Employee Offboarding Security Checklist describe how leavers should be processed. This playbook is for when that has already failed.
1. Scope and triggers
1.1 This playbook applies when a former employee, contractor, intern or supplier staff member of [Organisation] is found to hold any access path that still works after their leaving date, whether or not it has been used.
1.2 Access paths in scope:
| Access path | Why it survives offboarding | Where to check |
|---|---|---|
| Directory account still enabled | HR leaving date never reached the identity provider, or the leaver was a contractor outside the HR feed | Identity provider user list compared with the HR leaver report |
| Live sessions and refresh tokens | Account disabled but sessions not revoked | Identity provider sign-in logs, application session lists |
| Local SaaS or application accounts | Application not behind single sign-on or not provisioned by SCIM | Application user lists against the SaaS register |
| Personal access tokens, SSH keys, API keys | Created by the person and invisible to the identity provider | Code platform token lists, cloud IAM credential reports |
| OAuth grants to third-party apps | Refresh tokens issued to an app keep working independently of the user's password | Identity provider and SaaS app consent lists |
| Shared and service credentials the person knew | Never rotated when they left | Vault access history, secrets inventory, service account owner fields |
| Signing keys and certificates they could read | Keys copied to laptops or build machines | Key management service access logs, certificate inventory |
| Remote access and physical access | VPN, privileged access, third-party portals or badges run outside the identity provider | VPN and badge system user lists |
| Mailbox rules and delegations | Forwarding to a personal address set before departure | Mail audit log, transport and inbox rules |
1.3 Triggers: an access review or audit finding; a sign-in attempt, API call or key use attributed to a leaver; a leaver report from an application owner; the former employee contacting [Organisation] about access they still have; a third party reporting activity from a leaver's account; a reconciliation job flagging accounts with no active HR record.
1.4 Hand-offs. If evidence shows the former employee copied data, switch to the Insider Data Theft Response Playbook. If they changed or destroyed systems, switch to the Insider Sabotage Response Playbook. If someone other than the former employee is using the account, switch to the Account Takeover Response Playbook. Record the switch and keep this case open for section 5.3.
2. Roles and contacts
| Role | Named lead | Responsibilities |
|---|---|---|
| Incident lead (security) | [Name, phone] | Opens the case, owns the case log, decides severity and hand-offs |
| Identity administrator | [Name] | Account, session, token and key actions; produces the access inventory for the person |
| Security analyst | [Name] | Reviews activity after the leaving date, preserves logs, writes the technical findings |
| Application and system owners | [Names by system] | Confirm local accounts and what the person could reach in each system |
| HR business partner | [Name] | Confirms leaving date, exit circumstances and any restrictive terms |
| Legal counsel | [Name] | Contact with the former employee, law enforcement referral, contractual and notification duties |
| Data protection officer | [Name] | Personal data breach assessment and record |
3. Detection and triage
3.1 Open the case with a case number, the trigger, the person's identity, their leaving date as recorded by HR and the access path found. Restrict the case to the team in section 2.
3.2 Confirm the facts with HR. Check the leaving date, whether the departure was voluntary, whether the person is now with a competitor or supplier, and whether they were rehired or retained as a contractor. A rehire or consultancy arrangement can make the access legitimate: if so, record it, correct the records and close.
3.3 Build the access inventory for the person across every row of the table in 1.2. Do this before you remove anything, so that the list of what existed is complete and evidenced.
3.4 Establish whether the access was used after the leaving date. Pull logs from the leaving date (or the last day of legitimate work, if earlier) to now:
| Question | Evidence | ATT&CK reference |
|---|---|---|
| Did anyone sign in as the person? | Identity provider and application sign-in logs: source IP, device, location, MFA method | T1078 Valid Accounts; T1078.004 Cloud Accounts |
| Were their tokens or keys used? | Code platform audit logs, cloud API logs (for AWS, the IAM access key last used date and CloudTrail events) | T1550.001 Application Access Token |
| Did forwarding or delegation move mail? | Mail audit log, message trace | T1114.003 Email Forwarding Rule |
| Were new credentials or accounts created? | Directory and cloud audit logs for credential and account changes by or for the person | T1098 Account Manipulation |
3.5 Classify the case:
| Class | Definition | Default severity |
|---|---|---|
| A. Dormant | Access existed but logs show no use after the leaving date | Low, raised to Medium for privileged or production access |
| B. Benign use | Used by automation or a colleague (for example a script running as the person) with no access by the former employee | Medium: this is also a shared-credential finding |
| C. Used by the former employee | Activity attributable to the person after the leaving date | High |
| D. Used by an unknown party | Activity from sources not linked to the person or [Organisation] | High, hand off to account takeover response |
| E. Cannot tell | Logs missing or retention expired for the period | Treat as C until shown otherwise |
3.6 Decision (incident lead): severity, whether to hand off under 1.4, and whether legal and the DPO join now. Any class C, D or E case brings in legal and the DPO immediately.
4. Containment
4.1 Preserve first. Export the audit logs identified in 3.4 to protected storage, record hashes and who exported what, and place a hold on the person's mailbox and files if a class C or E case may lead to legal action. Many platforms keep audit logs for a fixed period only.
4.2 Decision (incident lead): remove everything now, or deactivate in stages. For class C and D, remove all access at once. For class A and B where automation depends on the person's credentials, deactivate in a reversible way first, so a broken job can be restored while it is moved to a service identity.
4.3 Containment actions, using each platform's own documented steps (platforms listed alphabetically):
- AWS: set each of the person's IAM access keys to Inactive (reversible), check the last used information, then delete once nothing depends on them. Remove console passwords and the IAM user, and check for roles the person could assume.
- GitHub: remove the person from the organisation, and as an organisation owner review and revoke fine-grained personal access tokens with access to the organisation under Settings, Personal access tokens, Active tokens. GitHub notes that SSH keys created by a revoked token keep working, so review SSH and deploy keys separately. That view lists fine-grained tokens, so also set an organisation personal access token policy that restricts classic tokens. See the GitHub Personal Access Tokens Security Guide.
- Google Workspace: Google's leaver steps include changing the password, removing recovery email and phone, revoking OAuth 2.0 application tokens, resetting sign-in cookies, revoking security keys and app passwords, wiping mobile devices or their work data, then moving data and deleting the account.
- Microsoft Entra ID: clear Account enabled, select Revoke sessions and disable the user's registered devices. Microsoft notes that Revoke sessions revokes refresh tokens but does not end access tokens already issued, which stay valid until they expire (one hour by default) unless the resource supports Continuous Access Evaluation, and that applications holding their own session cookies must end those sessions themselves. In hybrid environments Microsoft advises disabling the on-premises account and resetting its password twice.
4.4 Rotate what the person knew, not just what they owned. Shared passwords, service account secrets, break-glass credentials and signing keys the person could read are rotated in class C, D and E cases, and for privileged or production access in every class. Signing keys matter most: a key copied before departure lets the holder mint tokens your services accept. The Coupang breach involved a former engineer who kept a token signing key and used it for months after leaving. See the NHI Offboarding and Decommissioning Guide.
4.5 Remove persistence: mailbox forwarding rules and delegates, OAuth app consents, scheduled jobs and automation running under the person's identity, VPN and privileged access entries, and physical badges.
5. Eradication
5.1 Verify from the application side. Test that each access path in the inventory now fails, from the target system, not only from the identity provider. Record the test and its result against each row.
5.2 Move dependent automation found in class B to a service identity with a named owner. Do not re-enable the leaver's account to fix a broken job.
5.3 Find the others. A retained-access finding is evidence of a process gap. Within [5] working days, run a look-back across every leaver in the last [12] months for the same access path and the same system, and across every access path for leavers from the same team or contract. Each further hit is logged against this case and triaged under section 3. The Orphaned and Dormant Accounts guide describes the reconciliation queries.
6. Recovery
6.1 Transfer ownership of the person's data, repositories, service accounts and integrations to named current owners.
6.2 Restore any service broken by containment from the new service identity, and confirm with the business owner.
6.3 For class C, legal decides on contact with the former employee: a written request to confirm deletion of [Organisation] data and return of devices and credentials, with undertakings where justified. In the UK, using access you know to be unauthorised can be an offence under section 1 of the Computer Misuse Act 1990. See the UK Computer Misuse Act Guide. Law enforcement referral is a legal and executive decision.
7. Communication and notification
| Audience | Owner | When |
|---|---|---|
| Executive sponsor | Incident lead | Class C, D and E cases on declaration; class A and B in the monthly report |
| Data protection regulator | DPO | Where personal data was accessed and the breach is not unlikely to result in a risk to individuals: under UK GDPR and EU GDPR Article 33, without undue delay and where feasible within 72 hours of becoming aware |
| Internal breach record | DPO | Every personal data breach is documented under Article 33(5), including those not notified |
| Affected individuals | DPO and legal | Where the breach is likely to result in a high risk to them (Article 34) |
| Customers and partners by contract | Legal and account owners | As contracts and sector rules require |
| HR and line management | Incident lead | Factual findings on the process gap, without blame on individuals |
7.1 A dormant account with access to personal data is not automatically a reportable breach: the DPO records the assessment and the reasoning either way. See the Data Breach Notification Checklist.
8. Post-incident review
8.1 Within [10] working days of closure, hold a blameless review. Record the time from leaving date to discovery, from discovery to containment, and which offboarding step failed.
8.2 Answer these questions:
- Did the leaving date reach the identity provider, and on time? Were contractors and supplier staff in the feed?
- Was the system in the SaaS register and behind single sign-on or SCIM? See the SaaS deprovisioning guide.
- Were the person's personal tokens, keys and OAuth grants listed against their identity before they left?
- Were shared secrets they knew rotated at exit?
- Did the last access review include this system, and did the reviewer have the leaver status?
- Were logs retained long enough to answer section 3.4?
8.3 Track: leavers with any access path live after the leaving date (target zero), median time from leaving date to discovery, look-back hits per case, percentage of leavers whose personal tokens and keys were revoked at exit, and percentage of cases where logs covered the full period.
Implementation guidance
- Run reconciliation, not only offboarding. A scheduled job that compares HR leavers with accounts, tokens and keys in each system finds class A cases before an attacker does. NIST SP 800-53 PS-4 Personnel Termination and AC-2(3) Disable Accounts set the control expectation.
- Alert on use after leaving. Any sign-in attempt on a disabled leaver account, or any API call using a key or token owned by a leaver, should open a case under this playbook automatically.
- Prefer reversible deactivation for automation. Deactivating before deleting, as AWS recommends for access keys, lets you restore a broken job without re-enabling the person.
- Size by organisation. A small organisation can run this with the IT lead as incident lead and external legal support, using a spreadsheet inventory per leaver. A large organisation should feed leaver status into its IGA platform and SIEM and run the look-back in 5.3 as a query rather than a manual exercise.
- Exercise it yearly with a class B scenario (automation running as a leaver) and a class C scenario.
| Playbook section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| 1. Triggers and reconciliation | PR.AA-01, DE.CM-03 | AC-2, PS-4, PS-5 |
| 3. Detection and triage | RS.AN-03 | AU-6, IR-4 |
| 4. Containment and evidence | RS.MA-01, RS.AN-06 | AC-2(3), IR-4, PS-4 |
| 5. Eradication and look-back | PR.AA-05 | AC-2 |
| 6. Recovery | RC.RP-01 | IR-4 |
| 7. Communication | RS.CO-02 | IR-6 |
References: Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID · Google Workspace: Maintain data security after an employee leaves · GitHub Docs: Reviewing and revoking personal access tokens in your organization · GitHub Docs: Removing a member from your organization · AWS: Update access keys · legislation.gov.uk: UK GDPR Article 33 · legislation.gov.uk: UK GDPR Article 34 · legislation.gov.uk: Computer Misuse Act 1990, section 1 · NIST: SP 800-53 Rev. 5
This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Joiner-Mover-Leaver Guide · OWASP NHI Top 10 NHI1 Improper Offboarding Guide · Insider Threat and Identity Guide · Access Reviews Guide