Universal Consent Lifecycle & Compliance

Universal Consent helps you keep a user's consent choices consistent across the experiences where you recognize them. This guide explains how those preferences are stored, shared, honored, and deleted.

For an introduction to Universal Consent and available deployment options, see the Overview. For implementation details, see the Developer Guide.

Protecting Identifiers

Universal Consent never receives the plain-text identifier you use for a user. The identifier you provide is converted into a hash on the user's device or on your servers, and only the hash is sent to and stored by DataGrail. You can think of a hash as a fingerprint that allows Universal Consent to recognize the same user without storing the original identifier as the record key.

The hash is also scoped to your DataGrail customer and project, helping prevent consent records from being associated across different customers or projects.

Pseudonymization, not anonymization. Hashed identifiers are considered pseudonymized rather than anonymous data and may still be treated as personal data under applicable privacy laws.

Choosing an Identifier

Use a stable, opaque identifier that you assign, such as a random user UUID. Don't use an email address or phone number, even hashed: those values are guessable, so anyone with a list of candidates could hash them and match the results to stored records. It must also be non-guessable, such as a random UUID, never a sequential or enumerable ID: reads need only public values (your API key, customer ID, and project ID), so anyone could hash guessable IDs and look up other users' records.

What's Stored

Universal Consent stores the user's consent preferences against their hashed identifier. For example:

• Marketing: Off
• Analytics: On
• Functional: On

The consent record does not contain the user's activity or their plain-text identity.

This gives your team a consistent consent record while helping ensure that changes, including withdrawals of consent, are reflected across connected experiences.

The Data Lifecycle

Every consent choice moves through a predictable lifecycle.

• Support consent accountability. Because every change is timestamped, you can demonstrate when and what a user consented to — a core requirement for accountability under the GDPR.
• Consistent preference handling. Once a choice is recorded, connected surfaces can reference the same consent record, helping ensure withdrawals and updates are honored consistently.

Consent Accountability

Universal Consent maintains timestamps when consent preferences change, giving your team a record of what preference was captured and when.

This can help support compliance and audit needs, including demonstrating consent history where required.

Because connected experiences reference the same consent record, a user's updated preference does not need to remain isolated to the browser or device where they made the change.

Deleting a Record

If a user submits a valid deletion request, such as a GDPR right-to-erasure request or an equivalent request under another applicable privacy law, you can have their Universal Consent record deleted. For now, deletion is coordinated through support@datagrail.io; it isn't yet part of the automated DataGrail request workflow.

There is no public or client-side deletion endpoint. DataGrail deletes the record with an authenticated internal request, so deletion actions are controlled.

The process follows these steps:

1. The user submits a deletion request.
2. Your team computes the user's hash from their identifier, the same way your backend does for signing (see the Developer Guide).
3. Your team sends the hash to support@datagrail.io and asks for the Universal Consent record to be deleted.
4. DataGrail deletes the record and confirms.

Deletion Details

• Deletion applies to the Universal Consent record. If the user's personal data also exists in other systems, such as analytics, marketing, or internal data platforms, those systems should be addressed separately as part of your broader request workflow.
• A device can save a choice again. If the user keeps using a device where they made a choice earlier and your site identifies them there again, the banner treats it as a first sign-in and saves that device's choice as a new record. To prevent this, call clearUserIdentifier() on that device (for example, on the user's next visit or logout) so its old local choice isn't saved again. Stopping setUserIdentifier calls for that user also prevents it, but it turns off Universal Consent for that user on every device.

Privacy Program Support

The table below maps common privacy requirements to how Universal Consent supports them.

Requirement	How Universal Consent Helps
Keep consent consistent for a recognized user	Maintains a central consent record that supported experiences can reference
Honor updated or withdrawn consent	Connected experiences can retrieve the user's latest preference
Maintain a record of consent	Consent changes are timestamped
Minimize use of direct identifiers	Consent records are keyed using a hashed identifier rather than a plain-text identity
Support deletion requests	DataGrail deletes a Universal Consent record on request to support@datagrail.io

Universal Consent provides the consent record and infrastructure to support these workflows. Your organization remains responsible for determining which privacy requirements apply and for configuring and implementing Universal Consent in accordance with those requirements.

Related

• Universal Consent Overview — what Universal Consent is and its deployment options
• Developer Guide — the technical integration for developers
• Consent Policies — configuring regional consent behavior
• Audit Logging — exporting the consent audit trail