2026-08-07 · ~24 min read · Decision records

The consent management decision record: why the consent framework you chose determines your downstream propagation failure surface and your regulatory defense gap

Consent management decisions are made in three founding sessions that never document the operational consequences — the "add a cookie banner" session that picks a consent management platform without specifying how the consent signal propagates to each downstream data processor, so that GA4, Segment, and Intercom initialize on every page load regardless of the choice the user just made in the consent dialog, and 840,000 analytics events collected on users who declined analytics consent are discovered during a DPA audit 14 months later; the "implement consent withdrawal" session that builds a right-to-erasure flow without specifying the distinction between user personal data subject to deletion and consent records that the company must retain as evidence of lawful basis, so that the erasure flow truncates the consent_events table rows for the requesting user along with their other account data, and when a national data protection authority audits the company 3 years later and requests evidence of consent at the time of data collection for four specific users, the company cannot produce consent records for any of them because the erasure flow deleted the records it was legally required to retain; and the "add age verification" session that implements an age gate as a client-side JavaScript date-of-birth form that rejects values below the minimum age threshold without specifying that the enforcement must occur at the server boundary, so that the age check is bypassed by any user who modifies the DOM or sends an HTTP POST directly to the account creation endpoint, and an FTC review triggered by a competitor complaint finds that the platform's age verification system does not actually verify age because the enforcement exists only in JavaScript that runs in the user's browser, under the user's control. What none of these sessions produce is the consent signal propagation specification enumerating every downstream system and its initialization dependency on the consent decision, the distinction between user data deletion and consent record retention for regulatory defense, or the enforcement boundary requirement that age gates and geographic restrictions must be validated server-side before any data is persisted or any account is created.

A 30-person B2C subscription software company operating in the European Union added a GDPR-compliant cookie consent banner in response to a legal review that identified the absence of a consent mechanism as a compliance risk. The engineering team integrated a consent management platform — a JavaScript widget that displayed a banner on first visit, recorded the user's consent choices (analytics, marketing, personalization) as a TCF-compliant consent string in a first-party cookie, and exposed an API for querying the user's current consent state. The integration took four days. The CMP vendor's documentation showed a working demo. The banner appeared correctly on every page. The consent choices were stored correctly in the cookie. The legal team reviewed the banner copy and approved it. The engineering team closed the compliance ticket.

The company used Google Analytics 4 for product analytics, Segment as its event routing layer, and Intercom for in-app messaging and support chat. All three tools were loaded via a script tag in the HTML <head>, unconditionally, before the CMP's script tag. The initialization order meant that GA4, Segment, and Intercom loaded and fired their initial pageview and session events before the CMP had an opportunity to present the consent banner, let alone receive a consent decision. When a user arrived at the homepage, the sequence was: GA4 initializes, fires pageview event, sends data to Google's servers → Segment initializes, fires anonymous identify call, routes to configured destinations → Intercom initializes, creates a visitor session, sends browser fingerprint data → CMP banner appears on screen. The user's consent choice, made seconds after all three tools had already collected their first-session data, had no effect on what those tools had already sent.

The engineering team had read the CMP vendor's integration guide, which included a section on "blocking mode" — a configuration that prevented the CMP's managed scripts from loading until consent was granted. The guide described blocking mode as optional, recommended for "advanced users." The team had implemented the CMP in "informational mode," where the banner presented choices and recorded them, but script blocking was not enabled. The consent choices were stored correctly. The downstream tools were not wired to check those choices before collecting data. The CMP's dashboard showed consent rates and purpose breakdowns. It did not show whether the downstream tools were respecting those consent rates, because the CMP had no visibility into whether the analytics tools were reading the consent signal before firing events.

Fourteen months after the banner was deployed, the company received a formal inquiry from the data protection authority of a member state where a significant fraction of its users resided. The inquiry cited a complaint from a user who had declined analytics consent on first visit and noticed, through browser developer tools, that GA4 and Segment requests were still appearing in the network tab. The DPA requested a full accounting of analytics data collected from users who had declined consent. The company's analytics team queried its Segment event store: 840,000 analytics events from users whose CMP consent record showed analytics=denied. The consent string had been stored correctly. The events had been collected regardless of what the consent string said. The founding session that integrated the CMP had documented "integrate [CMP name] for GDPR compliance." It had not specified that each downstream analytics tool must be wired to the CMP's consent signal such that the tool does not initialize or collect data until an affirmative analytics consent decision has been recorded — and that the initialization dependency must be enforced by loading order and CMP callback wiring, not assumed from the presence of a consent banner on the page.

The remediation required restructuring the analytics initialization across the entire application: moving all analytics script tags out of the HTML <head>, wiring their initialization inside the CMP's consent-granted callback, implementing Google Consent Mode v2 for GA4 (which allows GA4 to run in a cookieless, aggregated mode when analytics consent is denied rather than blocking it entirely), and auditing every tag in the Google Tag Manager container for consent dependencies. The remediation took six weeks of engineering time. The DPA issued a formal warning and required the company to notify affected users. The consent records correctly reflecting users' choices had existed in the database for 14 months without any downstream system reading them.

A 25-person FinTech SaaS company operating under GDPR built a data retention and erasure system as part of its Series A compliance readiness work. The system handled right-to-erasure requests (GDPR Article 17): a user could request deletion of their account and all associated data, and the system would delete the user's profile, transaction history, linked account data, support ticket history, and all other records linking the user's identity to stored data. The legal team reviewed the erasure flow and confirmed that it satisfied the GDPR Article 17 obligation. The implementation deleted the user's row from the users table, and cascaded deletions to all tables with a foreign key reference to the user's ID. The cascade included the consent_events table — which stored rows recording each consent grant and withdrawal the user had made since account creation, keyed by user_id.

The founding engineering session that built the erasure system had discussed the scope of deletion: "everything linked to the user_id should go." The consent_events table was linked to the user_id. It was included in the cascade. The session did not include anyone who had considered whether consent records were a category of data the company needed to retain independently of the user's personal data. The engineers understood consent records as "data about the user" and included them in the scope of the erasure obligation. The legal team's review confirmed that the erasure flow deleted what it was supposed to delete — the user's personal data. Neither the engineering team nor the legal team had distinguished between the user's personal data (which the erasure obligation required deleting) and the company's records of lawful basis (which the company needed to retain as evidence that the processing it had conducted during the user's account tenure was conducted lawfully).

Three years after launch, the company underwent a formal regulatory audit by a national data protection authority as part of a sector-wide review of FinTech data practices. The DPA requested evidence of consent at the time of data collection for five specific users. Four of those five users had submitted erasure requests during their account tenure. For those four users, the company's erasure flow had deleted their consent_events records — the only records that documented when they had granted consent, for which purposes, and through which CMP session. The company could produce no evidence of consent for any processing conducted during those users' account periods. The analytics events, the transaction enrichment processing, the marketing emails sent to those users — all had been conducted under consent that could no longer be demonstrated. The absence of consent records was not evidence that consent had not been granted. It was evidence that the company had not retained its own records of consent — which, from the regulator's perspective, was as problematic as having never obtained consent in the first place, because the burden of proof for lawful basis rests with the controller under GDPR Article 5(2).

The DPA's investigation found that the company had a systematic practice of deleting its own consent records as part of erasure flows — a practice that reflected a misunderstanding of what the erasure obligation required. GDPR Article 17(3) enumerates exceptions to the erasure obligation, including the establishment, exercise, or defense of legal claims. Consent records are the company's legal claim documentation — the records by which it defends the lawfulness of its processing if challenged. Deleting them on an erasure request extinguished the defense. The DPA issued a formal finding that the company had violated GDPR Article 5(2) (accountability) by failing to retain records capable of demonstrating that processing was conducted lawfully, and required the company to revise its erasure procedure and implement a consent record retention policy. The founding session that built the erasure system had not documented the distinction between user personal data subject to the erasure obligation and the company's own legal basis records that must be retained for the regulatory defense period — typically the statute of limitations for data protection enforcement proceedings in the relevant jurisdiction, which in the EU ranges from 3 to 6 years depending on the member state's administrative procedure law.

A 20-person consumer social platform serving users in the United States and Canada launched with a signup flow that included an age verification step required by the Children's Online Privacy Protection Act (COPPA). COPPA prohibits platforms from knowingly collecting personal information from children under 13 without verifiable parental consent. The platform's founding engineering team implemented age verification as part of the signup form: a date-of-birth field with client-side JavaScript validation that calculated the user's age from the entered date and rejected the form submission with an error message if the calculated age was below 13. The validation ran entirely in the browser. If the user entered a valid date indicating age 13 or older, the form submitted, and the account was created. If the entered date indicated age below 13, the form displayed an error and did not submit.

The implementation was reviewed by the engineering team and approved by the product team as satisfying the COPPA age verification requirement. The legal team was not consulted on the technical implementation — only on the policy language about age restrictions in the terms of service. The age gate was documented in the terms of service ("by creating an account you certify that you are 13 years of age or older") and implemented as a form validation rule. The team considered this sufficient: the user had to enter a date indicating age 13 or older to proceed. A user who entered a false date was lying in violation of the terms of service, and the company's legal exposure was limited because the user had falsified the verification.

Eighteen months after launch, a security researcher published a blog post demonstrating that the platform's age verification could be bypassed by three methods: (1) opening the browser's developer tools, selecting the form's submit button element, removing the JavaScript event listener that triggered the age validation, and clicking the button to submit the form with any date-of-birth value including one indicating age below 13; (2) opening the browser's developer tools, modifying the date-of-birth input's value attribute to a date indicating age 13 or older after the form had rejected a date indicating underage, and resubmitting; (3) using curl to send an HTTP POST request directly to the account creation API endpoint with an arbitrary date-of-birth value, bypassing the browser form entirely. The researcher demonstrated all three methods with screen recordings and received a working account on the platform in each case. The API endpoint that created accounts did not validate the date-of-birth value on the server side — it accepted whatever value the client submitted and created the account.

The blog post was shared widely. Six days after publication, the platform received a letter from the Federal Trade Commission indicating that the FTC was opening an investigation into potential COPPA violations. A competitor had filed a formal complaint with the FTC the week before the blog post was published, citing evidence that the platform had users who were under 13. The FTC's investigation requested records of the platform's age verification mechanism, the number of accounts created with date-of-birth values indicating age below 13, and the platform's technical controls to prevent underage access. The platform's age verification logs showed that the client-side validation had correctly blocked form submissions with underage dates of birth in the browser. The API logs showed that the account creation endpoint had accepted 12,000 POST requests in the past 18 months with date-of-birth values indicating age below 13 — requests that bypassed the client-side form entirely. Those 12,000 accounts had been created, had used the platform, and had had their personal information collected and processed during the period they were active. The founding session that implemented the age gate had documented "age verification on signup." It had not specified that age verification must be enforced at the server boundary — that the API endpoint must validate the submitted date of birth before creating an account — because the team had equated the presence of a client-side form validation with the presence of an age verification control.

Structural properties set by the consent management decision

Three structural properties are determined when a team decides how to implement consent management. None appear explicitly in the sessions that choose a CMP vendor, build a data erasure flow, or add an age gate to a signup form — they are the operational consequences of choices made under the assumption that the presence of a consent UI component, an erasure button, or an age-check form field constitutes the corresponding compliance control.

Property 1: The consent signal and the downstream propagation surface. A consent management platform records the user's consent decision in its own storage — typically a first-party cookie containing a TCF consent string, or a database record keyed to the user's session or account identifier. Recording the decision is not the same as propagating it. The propagation surface is the complete set of downstream systems, SDKs, scripts, and API calls that collect or process user data. Each system in the propagation surface must receive the consent decision before it initializes or collects. The gap between recording and propagating is the core failure mode: a CMP that correctly records "analytics=denied" for 840,000 users has done nothing if GA4 is loaded before the consent check and fires its pageview event before the CMP has run.

The propagation dependency is directional and time-ordered: no downstream data collector may initialize before the consent decision is known. "Known" means either (a) a consent string from a prior session has been loaded and parsed, or (b) the user has made a choice in the current session's consent dialog. For returning users with a stored consent string, the CMP should be able to determine the prior consent decision synchronously on page load and communicate it to downstream tools before those tools initialize. For new users (no stored consent string), no downstream tool may initialize before the consent dialog has been displayed and a choice has been made — which means those tools must not be loaded at all until the choice is recorded. The cookie and session management decision record documents the interaction between consent cookies and session cookies: the consent string must be a first-party cookie with an appropriate expiration (IAB TCF requires re-consent after 13 months maximum); the session cookie must not carry analytics identifiers or behavioral data before analytics consent is confirmed; and the consent cookie must be set before any cookie that carries user-identifying data to any third-party domain.

Property 2: The consent record and the regulatory defense period. Consent records are the company's evidence of lawful basis under GDPR Article 6(1)(a) (consent) or Article 8 (children's data). They are the company's own records of a transaction — "user X granted analytics consent at time T via CMP session S under consent string version V" — not the user's personal data in the Article 4(1) sense. The right to erasure under Article 17 applies to the user's personal data. It does not apply to the company's records of its own legal basis. A company that correctly understands this distinction maintains two categories of data separately: user personal data (profile data, usage history, content, behavioral records — subject to erasure) and consent records (timestamps, purpose grants, withdrawal events, CMP session identifiers — retained for the regulatory defense period regardless of erasure requests).

The regulatory defense period is the duration for which the company may be required to produce consent records to demonstrate lawful basis. In the EU, this is typically the statute of limitations for data protection enforcement proceedings in the member state — 3 to 6 years in most jurisdictions, with the limitation period beginning either from the date of the alleged violation or from the date the supervisory authority discovers the violation, depending on the member state's administrative procedure law. Consent records must be retained for this period. When a user submits an erasure request, the correct implementation is to delete the user's personal data and pseudonymize the consent records: replace the user_id foreign key in the consent_events table with a pseudonymous token (a one-way hash of the user_id with a salt that is itself deleted), delete the mapping from the token back to the original user_id, and retain the pseudonymized consent record. The pseudonymized record demonstrates that a user in the relevant cohort (same signup date, same CMP version, same consent string) granted consent at the recorded time, without retaining any information that identifies the specific user. The data retention decision record documents the full retention classification model that distinguishes personal data, derived data, operational records, and legal basis records — consent records fall into the legal basis category and carry the regulatory defense period as their retention duration, not the personal data deletion schedule.

Property 3: The consent enforcement boundary and the client-server split. A consent check in client-side code is not an enforcement control — it is a UI convention that communicates the system's intent to the user but does not technically prevent any outcome. Every client-side check — an age validation that rejects a date of birth, a consent flag that prevents an analytics call from firing, a geographic restriction that disables a feature based on the browser's timezone — can be bypassed by a user who can modify JavaScript, inspect network requests, or send HTTP requests from a tool that does not run the client-side code. The regulatory requirement for age gates, consent-based data collection restrictions, and geographic applicability rules is expressed as an outcome requirement: the system must not collect data from users under the minimum age, the system must not process data for purposes a user has not consented to, the system must not provide services prohibited in a user's jurisdiction. Those outcome requirements are only satisfiable by server-side enforcement: the API layer validates the relevant assertion before committing any data to storage or triggering any downstream processing.

The client-server split in enforcement has implications for the audit trail. Server-side enforcement produces server-side logs: an API endpoint that validates age and rejects requests from users below the minimum age generates a rejection log entry with the submitted date-of-birth value, the calculated age, and the rejection reason. Those log entries are evidence that the enforcement control operated. Client-side enforcement produces no server-side log, because the check runs in the browser and the server receives only the requests that pass the check. A platform whose age enforcement is entirely client-side has no server-side record of having rejected any underage signup attempt — it has only the absence of accounts with underage dates of birth in its database, which is indistinguishable from the absence of underage signup attempts. When a regulator asks for evidence of the age verification control's operation, server-side logs of rejected requests provide that evidence. Client-side validation does not. The access control model decision record documents the general enforcement boundary principle: every access control, restriction, and eligibility check that has a regulatory or security consequence must be enforced at the server boundary — client-side enforcement is presentation only, not security or compliance enforcement.

What the founding session records and what it omits

The founding consent management session typically records the chosen CMP vendor, the consent banner copy, the purpose categories presented to users, and the decision to implement the banner before a specific deadline (usually a legal review finding or a regulatory inquiry). The session may record the ticket number of the compliance task and the name of the legal reviewer who approved the copy. What it does not record is the propagation specification — the ordered list of every downstream system that collects user data, the dependency each has on a specific consent purpose, and the technical mechanism by which the consent signal is communicated to that system before it initializes. It does not record the consent record schema — the table or document structure that stores consent grants and withdrawals, whether the user_id reference is pseudonymizable on erasure, and the retention period that applies to consent records distinct from the retention period for personal data. It does not record the enforcement boundary — whether age gates and geographic restrictions are enforced in client-side code only, in server-side code only, or in both with the server-side check being the authoritative one.

The propagation omission produces a failure that is invisible to the engineering and legal teams because the CMP's UI and reporting appear to be working correctly. Consent rates are tracked. Consent strings are stored. The compliance dashboard shows green. The failure surface is in the gap between the CMP's records and the analytics systems' actual behavior — a gap that only becomes visible when someone compares the set of users who declined analytics consent against the set of users who appear in the analytics event store. That comparison is not part of any routine engineering task. It happens when a user notices the discrepancy and complains, or when a regulator requests it as part of an audit. Neither event is predictable in timing, and the gap can accumulate for years before being detected.

The consent record omission produces a failure with a time-delayed consequence. The erasure flow operates correctly — it deletes the data the engineering team intended to delete. The gap is not in the implementation but in the specification: the session that built the erasure flow did not define which data categories were subject to erasure and which were not. Consent records fell into the wrong category by default, because they are stored in a table linked to the user_id and the team applied the reasonable-sounding rule "everything linked to the user_id should go." The consequence does not surface until a regulatory audit requests records that should have been retained — potentially years after the erasure events that deleted them. The company cannot retroactively reconstruct consent records it has deleted. The regulatory defense gap is permanent for the affected users.

The enforcement boundary omission produces a failure that is detectable only through security testing. The age gate works correctly for users who interact with the product in good faith: they enter their date of birth, the form validates it, underage users see an error and cannot proceed. The failure is that the enforcement is not present at the layer where it matters — the server. Testing the UI confirms the UI works. Testing the API directly (by sending a POST request with an underage date of birth) reveals the absence of server-side enforcement. Security testing of the account creation API is not a standard practice at early-stage companies, which means the enforcement gap often persists until an external researcher or regulator applies the test that the internal team did not. The compliance automation decision record documents the automated testing controls that detect enforcement boundary gaps: API tests that submit requests bypassing the client-side form must be part of the test suite for any endpoint that has an age gate, geographic restriction, or consent-based access control — because those are exactly the tests that exercise the server-side enforcement that the client-side tests cannot reach.

The consent management decision record does not need to enumerate every CMP configuration option or every GDPR article. It needs to answer four questions: which downstream systems are in the propagation surface and what is the dependency between each system's initialization and the consent purpose it requires, what is the consent record schema and the retention period that applies to it distinct from user personal data, what is the scope of erasure requests with respect to consent records and how does the erasure implementation preserve legal basis documentation while deleting personal data, and which consent-based enforcement controls are server-side validated versus client-side only. Four answers written in the founding session prevent the 840,000-event propagation failure, the regulatory defense gap from deleted consent records, and the age gate bypass that the FTC found 18 months after the platform launched.

The WhyChose decision extractor finds the founding consent sessions in your ChatGPT and Claude export — the "what CMP should we use?" conversation, the "how do we handle GDPR erasure requests?" thread, the "we need an age gate before launch" planning session. It extracts the decision and the trade-off that was actually considered, not the surrounding regulatory compliance discussion that buries the propagation wiring question in forty messages about cookie banner design and consent copy approval.

The five ADR sections for a consent management decision

Section 1: CMP selection and consent signal format. Specify the consent management platform and the consent signal format it produces. Two signal formats are common: IAB TCF v2.2 compliance strings (required for platforms that serve targeted advertising using IAB member demand-side platforms; the TC string encodes purpose consents, legitimate interest signals, and vendor-specific consents in a binary format that IAB-compliant tools can parse natively) and custom per-purpose boolean signals (suitable for platforms that do not use IAB-member ad tech and prefer a simpler, proprietary consent model where each purpose — analytics, marketing, personalization, support — is a boolean value stored in a first-party cookie or backend record).

The signal format determines the integration pattern with downstream tools. IAB TCF-compliant tools (GA4, Meta Pixel, Criteo) can read the TC string natively and adjust their collection behavior based on the encoded purpose consents; the CMP handles TC string generation and the tool handles TC string parsing. Custom signal formats require explicit integration: each tool's initialization code must check the custom signal before initializing, and the integration must be maintained whenever either the CMP's API or the tool's initialization API changes. Specify the chosen format, the API by which downstream code reads the current consent state, the event by which the consent state changes (user makes a new choice, stored consent string expires, user withdraws consent), and the callback mechanism by which downstream tools receive change notifications. The observability strategy decision record documents the monitoring requirement: the consent signal must be observable — log every consent grant, withdrawal, and state change with a timestamp, the purpose affected, and the CMP session identifier, so that the propagation surface can be audited against the consent event log to verify that downstream tools are respecting the signal.

Section 2: Consent propagation model — downstream systems, initialization order, and verification. Enumerate every system in the propagation surface: the complete set of scripts, SDKs, pixels, and API calls that collect or process user data. For each system, specify the consent purpose it requires (analytics, marketing, personalization, support), the initialization mechanism (script tag loaded conditionally, SDK initialized inside a callback, API call gated on a server-side consent check), and the expected behavior under each consent state (consent granted: initialize normally; consent denied: do not initialize, or initialize in cookieless/aggregated mode if the tool supports it; consent unknown — no stored signal, banner not yet dismissed: do not initialize until the user makes a choice). Document the initialization order explicitly: the CMP's script loads first, synchronously, before any other script in the <head>; all downstream tools load conditionally, after the CMP has determined the consent state.

For tag manager integrations, specify the consent mode configuration: Google Consent Mode v2 configuration for Google tags (which allows GA4 and Google Ads to run in a restricted, cookieless mode when consent is denied rather than blocking entirely), and the trigger conditions in the tag manager container that prevent tags from firing before the CMP has loaded and the consent state is known. Specify the verification test: an integration test that loads the page in an incognito session (no stored consent), waits for the consent banner to appear without dismissing it, and asserts that no network requests to analytics domains have been made. This test runs in the CI pipeline for every change to the consent initialization code or the tag manager container. A passing test confirms that the propagation wiring is correct. The logging strategy decision record documents the server-side logging requirement for consent signal reads: any server-side processing that is conditional on consent (API endpoints that personalize responses based on behavioral data, backend analytics pipelines that receive user events) must log the consent state read at the time of processing, so that the processing records can be correlated with the consent records during an audit.

Section 3: Consent record schema and retention policy — distinct from user data. Specify the consent record schema. A minimal schema contains: a record identifier (primary key, not the user_id), a user reference (the user_id or a pseudonymous token if the user has submitted an erasure request), a consent purpose identifier (the specific purpose granted or withdrawn — analytics, marketing, personalization), a consent state (granted or withdrawn), a timestamp (the moment the consent decision was recorded), a CMP session identifier (links the record to the full consent interaction, including the banner version, the consent copy displayed, and the user's explicit action), and the consent string version (the TCF consent string or the custom signal version that was in effect when the decision was recorded). Each consent grant and each withdrawal is a separate record — the history of a user's consent decisions is preserved as an append-only log, not as a single mutable record overwritten on each change.

The retention policy for consent records is distinct from the retention policy for user personal data. Specify the retention period in the ADR as the maximum of: (a) the regulatory defense period for data protection enforcement in each jurisdiction where the platform processes data (3 years in most EU member states, 6 years in some, 5 years in the UK under the GDPR UK Retained Regulation), and (b) any contractual retention requirement imposed by processors or customers. Consent records are retained for this period from the date of the last consent event for each user — if a user withdraws consent and closes their account in year 1, the consent records are retained until year 4 or 7, depending on the applicable regulatory defense period. The erasure procedure must explicitly preserve consent records: when an erasure request is received, the consent records for that user are pseudonymized (the user_id reference is replaced by an HMAC of the user_id with a salt that is separately deleted, so the record cannot be linked back to any identified individual) and retained for the full regulatory defense period; all other user data is deleted. The data governance decision record documents the data classification model that distinguishes personal data from legal basis records — consent records belong in the legal basis category and are subject to a retention obligation, not a deletion obligation, under the accountability principle of GDPR Article 5(2).

Section 4: Consent withdrawal scope — data deletion boundary and consent record preservation. Specify the scope of right-to-erasure requests with respect to each data category. The erasure flow must be tested against the consent record schema to verify that consent records are excluded from deletion. Document the implementation explicitly: the erasure stored procedure or application code must not include the consent_events table in its deletion scope; it must include a pseudonymization step that replaces the user_id foreign key in consent_events with a pseudonymous token; it must delete the token-to-user_id mapping table entry; and it must log the pseudonymization event with a timestamp for audit purposes.

Specify the response to the data subject when erasure is complete: the response must confirm what was deleted (personal data, account data, usage history) and what was retained and why (consent records, retained for regulatory compliance for N years, no longer linked to the individual's identity). The GDPR does not require companies to delete their own legal basis documentation — but it does require that processing continues to be lawful after erasure, which means that any ongoing processing for which consent was the lawful basis must stop when consent is withdrawn. Distinguish between the erasure of personal data (historical data is deleted), the withdrawal of consent for future processing (downstream systems must be updated to reflect the withdrawal), and the retention of consent records (the historical record of consent granted and withdrawn is preserved, pseudonymized, for the regulatory defense period). These three actions occur in the erasure flow, each with different data targets and different retention outcomes. The audit log decision record documents the audit trail requirement for erasure events: every erasure request and its outcome — which records were deleted, which were pseudonymized, which were retained and why — must be logged in an append-only audit log that is itself retained for the regulatory defense period, separate from the application database that the erasure flow modifies.

Section 5: Consent enforcement boundary — server-side validation, age gates, and geographic restrictions. Enumerate every consent-based enforcement control in the application and specify the enforcement boundary for each. An enforcement boundary is server-side if the check occurs in the API layer before any data is persisted or any downstream processing is triggered, and the check result determines whether the API request succeeds or fails. An enforcement boundary is client-side if the check occurs in JavaScript running in the browser, without a corresponding server-side check. Only server-side enforcement boundaries satisfy regulatory requirements for age gates, consent-based processing restrictions, and geographic restrictions.

Age gates: specify the minimum age for the jurisdiction, the date-of-birth validation logic that must run on the server, the API response when the submitted date of birth fails the minimum age check (HTTP 400 with a machine-readable error code), and the logging requirement (rejected signup attempts with the submitted date of birth value and the calculated age must be logged for audit purposes). The client-side age gate form is a UX convention that presents the requirement to the user; it is not an enforcement control. Specify that the client-side form exists for user experience purposes only, and that the server-side endpoint is the enforcement point. For platforms subject to enhanced age verification requirements (UK Age Appropriate Design Code, platforms with evidence of prior underage access), specify the age verification mechanism required — self-declaration, credit check, document verification, or third-party age verification service — and document the mechanism's known bypass rate and the platform's residual risk acceptance. The authentication strategy decision record documents the account creation flow where the age gate enforcement must be embedded: the age check must be part of the account creation API endpoint, not an optional pre-check that can be bypassed by calling the account creation endpoint directly.

Geographic restrictions: specify the geographic restriction logic (which features are restricted in which jurisdictions, the source of geographic determination — IP geolocation, billing address, phone country code — and the fallback when the source is unavailable), the server-side enforcement point (the API endpoint that must validate geographic applicability before providing access to the restricted feature), and the logging requirement. Client-side geographic restriction (reading navigator.language or the browser's timezone to determine jurisdiction) is presentation only. The access control model decision record documents the general authorization enforcement model; geographic restrictions are a category of authorization decision that must follow the same enforcement pattern as role-based or subscription-based access control: the authorization check runs on the server, the client reflects the server's authorization decision, and the enforcement point cannot be bypassed by modifying client-side code.

The consent management decision record: why the consent framework you chose determines your downstream propagation failure surface and your regulatory defense gap

Structural properties set by the consent management decision

What the founding session records and what it omits

The five ADR sections for a consent management decision

Further reading

How do you wire a consent management platform's signal to downstream analytics tools so that they do not collect data before consent is granted?

What is the distinction between user personal data subject to a GDPR erasure request and consent records that must be retained for regulatory defense?

Why does client-side age verification not satisfy regulatory age gate requirements, and what does server-side enforcement require?