Court & small-claims ready
Identity-verified acknowledgments with an external timestamp are the kind of contemporaneous record a judge or arbitrator accepts: not screenshots reconstructed after the fact.
For MSPs & IT providers
MSP client handoffs, documented and verified.
When you take over a client, or hand one off, both sides need proof of what credentials, configs, and known issues changed hands, and when. Pactbound makes that record tamper-evident and verifiable by anyone, so a clean transition can't come back to bite you.
What goes wrong during a client transition
On- and offboarding are the highest-risk days in the relationship. Without a verifiable handoff record, every later problem becomes a question of your word against theirs.
A real offboarding
Did you hand over everything, or just enough to get blamed?
When Westbrook IT loses a client to a competitor, the offboarding is supposed to be routine. Forty-three credentials, two firewalls, a backup appliance that's been throwing errors since winter, and a client who's already half out the door and barely returning calls.
Before they revoke a thing, Westbrook sends the incoming provider a Pactbound handoff: every credential, the network docs, and a plain list of what's known-broken, including that failing backup. The new provider opens the link, confirms who they are, and acknowledges each item.
Nobody loves signing off on a failing backup. They do it anyway, because the alternative is pretending they were never told. Now there's a line in the sand: what was handed over, what was disclosed, and who accepted it, fixed to a date neither side can move.
When the client is hit with ransomware that fall and their lawyer goes looking for someone to blame, Westbrook pulls one receipt. The backup was flagged in writing, the new provider acknowledged it, and the transfer was complete and timestamped months before the breach.
Tamper-evident proof of what you handed over
Pactbound creates a sealed record containing every credential, config, disclosure, and acknowledgment exchanged during the transition. Anyone can later confirm it is genuine and unchanged, with no Pactbound account and no Pactbound server.
You upload the documentation and disclose what’s known-broken: the failing backup, the unpatched box, the license that lapses next month. The receiving party reviews each item and acknowledges receipt, identity-verified with a one-time code. Every acknowledgment is tied to the specific disclosure it answers.
Under the hood, each item is hashed and a fingerprint of the whole record is anchored on an independent public ledger, so the timestamp holds up even if we disappear. If a client later asks whether a vulnerability was disclosed or whether access was fully transferred, the record gives a verifiable answer. How this stands up in court.
MSP Client Handoff Template
Start with a pre-built template covering the critical sections of a client transition. Add custom disclosures for anything client-specific, and attach the supporting documents and exports.
Template sections
- Client and environment summary
- Domain, RMM, and PSA access
- Privileged-credential and account inventory
- Network documentation and diagrams
- Backup configuration and last verified restore
- Security posture and known-vulnerability disclosure
- License and subscription inventory
- Vendor and ISP contacts
- Open tickets and in-flight work
- Data-retention and access-revocation acknowledgment
A clean transition protects your reputation
The MSP community is smaller than it looks, and one botched handoff follows you. A sealed, acknowledged record of exactly what you transferred and what you disclosed turns a he-said-she-said into a closed question.
What you seal
Every credential and config a successor could later question.
- The credentials and access actually transferred
- Which systems are documented versus undocumented
- Backup status and the last verified restore
- Known vulnerabilities and unpatched systems disclosed
- Open tickets and in-flight work at handover
- The receiving party's acceptance of the environment as-is
Where the receipt does the work
One artifact, three places it pays off.
Chargeback & dispute evidence
Export a bundle as PDF and drop it straight into a Stripe, PayPal, or Square dispute: proof of delivery and proof of acceptance in one file.
Outlives the relationship
The receipt is anchored on a public ledger and verifiable with an open-source script. It holds up years later, with or without Pactbound.
Common questions
What MSPs ask before their first handoff
- Who is liable after an MSP client offboarding goes wrong?
- Whoever can prove what was handed over and what was disclosed. If you document the credentials, configs, and known issues you transferred, and the receiving party acknowledges them, responsibility for what you disclosed stays settled with that acknowledgment. Pactbound captures the handoff as a sealed, timestamped record both sides sign.
- How do I prove I handed over a client's credentials and access?
- Package the credentials, configs, documentation, and known-issue disclosures into a Pactbound handoff. Each item is SHA-256 hashed, the receiving party verifies their identity and acknowledges receipt, and a fingerprint of the record is anchored independently. You can show exactly what was transferred and when, and anyone can verify it without trusting us.
- What should an MSP client handoff include?
- At minimum: domain, RMM, and PSA access; a privileged-credential inventory; network documentation; backup and last-verified-restore status; a security-posture and known-vulnerability disclosure; a license inventory; vendor contacts; open tickets; and a data-retention and access-revocation acknowledgment. The MSP template covers each of these.
- Does the incoming provider or client need a Pactbound account to sign off?
- No. They open the handoff from a link in their email, confirm their identity with a one-time code, and acknowledge it. No account, and nothing to install.
Seal your next client transition
Free tier includes 5 sign-offs per month. No credit card required.
Start Free