How to Make a Client Handoff Legally Defensible
Five steps that turn a routine MSP client handoff into a tamper-evident record you can still produce two years later.
When you hand off a client, you are accepting risk. If a dispute surfaces six months later, the question is never what you handed over. It is what you can still prove you handed over. Five things make the difference: disclosures written down before the transfer, a hash of every file, an acknowledgment tied to a named person, a timestamp neither side controls, and a package that survives without you.
This applies whether you are an MSP transitioning a client to another provider, a property manager moving a portfolio, or a bookkeeper closing out an engagement.
1. Disclose everything in writing
A verbal disclosure is not a record. Every known issue, risk, outstanding ticket, and configuration concern belongs in a structured disclosure with a severity attached.
A disclosure list is worth writing down precisely because the items on it are the ones nobody wants to raise on the last day. Photo: RDNE Stock project via Pexels. Pexels License.
What to disclose:
- Security vulnerabilities and unpatched systems
- Configuration drift from documented baselines
- Outstanding support tickets and their status
- Licensing gaps and upcoming renewals
- Backup failures or recovery procedures that were never tested
The goal is not to alarm the person receiving it. The goal is to remove "nobody told me" from the argument before the argument starts.
2. Hash every file before it leaves
A handoff package is usually runbooks, network diagrams, configuration exports, and a credential vault. Each of those files gets a SHA-256 hash at the moment it is packaged.
Change one byte and the hash no longer matches. That is what lets you show, later, that the copy in their hands is the copy you sent. SHA-256 is specified in NIST FIPS PUB 180-4, which is worth citing when someone asks what the hash actually is.
3. Get an acknowledgment, not a delivery confirmation
Sending is not receiving. You want the other side to say what they got, and you want that statement tied to a person and a time.
Handing something over and having it acknowledged are two different events. Only the second one leaves a record. Photo: Pavel Danilyuk via Pexels. Pexels License.
There is a real difference between the two records:
| Record | What it establishes | Where it falls down |
|---|---|---|
| Email delivery receipt | A server accepted a message | Says nothing about who read it, or what was in it |
| Read receipt | A client rendered the message | Trivially disabled, easily disputed |
| Acknowledgment per disclosure | A named person confirmed this specific item | Requires the recipient to act |
The third is the one that survives contact with a dispute, because it names what was acknowledged rather than that something arrived.
4. Timestamp with something neither of you controls
Timestamps from your mail server, your file system, and your own database share a weakness: you control them. So does anyone arguing you backdated the record.
A public network assigns the time. That is the point: neither side of a dispute gets to set the clock. Photo: U.S. Department of Agriculture via Openverse. CC0 1.0.
Anchoring the key events to a public ledger removes that objection, because the timestamp is assigned by a network rather than by either party. Pactbound uses the Hedera Consensus Service, and the resulting record is readable by anyone through a public mirror node without a Pactbound account.
5. Produce a package that outlives everyone involved
The deliverable is a single self-contained file holding the content and its hashes, the disclosures, the acknowledgments, the Merkle proofs linking each item to one root, and the on-chain anchor records.
The infrastructure outlasts the contract. The record of what was disclosed about it should too. Photo: Federal Bureau of Investigation via Wikimedia Commons. Public domain.
The property that matters: it verifies offline. If your email provider, your documentation vendor, or Pactbound itself disappears, the evidence still stands, because the proof lives on a public ledger and inside the file rather than on someone's server.
What this does not do
It does not guarantee a specific court admits a specific record, and it is documentation rather than a legal instrument. The federal E-SIGN Act (15 U.S.C. § 7001) stops a record being rejected for being electronic; it does not decide whether yours is accepted. What it does is answer the three questions a court, an insurer, or a card processor actually asks: did the content change, when did it exist, and who agreed. Those are covered in more detail in what this evidence proves and what it does not.
Start with one
A handoff you cannot evidence is a liability sitting on your books at whatever a dispute later costs to defend. Create a handoff on the free tier, which includes five sign-offs a month and does not ask for a card.