What Belongs in a Handover Document, and What Usually Gets Left Out
A handover document has seven sections. Six of them get written. The seventh, the one listing what is broken, is the one that decides who pays when something surfaces later.
A handover document needs seven sections: scope, systems and access, current state, known issues, in-flight work, contacts and dependencies, and a sign-off. Most templates cover six. The one that gets thinned to nothing is known issues, and it is the section that decides who carries the cost when a problem surfaces two months later.
This covers what each section holds, and the difference between a document you wrote and a record you can produce later. If you would rather just have the document, the free handover document generator builds one from a few answers and never sends anything anywhere.
The seven sections
1. Scope and effective date. What is transferring, from whom, to whom, and the date responsibility moves. Name the boundary explicitly, because "we assumed you had it" lives in the gap.
Systems and access is an inventory question: what exists, who holds the account, and how it moves. Photo: panumas nikhomkhai via Pexels. Pexels License.
2. Systems and access. Every system, its purpose, who the account holder is, and how access is being transferred. Credentials do not belong in the document body. Move them through a channel built for secrets, and reference them here.
3. Current state. How things stand at the moment of transfer: versions, configurations, licence counts, renewal dates, capacity, anything with a clock on it.
4. Known issues. Covered below. This is the section that matters.
5. In-flight work. Anything started and not finished, with its status and whatever the next step is. Half-finished work that nobody inherits is how a migration stalls for a quarter.
6. Contacts and dependencies. Vendors, support contracts, escalation paths, the third parties who will need telling. Include the ones that are informal, because those are the ones that vanish with you.
7. Sign-off. Who accepted, when, and what exactly they were accepting.
The section everyone thins
Known issues is uncomfortable to write. It is a list of things that are wrong, handed to the person taking over, often while a relationship is ending badly.
A disclosure is a warning attached to the thing being moved, written before anyone has a reason to dispute it. Photo: Erik Mclean via Pexels. Pexels License.
Write it anyway, and write it with severity attached:
| Severity | Means | Example |
|---|---|---|
| Critical | Live risk of loss or breach | Backups have not completed since January |
| Warning | Will bite on a known clock | Licence lapses in six weeks, unbudgeted |
| Info | Should be known, not urgent | Two servers still on a deprecated OS build |
The purpose is not to alarm the recipient. It is to make "nobody told me" unavailable as a position, before anyone has a reason to take it. A disclosure that was never written is indistinguishable, later, from a problem you concealed.
Writing it is half the job
Here is the failure that a template alone does not fix.
Nine months later the question is not what you wrote. It is what they can be shown to have received. Photo: Kindel Media via Pexels. Pexels License.
You write a thorough handover document. You attach it to an email. Nine months later the client says the backup failure was never disclosed, and that the document they received did not contain that line.
Now what? You have your copy. They have theirs, or say they do. Your copy is a file on your disk with a modification date you control, sent through a mail server you control. Nothing about it establishes what they received, when they received it, or that they read any of it.
| What you have | What it establishes |
|---|---|
| The document on your disk | That you wrote something. Timestamps are yours to change. |
| The sent email | That a server accepted a message. Not what was in the attachment they opened. |
| A read receipt | That a mail client rendered it. Trivially disabled, easily disputed. |
| A signed acknowledgment naming the disclosures | That a named person confirmed these specific items on a date. |
Only the last row survives someone contesting it.
Making the document a record
Three properties turn a handover document into something you can produce later:
- A hash of the file at the moment it was sent, so the copy in their hands is provably the copy you sent.
- An acknowledgment tied to a person, naming what was acknowledged rather than confirming that something arrived.
- A timestamp neither party controls, because your mail server and your file system are both yours.
A signature naming what was acknowledged is the part that survives someone contesting it. Photo: Ch%E2u%20Th%F4ng%20Phan via Openverse. CC0 1.0.
That is the whole of it. The document is the easy part and a template gets you there. The record is the part that holds up.
Templates
Pactbound ships handover templates with the disclosure structure already built, including MSP offboarding and property management transitions, in the template library. Filling one in produces the document and the acknowledgment together, so the second does not become a thing you meant to get around to.
The five-step version of the underlying method is in how to make a client handoff legally defensible.
Sources
- NIST FIPS PUB 180-4, the standard specifying SHA-256, the hash used to fix a document's contents at a point in time
- E-SIGN Act, 15 U.S.C. § 7001, under which an electronic record or signature may not be denied legal effect solely because it is electronic