# Offboarding Security Checklist: [Organization name]

> Security checklist and procedure for people who leave the organization
> or change role: access revocation timed by risk, return of assets,
> handling of data on devices and in accounts, knowledge transfer,
> continuing confidentiality duties, and special handling of privileged
> and urgent leavers. It supports ISO/IEC 27001:2022 + Amd 1:2024, Annex
> A controls A.5.11 (return of assets), A.6.5 (duties after leaving or
> changing role), A.5.16 to A.5.18 (identity lifecycle, authentication
> information, access rights), A.8.2 (privileged access rights), A.7.10
> and A.7.14 (storage media, secure disposal or re-use of equipment) and
> A.8.10 (information deletion), with guidance in ISO/IEC 27002:2022.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- When to use: as the security standard behind every leaver and mover
  ticket. The operational ticket checklist for IT is
  `ops/onboarding-checklist` (joiner, mover, leaver, request ID
  JML-YYYY-NNNN); this template sets the security rules, timings and
  evidence that ticket must meet, and adds the steps outside IT (HR,
  legal, managers, suppliers).
- Fill first: section 3 (leaver types and revocation timing) and section
  5 (access revocation list per system). Then agree the HR trigger in
  section 4 so IT learns about leavers on time.
- Main pitfall: late HR notification. Most orphaned accounts come from
  leavers that IT never heard about, contractors whose engagement simply
  ended, and shared or service accounts the leaver knew the secret for.
- Second pitfall: treating movers as low risk. Movers keep old access
  ("access creep") unless old rights are removed on the move date.
- Related templates: `ops/onboarding-checklist`, `ops/access-review`,
  `isms/access-control-policy`, `security/privileged-access-standard`,
  `security/secrets-management-standard`, `compliance/asset-inventory`,
  `isms/equipment-disposal-reuse-record`, `isms/confidentiality-nda`,
  `isms/security-disciplinary-process`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: This document is the standard. Each completed leaver or mover checklist is a record, kept with the ticket. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-053 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@head-of-people], [@head-of-it], [@ciso], [@general-counsel] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, A.5.11, A.6.5, A.5.16 to A.5.18, A.8.2, A.7.10, A.7.14, A.8.10; guidance ISO/IEC 27002:2022 |
| Identity source of truth | [HR system feeding the identity provider] |
| Ticket system and request ID | [Ticketing system], JML-YYYY-NNNN |
| Next scheduled review | YYYY-MM-DD (at least annually and when a new critical system is added) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS owner | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| HR | [@head-of-people] | [Approved] | YYYY-MM-DD |
| IT | [@head-of-it] | [Approved] | YYYY-MM-DD |
| Security | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@isms-manager] | First approved version |
| 1.1 *(Example)* | YYYY-MM-DD | [@isms-manager] | Added contractor end-date trigger after access review found 3 orphaned accounts |

## Contents

1. Purpose and scope
2. Roles and responsibilities
3. Leaver types and revocation timing
4. Triggers and notice
5. Leaver checklist
6. Mover checklist
7. Privileged and urgent leavers
8. Continuing duties after leaving
9. Verification and access review
10. Size tiers
11. Records and evidence
12. Metrics
13. References

## 1. Purpose and scope

<!-- Guidance: Name every population that leaves. Questions to answer: are contractors, interns, board members, supplier personnel and service accounts owned by the leaver covered? Pitfall: offboarding only employees. -->

This checklist makes sure that when a person leaves [Organization name]
or changes role, access is removed on time, organizational assets and
information are returned or securely deleted, knowledge is handed over,
and the person knows which security duties continue after the change.

It covers employees, contractors, interns, agency staff, board members
with accounts, and supplier personnel with named access. It also covers
accounts, keys and secrets that the person owned or knew, including
shared, service and break-glass credentials.

## 2. Roles and responsibilities

<!-- Guidance: Offboarding fails at the hand-offs. Give each step one owner. -->

| Role | Responsibility |
|---|---|
| HR | Records the leaving or move date in the HR system, opens the JML ticket, runs the exit meeting, reminds the person of continuing duties |
| Line manager | Confirms systems and assets used, arranges knowledge transfer, reassigns ownership of data, tasks and assets |
| IT service desk | Disables and removes access per section 5, collects and processes devices |
| System and application owners | Remove access in systems not connected to the identity provider, confirm removal in the ticket |
| Security team | Handles privileged and urgent leavers, rotates shared secrets, reviews unusual activity before departure where policy and law allow |
| Supplier manager | Obtains notice from suppliers when their personnel leave or rotate off the account |
| Legal counsel | Advises on legal holds, disputes and post-employment obligations |
| ISMS manager | Owns this standard, monitors metrics, samples completed tickets |

## 3. Leaver types and revocation timing

<!-- Guidance: Time revocation by risk, not by convenience. The timings are *Example* values; set your own and keep them consistent with the access control policy (DOC-ISMS-041). An auditor will sample leavers and compare the leaving time with the disable time in the identity provider log. -->

| Type | When it applies | Disable primary identity | Remove all other access | Rotate known shared secrets |
|---|---|---|---|---|
| L1 Standard leaver | Planned departure, no privileged access | By end of last working day *(Example)* | Within [2] business days | Not normally needed |
| L2 Privileged leaver | Holds admin, production, security tooling, key management or payment authority | Privileged roles removed at notice or reassigned, identity disabled at end of last day | Same day as identity disable | Within [1] business day |
| L3 Urgent leaver | Dismissal, suspension, resignation with risk indicators, dispute | Immediately, coordinated with HR before or at the moment the person is informed | Same time | Immediately, before or at notification |
| L4 Contractor or supplier end | Engagement end date reached or supplier notifies rotation | On end date or within [1] business day of supplier notice | Within [1] business day | Not normally needed (privileged contractors and supplier staff are handled as L2) |
| L5 Long absence | Absence over [30] days (for example extended leave) | Suspend, do not delete | Review on return | Not normally needed |

```mermaid
flowchart TD
  A["Leaving, role change or long absence recorded"] --> B{"Type of change"}
  B -- "Role change" --> M["Section 6: mover checklist"]
  B -- "Long absence" --> L5["L5 Long absence: suspend, review on return"]
  B -- "Leaving" --> C{"Risk indicators or dismissal?"}
  C -- Yes --> L3["L3 Urgent: disable immediately, rotate secrets"]
  C -- No --> D{"Privileged access?"}
  D -- Yes --> L2["L2 Privileged: remove privileges at notice"]
  D -- No --> E{"Contractor or supplier?"}
  E -- Yes --> L4["L4 Contractor or supplier end"]
  E -- No --> L1["L1 Standard leaver"]
  L1 --> V["Section 9: verification"]
  L2 --> V
  L3 --> V
  L4 --> V
  M --> V
```

## 4. Triggers and notice

<!-- Guidance: Automate the trigger from the HR system where possible. Pitfall: contractors with no HR record and no end date. -->

- HR records the leaving date as soon as it is known; the HR system or HR
  opens the JML ticket at least [5] business days before the last day for
  L1 and L2.
- Every contractor and supplier account has an end date at creation;
  accounts without an end date are reported weekly to the IT lead.
- For L3, HR contacts the security team and IT lead directly by
  [phone or secure channel], not through the ticket queue, and agrees the
  exact time of revocation.
- Supplier contracts require notice of personnel changes within [1]
  business day (DOC-ISMS-068).

## 5. Leaver checklist

<!-- Guidance: Use this as the checklist in each leaver ticket. Mark steps that do not apply as "N/A" with a reason, never leave them blank. Personal data in the ticket should be limited to an employee or contractor ID. -->

### 5.1 Before the last day

| ID | Step | Owner | Done | Evidence |
|---|---|---|---|---|
| OFF-01 | Confirm leaver type L1 to L4 and last day in the ticket | HR | [ ] | Ticket field |
| OFF-02 | List systems, data stores, shared mailboxes and assets used by the person (from the identity provider, asset inventory DOC-ISMS-012 and the manager) | Line manager | [ ] | List attached |
| OFF-03 | Plan knowledge transfer: open work, procedures, credentials known, customer and supplier contacts, scheduled jobs | Line manager | [ ] | Handover note |
| OFF-04 | Reassign ownership of documents, repositories, cloud resources, tickets, risks and controls the person owned (update DOC-ISMS-016 and DOC-ISMS-033 owners) | Line manager, ISMS manager | [ ] | Ownership updated |
| OFF-05 | For L2: remove or reassign privileged roles, transfer on-call duties | Security team | [ ] | Privileged access log |
| OFF-06 | Check for legal holds before deleting any data | Legal counsel | [ ] | Hold check recorded |

### 5.2 On the last day

| ID | Step | Owner | Done | Evidence |
|---|---|---|---|---|
| OFF-07 | Disable the primary identity and revoke active sessions and tokens | IT service desk | [ ] | Identity provider log time |
| OFF-08 | Remove MFA factors and registered devices, revoke VPN and remote access certificates | IT service desk | [ ] | Identity provider record |
| OFF-09 | Collect laptop, phone, tokens, badges, keys and removable media, check against the asset inventory | IT service desk, facilities | [ ] | Asset return record |
| OFF-10 | Disable physical access badge and alarm codes | Facilities | [ ] | Access control system log |
| OFF-11 | Remove the person from BYOD management or wipe organization data from personal devices (DOC-ISMS-058) | IT service desk | [ ] | MDM record |
| OFF-12 | Exit meeting: remind of continuing duties (section 8), collect signed declaration of return and deletion of organization information | HR | [ ] | Signed declaration |

### 5.3 After the last day

| ID | Step | Owner | Done | Evidence |
|---|---|---|---|---|
| OFF-13 | Remove access in systems not connected to the identity provider, including SaaS tools, code hosting, cloud consoles, finance and customer portals | System owners | [ ] | Owner confirmation per system |
| OFF-14 | Rotate shared, service and break-glass secrets the person knew (`security/secrets-management-standard`) | Security team | [ ] | Vault rotation log |
| OFF-15 | Set mailbox forwarding or auto-reply per policy, then convert or delete per retention rules | IT service desk | [ ] | Ticket note |
| OFF-16 | Wipe and re-image or dispose of returned devices and media (DOC-ISMS-057) | IT service desk | [ ] | Wipe certificate or disposal record |
| OFF-17 | Delete or archive the account and personal data after the retention period (`data/data-retention-deletion-standard`) | IT service desk | [ ] | Deletion log |
| OFF-18 | Close the ticket after verification (section 9) | IT lead | [ ] | Ticket closure |

Unreturned assets: escalate to HR within [2] business days, remotely lock
or wipe the device where possible, and record the asset as lost in the
asset inventory and, if it may hold Confidential information, as a
security event (`isms/security-event-reporting-procedure`).

## 6. Mover checklist

<!-- Guidance: A role change is a leaver for the old role and a joiner for the new one. The order matters: remove before add, or at least on the same day. -->

| ID | Step | Owner | Done | Evidence |
|---|---|---|---|---|
| MOV-01 | Record the move date and new role in the HR system, ticket opened | HR | [ ] | Ticket |
| MOV-02 | Compare old and new role bundles, list access to remove | IT service desk | [ ] | Bundle comparison |
| MOV-03 | Check whether the new role needs a higher screening level (`isms/personnel-screening-procedure`) | HR | [ ] | Screening record |
| MOV-04 | Remove old access on the move date, with an agreed handover period of no more than [10] business days for named items, approved by the new manager | IT service desk | [ ] | Identity provider log |
| MOV-05 | Grant new access per the new role bundle | IT service desk | [ ] | Provisioning record |
| MOV-06 | Reassign ownership of assets, risks and controls held in the old role | Old line manager | [ ] | Ownership updated |
| MOV-07 | Remind the person of confidentiality duties for information from the old role that the new role must not use | HR or manager | [ ] | Note in ticket |

## 7. Privileged and urgent leavers

<!-- Guidance: These cases carry most of the risk. Agree the steps in advance with HR so they can be executed in minutes. -->

For L2 and L3:

1. Security and IT prepare the revocation list in advance (privileged
   accounts, cloud root and admin roles, API keys, SSH keys, code signing
   and other keys in the key register DOC-ISMS-070, vault access, on-call
   tools).
2. For L3, revocation happens at the agreed time, before or at the moment
   the person is told. HR holds the meeting; IT confirms revocation in
   real time.
3. Rotate every secret the person knew, starting with production and
   customer-facing credentials.
4. Where policy and law allow, the security team reviews recent activity
   of the account (bulk downloads, forwarding rules, new keys) and opens a
   security event if anything unusual is found. Any evidence is preserved
   under `security/forensic-evidence-record`.
5. If a disciplinary matter is involved, follow `isms/security-disciplinary-process`.

```mermaid
sequenceDiagram
  participant HR as HR
  participant SEC as Security team
  participant IT as IT service desk
  participant P as Person leaving
  HR->>SEC: Urgent leaver notice and agreed time
  SEC->>IT: Prepared revocation list
  IT->>IT: Disable identity and privileged roles at agreed time
  IT-->>HR: Revocation confirmed
  HR->>P: Exit meeting and continuing duties reminder
  SEC->>SEC: Rotate known secrets and review recent activity
  SEC-->>HR: Completion and any security events raised
```

## 8. Continuing duties after leaving

<!-- Guidance: For A.6.5, an auditor wants to see that confidentiality and similar obligations do not end at the exit interview: what still binds the person, when they heard it, and what you would do if they ignored it. Say which duties continue, for how long, and in which document they are written. -->

Remind every leaver, in writing, that:

- confidentiality obligations continue as set in the confidentiality
  agreement or employment contract (DOC-ISMS-051), including for trade
  secrets and personal data for as long as they keep that status;
- organization information must not be kept on personal devices, personal
  email or personal cloud storage, and any found later must be deleted and
  reported;
- intellectual property terms in the contract continue;
- the person must not use remembered credentials or access paths;
- the person may be contacted for knowledge transfer questions for
  [period] where agreed.

Do not include unlawful restrictions (for example on reporting to
authorities or whistleblowing); legal counsel confirms the reminder text
per country.

## 9. Verification and access review

<!-- Guidance: Verification closes the loop. The periodic access review (`ops/access-review`) is the safety net that finds what the ticket missed. -->

- The IT lead checks that every step is complete or N/A with reason
  before closing the ticket.
- Weekly: reconcile HR leavers and contractor end dates against active
  accounts in the identity provider; any active account of a leaver is
  disabled at once and recorded as a security event.
- Quarterly: the access review (`ops/access-review`) includes systems not
  connected to the identity provider and shared accounts.
- The ISMS manager samples [5] completed leaver tickets per quarter and
  compares leaving time with disable time.

| Ref | Ticket | Type | Last day | Identity disabled | Within target | Note |
|---|---|---|---|---|---|---|
| OFF-VER-001 *(Example)* | JML-2026-0141 | L1 | 2026-05-14 17:30 | 2026-05-14 18:02 | Yes | |
| OFF-VER-002 *(Example)* | JML-2026-0152 | L2 | 2026-05-21 17:00 | 2026-05-21 17:05 | Yes | Two cloud keys rotated next morning, within 1 business day |
| OFF-VER-003 *(Example)* | JML-2026-0160 | L4 | 2026-05-29 | 2026-06-03 | No | Supplier gave late notice, corrective action raised with supplier |

## 10. Size tiers

<!-- Guidance: These are the library's working tiers. -->

| Aspect | Small: Quillmere Analytics Ltd | Medium: Quillmere Health Systems | Large: Quillmere Group |
|---|---|---|---|
| Population | 46 people (38 employees, 8 contractors) | 320 staff, colocation and support suppliers | 2,400 staff at 6 sites in 4 countries |
| Trigger | Office manager opens the ticket, contractor end dates in the identity provider | HR system integration to the identity provider | HR system feeds per country, automated disable on end date |
| Systems outside the identity provider | Small list kept by the ISMS manager (0.5 FTE) | Application owner list, quarterly confirmation | Per site lists including OT systems at the 3 plants, local OT admins confirm |
| Privileged leavers | Head of Engineering Operations rotates cloud keys | 3-person security team handles L2 and L3 | CISO office playbook, site security leads |
| Physical return | Single office plus courier return for remote staff | Two offices and the colocation suite access list | Six sites, badge systems per site, local facilities teams |
| Verification | Monthly reconciliation of all accounts | Weekly automated report, quarterly sample | Weekly per country, group dashboard |

## 11. Records and evidence

<!-- Guidance: Link these records in the control evidence matrix (`isms/control-evidence-matrix`, DOC-ISMS-033). Auditors usually sample leavers from the HR list and ask for these records. -->

| Record | Proves | Owner | Location | Retention |
|---|---|---|---|---|
| JML ticket with completed checklist | Steps done for each leaver and mover | IT service desk | Ticketing system | [2] years after closure |
| Identity provider disable logs | Timely revocation | IT | Identity provider, log archive | As set in `security/security-logging-standard` |
| Asset return records | Assets returned (A.5.11) | IT, facilities | Asset inventory DOC-ISMS-012 | Life of asset plus [1] year |
| Signed return and deletion declaration, duties reminder | Continuing duties communicated (A.6.5) | HR | HR system | Employment plus [period] per DOC-ISMS-014 |
| Secret rotation logs | Shared credentials changed | Security team | Secrets vault | [1] year |
| Wipe certificates and disposal records | Secure handling of returned equipment | IT | DOC-ISMS-057 | As that record |
| Weekly reconciliation and quarterly sample results | Verification operates | ISMS manager | [Location] | [3] years |

## 12. Metrics

<!-- Guidance: Report through the measurement programme (DOC-ISMS-080). Targets are examples. -->

| Metric | Target *(Example)* |
|---|---|
| Leavers with identity disabled within the target for their type | 100% for L2 and L3, 98% or more for L1 and L4 |
| Active accounts found for people who have left | 0 |
| Assets returned or remotely wiped within [10] business days | 100% |
| Movers with old access removed within the agreed handover period | 95% or more |

## 13. References

<!-- Guidance: Cite editions exactly. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html, Amd: https://www.iso.org/standard/88435.html | 2022, Amd 1 2024-02-23 | Controls A.5.11, A.6.5, A.5.16 to A.5.18, A.8.2, A.7.10, A.7.14, A.8.10 |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | 2022 | Guidance on return of assets and post-employment duties |
| NIST SP 800-53 Rev. 5 (release 5.2.0, August 2025), controls PS-4 Personnel Termination and PS-5 Personnel Transfer | Rev. 5 | Optional crosswalk |

Related templates: `ops/onboarding-checklist`, `ops/access-review`,
`isms/access-control-policy`, `security/privileged-access-standard`,
`security/secrets-management-standard`, `isms/cryptographic-key-register`,
`compliance/asset-inventory`, `isms/endpoint-device-byod-policy`,
`isms/equipment-disposal-reuse-record`, `isms/confidentiality-nda`,
`isms/personnel-screening-procedure`, `isms/security-disciplinary-process`,
`isms/security-event-reporting-procedure`, `data/data-retention-deletion-standard`,
`security/security-logging-standard`, `isms/control-evidence-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 including Amd 1:2024, Annex A
controls A.5.11, A.6.5, A.5.16 to A.5.18, A.8.2, A.7.10, A.7.14 and
A.8.10, with guidance in ISO/IEC 27002:2022. The leaver types, timings,
checklists, examples and guidance are original wording; no ISO or IEC text
is reproduced. ISO and IEC standards are copyrighted: obtain the official
standard from ISO or your national standards body
(https://www.iso.org/standard/82875.html). Check the current edition and
amendments before use, and confirm employment-related steps with legal
counsel in each country. This is a documentation format, not legal
advice. Template licence: MIT.