A good handover document lists the systems the person owns, every credential they hold and where it lives, open work and decisions, on call duties, known risks and the people to ask. Aim for one to two pages that a stranger could act on. Credentials are named, never pasted in.
Why security cares about handover
Knowledge walks out with people. The service nobody else deploys, the cron job on a personal server, the vendor account under a private email: these are how outages and incidents begin after a departure.
A handover is the one chance to turn private knowledge into shared records while the person is still available to answer questions.
The sections
| Section | What to include |
|---|---|
| Owned systems | Repositories, services, pipelines, dashboards, domains, with the new owner named for each |
| Access held | Roles in cloud, source host, CI, registries, monitoring. Include admin roles |
| Credentials | Names and locations of tokens, keys and certificates, expiry dates, who rotates them. No values |
| Scheduled and manual jobs | Anything that runs on a timer or needs a human step |
| On call and alerts | Rotations, escalation paths, alert routes tied to their address |
| Open work | Branches, pull requests, tickets, half finished migrations |
| Decisions and context | Why things are the way they are, known workarounds |
| Risks | Fragile parts, expiring certificates, unpatched components |
| Contacts | Vendors, internal teams, support channels |
How to produce it in the notice period
- Start from a template, so the person is not facing a blank page.
- Pair the leaver with the successor for a walkthrough of each system. Have the successor write the notes.
- Reconcile the document with reality. Compare listed access with what your identity provider and cloud console show. Anything on the console but not in the document is a question.
- Reassign alert routes, scheduled jobs and ownership fields from the person to a team or role.
- Run one real task. Ask the successor to deploy or rotate one credential using only the document. Fix the gaps.
- Store the final version in your documentation system with an owner and a review date.
Pitfalls
- Writing "see the wiki" without checking the wiki is current.
- Leaving personal email addresses on vendor accounts, which makes recovery depend on someone who has gone.
- Documenting secrets values in the handover, which creates a new leak.
- Waiting until the last week. Start as soon as notice is given.
Rotation after handover
Anything the person could read should be considered known to them. Rotate shared credentials listed in the document after the handover is complete, using the owner and expiry fields you captured. Prefer scoped, named credentials in future so rotation touches one thing.
Reuse the same document at onboarding
A good handover doubles as an onboarding page for the next owner. Keep it current and the next transition gets cheaper.
Quick check
Should credentials be written in the handover?
No. Record names, locations, expiry and owners. Values belong in your secrets manager.
How long should it be?
One to two pages per major area is usually enough. If a successor cannot act on it, add what they ask about.
Safeguard's asset discovery and compliance evidence automation can help you cross check a handover document against what actually exists. A free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
