---
status: template
playbook-section: 70
title: "Staff Offboarding Checklist (Data Access & Security)"
last-reviewed: "[FILL IN: YYYY-MM-DD]"
---

# Staff Offboarding Checklist (Data Access & Security)

> **Template status** — fill every `[FILL IN: …]` marker before use.

> **Not code-enforced** — access revocation, device return, and data-handover steps are operational controls implemented outside the application codebase. The consumer is responsible for integrating this checklist into their HR and IT offboarding workflow and ensuring it is completed before the final day.

---

## 1. Purpose & Scope

This checklist ensures that all access, devices, and personal data are securely handled when an employee, contractor, or third-party leaves `[FILL IN: organisation name]` or changes role.

**Owner:** `[FILL IN: role — e.g., HR / People Ops + IT]`

**Trigger:** Employment or engagement termination (voluntary or involuntary), role transfer requiring access scope change, contractor end-of-engagement.

---

## 2. Before Final Day — Immediate Actions (Involuntary / High-Risk Departure)

> Complete this section on the same day for involuntary terminations or where data-exfiltration risk is elevated.

| #   | Task                                                                                   | Owner                    | Done |
| --- | -------------------------------------------------------------------------------------- | ------------------------ | ---- |
| 1   | Suspend IdP account (`[FILL IN: provider]`) — do NOT delete yet (preserve audit trail) | `[FILL IN: IT]`          | ☐    |
| 2   | Revoke active sessions / tokens for all systems                                        | `[FILL IN: IT]`          | ☐    |
| 3   | Rotate any shared secrets the individual had access to: `[FILL IN: list]`              | `[FILL IN: engineering]` | ☐    |
| 4   | Preserve a copy of the departing individual's work output per data-retention policy    | `[FILL IN: manager]`     | ☐    |

---

## 3. Final Day — Access Revocation

| #   | System / tool                                                                       | Action                          | Confirmed by | Done |
| --- | ----------------------------------------------------------------------------------- | ------------------------------- | ------------ | ---- |
| 1   | `[FILL IN: e.g., GitHub org]`                                                       | Remove from org / teams         | `[FILL IN:]` | ☐    |
| 2   | `[FILL IN: e.g., Payload CMS admin]`                                                | Delete or deactivate user       | `[FILL IN:]` | ☐    |
| 3   | `[FILL IN: e.g., cloud console / IAM]`                                              | Revoke all policies             | `[FILL IN:]` | ☐    |
| 4   | `[FILL IN: e.g., monitoring / Sentry]`                                              | Remove member                   | `[FILL IN:]` | ☐    |
| 5   | `[FILL IN: e.g., HR / payroll system]`                                              | Deactivate                      | `[FILL IN:]` | ☐    |
| 6   | `[FILL IN: e.g., communication tools]`                                              | Deactivate / transfer ownership | `[FILL IN:]` | ☐    |
| 7   | `[FILL IN: any other system]`                                                       | `[FILL IN: action]`             | `[FILL IN:]` | ☐    |
| 8   | IdP account: move to suspended → delete after `[FILL IN: e.g., 30-day]` hold period | IT                              | `[FILL IN:]` | ☐    |

---

## 4. Device Return

| #   | Task                                                                        | Owner                | Done |
| --- | --------------------------------------------------------------------------- | -------------------- | ---- |
| 1   | Device returned by `[FILL IN: deadline — e.g., end of final working day]`   | Departing individual | ☐    |
| 2   | Device wiped via MDM (`[FILL IN: MDM tool]`) and wipe logged                | `[FILL IN: IT]`      | ☐    |
| 3   | Device re-assigned or quarantined per `[FILL IN: asset-management process]` | `[FILL IN: IT]`      | ☐    |

For lost/stolen devices see [`device-policy.template.md`](./device-policy.template.md) § 5.

---

## 5. Data Handover & Retention

| #   | Task                                                                                          | Done |
| --- | --------------------------------------------------------------------------------------------- | ---- |
| 1   | Business-critical files transferred to `[FILL IN: shared location — e.g., team drive]`        | ☐    |
| 2   | Personal data on company systems assessed; deleted or anonymised per retention policy         | ☐    |
| 3   | Any personal data held in personal tools / local storage destroyed: `[FILL IN: confirmation]` | ☐    |
| 4   | Email forwarding / out-of-office configured for `[FILL IN: duration]`                         | ☐    |

---

## 6. Exit Interview & Acknowledgement

| #   | Task                                                                           | Done |
| --- | ------------------------------------------------------------------------------ | ---- |
| 1   | Departing individual reminded of ongoing confidentiality obligations           | ☐    |
| 2   | Signed offboarding acknowledgement obtained: `[FILL IN: form name / location]` | ☐    |
| 3   | Final payslip / equipment receipt issued                                       | ☐    |

---

## 7. Post-Departure Review (30 days)

- Confirm no residual access exists: re-run access audit for `[FILL IN: critical systems]`.
- Review audit log for anomalous activity by the account in the 30 days before departure: `[FILL IN: query / command]`.
- If anomalies found, escalate to the incident runbook (see [`incident-runbook.template.md`](./incident-runbook.template.md)).

---

## 8. Record-Keeping

Completed offboarding checklists are stored in `[FILL IN: location — e.g., HR system / personnel file]` and retained for `[FILL IN: e.g., 7 years]` per the backup and retention policy (see [`backup-policy.template.md`](./backup-policy.template.md)).

---

## 9. Review Cycle

This checklist is reviewed `[FILL IN: frequency — e.g., annually or when systems change]`. The next scheduled review is `[FILL IN: YYYY-MM-DD]`.
