The consent handover document every agency should ship with a client site
Every agency has lived this: you build a site with consent properly configured, hand it over, and six months later a scan shows trackers firing before choice. The client added a tool, changed a tag, or let a plugin update through, and nobody knew what the setup was supposed to look like. A consent handover document fixes that. It is one page that records the configuration, the blocking logic, and the rules for not breaking it.
What the document contains
- The banner configuration: which categories exist, what each one covers, and the exact click path for accept and reject.
- The tracker inventory: every tracker on the site, its vendor, and the consent category that gates it. One table, no exceptions.
- The blocking mechanism: how consent state is stored, how tags read it, and where the logic lives in the tag manager.
- The embed list: videos, maps, chat, reviews, forms, each with its consent story.
- The rules for changes: what the client must do before adding any new tracking tool, in plain language.
- The scan schedule: how often consent gets re-tested and who runs it.
Why it protects the agency
The handover document does two things for the agency. First, it makes the deliverable complete: the client received not just a working site but the knowledge to keep it working. Second, it creates a record. When the client breaks the setup by adding an unvetted tool, the document shows where the change violated the stated rules. The conversation shifts from "your build broke" to "the setup changed after handover, here is where."
This matters because liability questions about consent rarely hinge on the original build. They hinge on what happened after. An agency that can produce the configuration it shipped, the inventory it left behind, and the maintenance rules it provided is in a fundamentally different position than one whose work product was a banner and a handshake.
How to keep it from going stale
A handover document that is never updated becomes fiction within a year. The practical version is a living page: the agency updates the tracker inventory at each retainer check-in, and the client notifies the agency before adding tools, per the rules in the document itself. Some agencies fold the consent re-scan into their maintenance retainer. That is both a revenue line and a liability reducer, and clients who understand the stakes rarely object to it.
The template
Keep it to one page: a configuration summary, a tracker table, a blocking-logic note, an embed list, change rules, and a scan schedule. Write it in language the client's marketing lead can follow, because that is the person who will add the next tracking tool at 4pm on a Friday. The document's job is to make the right action the easy action, long after the agency team has moved on to the next project.
Getting the client to sign off
The handover document only works if the client reads it, which means the sign-off has to be a real meeting, not an email attachment. Walk the client's marketing lead through the tracker inventory and the change rules in fifteen minutes at handover. Show them the scan, show them what "reject all" looks like in the debugger, and show them the one rule that matters: tell us before you add any tracking tool. Clients who have seen the machinery are dramatically less likely to break it.
Frame the rules as protection for the client, not bureaucracy from the agency. "If you add a tool without telling us, the next scan will flag it and we will have to bill you to fix it" is honest and effective. Some agencies go further and make the consent re-scan a line item in the maintenance retainer, so the document stays current and the client has a standing reason to route changes through the agency. The document is the deliverable; the retainer is what keeps it true.