Data Governance & Consent
Growth data you could defend in an audit.
Consent captured properly and carried with the record, access granted by role rather than by whoever asked, retention windows that actually delete, and deletion requests that propagate through every join and every downstream tool. Definitions live in one catalog so a metric means the same thing in the boardroom as in the warehouse. It is the unglamorous half of a data spine, and the half that gets audited.
Data Governance & Consent captures consent at source and carries it with every record through the pipeline. Access is role-based and reviewed on a schedule, retention windows run as jobs rather than policy, deletion requests propagate through every join and downstream tool, and one metric catalog holds a single owned definition for each number.
-
The tension
Consent is a banner nobody reads and a flag nobody checks after collection. Access is whatever was granted during the last urgent project. Nothing has ever been deleted, three teams define active customer differently, and a subject access request means someone searching systems by hand for a week.
-
The shift
Consent state travels with the event, so a record that was never permitted does not enter the pipeline in the first place. Access is role-based and reviewed, retention windows run as jobs rather than as policy documents, deletion propagates through the joins and into the connected tools, and every metric has one owned definition in a catalog everyone can read.
-
The outcome
A stack where the answer to what data do we hold on this person is a query, not an investigation — and where nobody has to choose between moving fast and being able to explain what happened to a regulator.
What you get
Concrete, not fluff.
-
Consent captured at source and enforced in the pipeline
-
Role-based access, reviewed on a schedule
-
Retention windows that run as jobs, not as policy
-
Deletion that propagates through joins and tools
-
A metric catalog with one owned definition each
-
Audit logging across warehouse and destinations
How it works
Brief in, live campaign out.
-
Map what you hold and where
-
Capture and carry consent
-
Set access and retention
-
Propagate deletion end to end
-
Catalog the definitions
It loops — every cycle feeds the next.
The proof
The unglamorous half is the half that gets audited.
Consent, access, retention and deletion treated as running jobs with logs — not as a policy document nobody has opened since it was signed.
A subscription business could not answer a subject access request inside its statutory window, because customer records existed in six systems and nobody had a map. Cataloging the holdings and wiring deletion through the joins reduced that from a week of manual searching to a single request. Directional, not a named client.
FAQ
Frequently asked questions
-
No. Your policy, and your interpretation of GDPR, CCPA or anything else, stays with you and your counsel. What we do is make the systems behave the way that policy says they already do — which is usually where the gap is.
-
In the first weeks, occasionally. After that it tends to speed things up, because arguments about which number is right and who is allowed to see it are what actually cost time. Enforced rules also mean fewer conversations start with a lawyer.
-
It gets mapped first, and then it is a decision: keep with a lawful basis, restrict, or delete. We will show you the holdings and the risk; choosing is yours, because it is your business and your obligation.
-
Less than most teams fear. It removes records you were never permitted to use, which is a smaller share than the industry implies, and it makes the remainder defensible. A number you cannot use is worth less than a smaller number you can.
-
Not before — alongside. Building the spine and retrofitting governance afterwards is how teams end up rebuilding pipelines. It is cheaper as a constraint at the start than as a remediation project a year in.