Guide for building a consent record-keeping system to demonstrate valid consent per GDPR Article 7(1). Covers required fields including timestamp, version, purpose, mechanism, and identity. Implements audit-ready consent receipts per the Kantara Initiative Consent Receipt Specification and supervisory authority expectations.
GDPR Article 7(1) states: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to the processing of personal data." This obligation to demonstrate consent requires comprehensive record-keeping that captures not only the consent decision but the context in which it was made.
The Kantara Initiative Consent Receipt Specification (v1.1) provides a standardized machine-readable format for consent receipts that satisfies regulatory expectations and enables interoperability.
Consent records must be immutable. Once a consent decision is recorded, it cannot be altered. This requires:
Append-Only Storage: Use an append-only database table or immutable log store. Never UPDATE or DELETE consent records.
Integrity Hashing: Each record includes a SHA-256 hash of its contents. Any tampering is detectable.
Chain Hashing: Each record's hash includes the previous record's hash, creating a verifiable chain (similar to blockchain concepts but without the distributed ledger overhead).
Timestamp Integrity: Timestamps are generated server-side (not client-supplied) to prevent manipulation.
Kantara Initiative Consent Receipt Format
The Kantara Initiative Consent Receipt Specification v1.1 defines a JSON format:
-- Consent records table (append-only, never UPDATE or DELETE)
CREATE TABLE consent_records (
consent_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
subject_id UUID NOT NULL,
purpose_id VARCHAR(128) NOT NULL,
purpose_description TEXT NOT NULL,
decision VARCHAR(16) NOT NULL CHECK (decision IN ('granted', 'not_granted', 'withdrawn')),
mechanism VARCHAR(64) NOT NULL,
consent_text_version CHAR(64) NOT NULL,
timestamp_utc TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT now(),
ip_address INET,
user_agent TEXT,
session_id UUID,
source VARCHAR(64) NOT NULL,
controller_name VARCHAR(256) NOT NULL DEFAULT 'CloudVault SaaS Inc.',
record_hash CHAR(64) NOT NULL,
previous_hash CHAR(64),
created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT now()
);
-- Index for efficient lookups per subject
CREATE INDEX idx_consent_records_subject ON consent_records(subject_id, purpose_id, timestamp_utc DESC);
-- Consent text versions (immutable)
CREATE TABLE consent_text_versions (
version_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
purpose_id VARCHAR(128) NOT NULL,
consent_text TEXT NOT NULL,
text_hash CHAR(64) NOT NULL UNIQUE,
approved_by VARCHAR(256) NOT NULL,
effective_from TIMESTAMP WITH TIME ZONE NOT NULL,
effective_until TIMESTAMP WITH TIME ZONE,
created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT now()
);
-- Prevent modifications to consent records
REVOKE UPDATE, DELETE ON consent_records FROM app_user;
REVOKE UPDATE, DELETE ON consent_text_versions FROM app_user;
Audit Query Examples
Reconstruct consent state for a subject at a point in time:
SELECT DISTINCT ON (purpose_id)
purpose_id, decision, timestamp_utc, consent_text_version, mechanism, source
FROM consent_records
WHERE subject_id = 'usr_7f3a9b2e-41d8-4c76-b5e3-9a8d1c2f4e60'
AND timestamp_utc <= '2026-02-15T00:00:00Z'
ORDER BY purpose_id, timestamp_utc DESC;
Verify record chain integrity:
SELECT consent_id, record_hash, previous_hash,
CASE WHEN LAG(record_hash) OVER (ORDER BY created_at) = previous_hash
THEN 'VALID' ELSE 'BROKEN'
END AS chain_status
FROM consent_records
WHERE subject_id = 'usr_7f3a9b2e-41d8-4c76-b5e3-9a8d1c2f4e60'
ORDER BY created_at;
Key Regulatory References
GDPR Article 7(1) — Controller must demonstrate consent