Service · Customer Identity & Consent
Customer identity and access management (CIAM) judged on one question: when a customer withdraws consent or asks to be deleted, does anything actually change in the systems holding their record? That is the part a regulator tests, and the part we build.
Disciplines covered
Where Consent Architecture Breaks Down
A checkbox at signup writes a row in a table the marketing platform owns. The authorization layer never reads it. The question a regulator asks is not whether consent was collected — it is whether the system behaved differently because of it, and whether you can show that for one named customer on one named date.
A data-subject request arrives with a clock attached — 30 days under PIPEDA and Law 25, 45 under CCPA/CPRA — and lands on an identity graph that cannot resolve one person across the CIAM, the CRM, the warehouse, and two acquisitions. The clock does not pause while you search.
The profile is gone from the identity provider and alive in the data warehouse, the support tool, the analytics pipeline, and a processor's cache. Partial deletion is worse than none: you have told the customer the record is gone, in writing, and it is not.
Before you hand someone their own data you have to establish that it is theirs. Get it wrong in the permissive direction and the request is a disclosure incident; get it wrong in the strict direction and you have obstructed a statutory right. Both failure modes live in the identity layer, not in the privacy policy.
What We Deliver
Consent and purpose state modelled as claims the policy decision point reads at request time — so the answer to 'was this permitted?' comes from the system that made the decision, not from a spreadsheet reconstructed afterwards.
Intake, requester verification, resolution across every downstream store, and response inside the shortest applicable clock — with a per-request evidence trail that shows what was searched and what was returned.
Fragmented profiles across acquisitions and legacy systems merged into one resolvable identity. One login for the customer; one answerable record for you.
One consent taxonomy and one implementation, mapped to Québec Law 25, PIPEDA's consent and access principles, and CCPA/CPRA — three evidence views over the same control, not three programmes.
Verification proportionate to the sensitivity of what is being released, designed so the request channel does not become an account-takeover path.
For healthcare: PHIPA consent directives and lockbox instructions enforced at the authorization layer, where they are testable, rather than described in a policy document nobody can query.
Platforms We Work With
We work in the consoles you already license, and we never resell them.*
* Platform and product names identify systems we work with. They do not imply partnership, certification, or endorsement by their owners.
We trace one data-subject request end to end through your real systems — intake, verification, resolution, deletion — and show you where it stalls and what it would take to answer it inside the clock.
Book an Identity Risk Review