The compliance calendar — 2018 to 2027

For: business and design stakeholders, agencies and consultancies, and the security and privacy reviewers they answer to.

Every entry below is public record — a statute, a published ruling or enforcement action, or a platform's own dated announcement. Nothing here is inside information, and nothing here is a prediction. The pattern only becomes visible when the dates are read together: for eight years, law and platform have been pushing commerce toward the same shape — a typed, server-resolved data plane where consent, price history, and provenance are records rather than settings.

Code split and verification — challenge, solution, benefit

Challenge. None of the dates below is a reading assignment. Each one changes behaviour on a day, and every record written after that day was written under different rules than the records before it. When Merchant API v1beta retires, when the Content API stops accepting feeds, when a field deprecated in one release is removed in the next — the code changes, and the data keeps its old shape alongside the new. Months later somebody asks the only question that matters: was this entitlement granted before or after the migration, and under which behaviour? A single monolithic deploy answers with a timestamp and a shrug. Reconstructing the rest is archaeology, and it starts exactly when a regulator, an acquirer or a customer is waiting.

Solution. Two mechanisms, and neither is sufficient alone.

Code split — three independently deployable units: the Webflow extension, the Cloudflare Worker, and the public spec repository. A deadline that touches one does not force a release of the others, so the blast radius of a compliance change is the unit that actually changed, and a pre-deploy guard validates the extension before it ships. Fewer things move per deadline, and the things that moved are named.

Release identity — the worker binds its own version, so it can see which release is serving the request. Without that binding the version id exists only in a dashboard, and nothing the worker writes can carry it. With it, every entitlement change is stamped with the release that produced it, alongside the state version, the actor, the actor type, and the mandate the change was made under.

Benefit — stated as the mandate it places on delivery. Which release wrote this record, under what configuration becomes a lookup rather than an investigation. That is the difference between an audit trail and a Day-2 index: one tells you something happened, the other tells you under which rules it happened. It holds because an entitlement here is not a flag carrying a current value but a history — an ordered change bus where every row names the subject, the change, the state version, the actor (admin, agent, user or system), and the mandate it was granted under. So the question a regulator or a customer actually asks is answerable by replaying to the point in question: what was this person entitled to on the day it mattered, and who granted it?

For a delivery organisation that is not an architectural nicety. It is an acceptance criterion, and it belongs in the definition of done rather than in a retrospective. PMO and QA sign-off must include a Data Timeline Attestation: a statement produced by the release itself of which rules were in force at the cut — schema version, rule set, release id — not a document assembled afterwards from memory by whoever is still available.

An attestation is only worth what it can be reconciled against, so change logging has to carry four axes, and the sign-off is that they cross-check:

Any one axis alone is an assertion. The four together are reconcilable, and reconciliation is the test: if the event says consent was granted and no permissions rule fired, one of the two is wrong and the release does not pass. That check is cheap to run continuously and nearly impossible to reconstruct later.

And the artefact cannot be a CSV. A spreadsheet exported without provenance or version evidences none of the above: no release stamp, so nothing says which rules produced it; no ordering, so nothing says what came before; no signature, so nothing says it has not been edited since. It records that somebody believed something on the day they exported it. Every enforcement finding in the calendar below turned on being able to show more than that.

Reading is not control

Everything above establishes that data in motion can be read — attested at the release, logged on four axes, reconciled between them. That is necessary and it is not sufficient, because an observation stops nothing. You could have watched SHEIN's advertising cookies fire on arrival all day; watching would not have prevented a single one.

So the requirement is stronger than observability, and it is symmetric: **humans and machines must both be able to read and block data in motion, at a named point on a timeline.** Four words in that sentence are load-bearing.

• Read — see what is about to be emitted, for which subject, under which rule, before it leaves. After it leaves, you are writing a disclosure, not exercising a control.
• Block — stop it leaving. Not flag it, not annotate it, not correct it downstream in the warehouse. A mechanism that only records is a witness, not a control.
• On a timeline — the block has an address: from this sequence point forward, on this stream, for this subject. A block with no position in the order cannot be replayed, scoped, lifted, or explained afterwards; it is a switch somebody flipped.
• **Humans and machines** — machine-only blocking leaves nobody accountable for a stop that should never have happened. Human-only blocking always arrives late, because events move at machine tempo and approvals do not. The same primitive has to be exercisable at both speeds, by both kinds of actor.

The practical shape follows from that and is the same shape as the rest of this section: the block is the gate, it evaluates inside the function that mints the event, and a refusal appends to the same ordered stream the emission would have. Which makes what did we stop, when, and on whose authority answerable by exactly the replay that answers what did we send — one mechanism, one timeline, two questions.

It is also the sharpest way to state the difference between a consent management platform and a gate. A CMP can read; the four findings above are what happens when reading is all it can do.

Two entries below make that concrete rather than theoretical. Feed labels do not carry over automatically when the Content API shuts down, so the record of what was published under which release is the only way to reconstruct what a feed actually contained. And fields deprecated in the 2026-10 release are removed in 2027-01 — a nine-month overlap, every release, during which both shapes are live and only the release stamp distinguishes them.

The lag is the point

The rows below are not a to-do list with deadlines. Most of them are decisions about conduct that had already happened, and the gap between the two is the part worth planning around.

Two things follow, and the second is the one that costs money.

A record you cannot produce later is a defence you do not have. GDPR Art. 7 has required controllers to demonstrate consent since 2018. Demonstrating it in 2032 means holding what the subject was shown in 2026 — the wording, the jurisdiction that applied, the purposes offered — frozen at capture. Re-deriving it later judges a past grant under a law the subject was not standing in.

Fixing it forward does not clear the back catalogue. Google's response to the €403M was that the case concerned historical settings, since updated. That is true and it did not reduce the fine. A remediation closes the exposure from the day it ships; everything behind it is already written.

So the operative question is not "are we compliant today". It is "if a regulator opens an investigation in 2031 into what we did this week, what can we produce?"

The calendar

Several of these are already behind us, and those are the ones most estates have not absorbed: the consent signal is already the ads data control, any un-migrated Script has already stopped, third-party pixels already receive less than they used to and can already be paused by the platform — and the feed deadline is weeks away, not quarters. Two entries carry no date at all yet, which is its own kind of planning problem: an obligation you can see coming but cannot schedule around.

The tool was bought. The gate never ran.

Four of the entries above are the same finding wearing four coats, and none of them is a case of a company having no consent tool. Every one had bought a consent management platform. Honda ran a mainstream commercial CMP. Todd Snyder ran a third-party privacy portal. SHEIN ran two cookie interfaces at once. The tool was purchased, deployed, and visible on the page — and in every case it was not wired to the thing it was supposed to control.

The regulator said so directly. Announcing the Todd Snyder order, the head of the CPPA's Enforcement Division put it in one line: "Using a consent management platform doesn't get you off the hook for compliance" — the buck stops with the business, not the vendor.

A CMP renders. A gate runs. That distinction is the whole of it, and the four findings sort cleanly along it:

The last row is the one worth dwelling on, because it is not fixable by configuring the banner better. Advertising cookies were written the moment a visitor arrived, before any interaction with the interface. No setting on that interface could have helped: the tag had already fired. The dependency is the timeline, not the widget. A gate that evaluates after the event has been emitted is decoration, however correct its copy.

The penalty table — ceilings, and what has actually been levied

Two numbers get confused constantly, so it is worth separating them. The statutory figure is a ceiling, not a starting point — GDPR's €20M is "up to €20M or 4% of worldwide annual turnover, whichever is higher," which for a large company means the percentage is the real number and €20M is the floor of the cap, not the floor of the fine. And cookie enforcement in France does not run under GDPR at all.

Against those ceilings, what was actually imposed on the four actions above:

And it is additive. That is the part worth planning around, and the mechanism is specific rather than rhetorical. Because CNIL takes cookie cases under Article 82 of the French Data Protection Act rather than under the GDPR, it holds exclusive jurisdiction and does not go through the one-stop-shop — so it acts without deferring to a lead supervisory authority in another member state, and an ePrivacy penalty sits beside GDPR exposure rather than being absorbed into it.

SHEIN is the worked example: €150M from CNIL on cookies and €40M from the DGCCRF on pricing — €190M, two authorities, two legal bases, one business, in the same year. Neither capped the other. GDPR Article 83(3) limits multiple infringements within a single processing operation to the gravest of them; it does nothing to stop separate instruments, separate regulators and separate operations from stacking. CNIL alone issued 21 sanctions totalling more than €475M across 2025.

The UK row is the one to diarise. Before 5 February 2026 a cookie breach there was capped at £500,000 — genuinely a cost of doing business for a large retailer. After it, the same breach reaches £17.5M or 4% of global turnover. Nothing about the technical failure changed; only the number attached to it did.

Why one CMP configuration cannot serve two regimes

There is a second trap underneath, and it is structural rather than careless. The US and EU consent models have opposite defaults:

• US (CCPA/CPPA) is an opt-out shape. Collection is lawful until the subject objects, so the tooling's job is to make objecting easy and to honour it. That is why Honda's asymmetry was the violation — the objection path was harder than the acceptance path.
• EU (ePrivacy/GDPR) is an opt-in shape. Non-essential cookies are unlawful until consent exists, so the tooling's job is to prevent the tag from firing at all. That is why SHEIN's timing was the violation — consent had not yet been given when the cookies were written.

A CMP bought and configured for the US shape does the right thing in the US and the wrong thing in the EU, because "collect until told to stop" is precisely what the EU prohibits. One tool, one configuration, deployed across both, guarantees that one of the two regimes is being broken continuously — and the broken one produces no error, no alert, and no visible symptom. It looks exactly like working software.

The pressure lands hardest on the purchase path, because that is where the tags are densest and where the money is attached. Add-to-cart, checkout, purchase and the conversion ping each carry identifiers to ad platforms, and each one is an event with a consent dependency that has to be resolved before it is emitted, per subject, in that subject's jurisdiction. Jurisdiction follows the subject, not the store: a French visitor to a US storefront is owed the opt-in shape, and no amount of correct US configuration supplies it.

That is the argument for resolving consent server-side, in the function that mints the event, rather than in a banner that renders beside it. A banner can only ask. A function can refuse — and can record that it refused, with the rule that fired, which is the artefact every one of the four investigations above was actually looking for.

What replaced Google Signals — and why it moves work onto you

The June 15 change is usually read as one toggle being retired. It is bigger than that: two different things were replaced, the control and the data model.

The control moved to consent. Google Signals stopped being a co-controller of what Analytics sends to Google Ads; the Consent Mode ad_storage parameter now decides alone. Signals still exists, demoted to a reporting toggle inside Analytics — whether Analytics data is associated with signed-in user information for behavioural reports. It governs a view, no longer a flow.

The data model moved from Google's identity graph to yours. Signals was Google's own cross-device graph, assembled from signed-in Google users and borrowed by advertisers. What replaced it is first-party data, hashed and matched: Enhanced Conversions, Customer Match, and the Data Manager API — launched 9 December 2025 as a single ingestion point for first-party data across Google Ads, Analytics, and Display & Video 360 — with enhanced conversions for web and leads unified into one toggle in April 2026.

Read as a sequence, the intent is unmistakable:

Consent Mode v2 (2023–24) → Enhanced Conversions (2024) → Data Manager (December 2025) → Signals demoted (15 June 2026).

Google spent three years replacing its identity graph with your first-party data, gated by consent. Targeting was not removed; the burden of identity was moved onto the merchant.

The consequence is uneven, and it is the reason this calendar is a strategy document rather than a compliance one. An organisation holding a real consent record and a genuine first-party identity spine now gets sharper measurement than it had under Signals — its own data, matched, with lineage. An organisation holding a banner and no record gets shrinking remarketing lists, modelled conversions, and no way to explain either. Same date, same platform change, opposite outcomes — decided entirely by whether the records existed beforehand.

The live version of this calendar — the same rows plus a machine-readable JSON block — is at crm-sync.dev/pages/difference#calendar.

When the platform changes the pipe and nobody tells the record

Two Shopify entries above are unusual, because they are the only changes in this calendar that took effect without requiring anything of the merchant — and without leaving a mark on the merchant's side.

On 10 December 2025, web pixel payloads began returning null for email, phone, name, and address to any app without approved protected-customer-data access. Five weeks later, on 13 January 2026, marketing app pixels moved to an "Optimized" default, under which the platform monitors pixels and may pause some or all of a pixel's data sharing when it judges the signal is not useful.

Read those together and the implication is uncomfortable in a specific way. What a merchant's own records say was sent, and what was actually sent, can now diverge with no event on the merchant's side. No error, no notification, no row. The tool still renders. The dashboard still populates, thinner. This is the same failure shape as an opt-out that silently fails to take effect — a path that stops working while every interface reports health — except the cause is a platform default rather than a misconfiguration, so no amount of care on the merchant's part would have surfaced it.

The mitigation is not to argue with the platform's judgement, which is often correct. It is to hold a record on your own side that can be compared to the platform's behaviour: what you believe you sent, to which destination, for which subject, under which consent posture. A divergence you can see is an operational finding. A divergence you cannot see is what a discovery request finds for you.

What the calendar actually asks for

Read together, the dates ask for four artifacts, not four projects:

1. A consent record — timestamp, method, version — held by the company, not by the visitor's browser.
2. A price history — enough observation to prove any "was" claim, or the discipline to refuse the claim.
3. A provenance record — what shipped, in which version, containing what (the SBOM and passport thread).
4. A dated dependency register — every API and plugin, with its published sunset status and the date it was checked.

Each is a record. None is a certificate. All four answer the same way: a query, at the moment the question arrives.

The builder's obligation

Most of this calendar lands on the person who builds, and the professional standard has moved with it.

A deprecation notice is a dated public warning

After the date, "we didn't know" is not a defense — it's a finding. Every sunset in the table above was announced publicly, months or years ahead, by the platform itself. An agency, consultancy, or internal team that ships onto a deprecated component is shipping against a published warning, and the vendor's own sunset page becomes the exhibit.

The discipline is small: a dated dependency register, and a written notice to the client or stakeholder when something on it moves. Which produces the other half of the rule — you can't be liable for a risk you documented; you are certainly liable for one you never raised. A declined remediation, recorded, is a closed risk. An unraised one is an open liability with your name on it.

Signed, non-destructive release management

If a release can silently overwrite what came before, no downstream record can be trusted — because nobody can prove which version produced it. The standard worth holding, end to end:

• Additive, not destructive. Promotion adds a version; it never overwrites the prior one. Rollback is selecting an earlier version, not reconstructing it.
• Signed at the boundary. Each release carries a signature and a content hash, so "what shipped on the day in question" is verifiable by someone who wasn't there — including a party who does not trust the publisher.
• Separation of duties. Whoever reviews does not promote. This is ordinary segregation-of-duties practice, and it is what makes a release record evidence rather than assertion.
• Every release leaves a row. Who promoted, from which version, at what time, against which review.

Self-improving test loops owe their own verdicts

AI-assisted testing changes what "we tested it" means. A loop that writes and revises its own tests is powerful and entirely legitimate — provided it keeps a record of what it asserted, when, and what changed. Otherwise "tested" is a claim about a system that no longer exists.

The obligation, stated plainly: a self-improving loop must be non-destructive and must keep its verdicts. Each run appends — the assertion, the version it ran against, the outcome, and the rubric used. A later run may supersede an earlier verdict; it may not erase it. That single property is what separates a test suite from a story about a test suite, and it is what lets an AI-driven pipeline be shown to a reviewer at all.

Assessment that doesn't wait six months

The hardest structural problem in this calendar is not technical. It is that the deadlines move in weeks and enterprise procurement moves in quarters. An organization can know exactly what it needs and still be unable to adopt it in time, because every tool — regardless of what it does — enters the same queue.

That queue exists for a good reason: most tools take custody of data, add a processor, widen the attack surface, or create a dependency that is painful to remove. Those genuinely deserve months of review. But the calculus is different for a control that:

• takes no custody — the record stays in systems the organization already owns;
• is additive — it installs beside the existing stack, and removal is a deletion rather than a teardown;
• adds no new party to the data path — no new processor, no new destination;
• is reviewable by the people who own the risk — the SME, the privacy or security stakeholder, the operator — because what it does is legible in an afternoon.

For that class, the right review is a short, expert one by the stakeholders accountable for the outcome, not a full vendor-onboarding cycle. Assessment should be proportional to what a tool can do, not uniform by category.

And the asymmetry underneath it is the part worth saying out loud: nobody has ever been penalized for introducing security. No regulator has fined an organization for logging consent, for keeping a price history, for signing a release, or for being able to produce evidence. Every penalty in the calendar above landed on an absence — a missing record, a broken path, an unprovable claim. Which inverts the usual risk framing: waiting is the only option with a downside. Adopting the record early costs a review; adopting it late costs the fine, the remediation, and the explanation.

The one-page version

• The dates are public. The pattern is one direction: records, not settings.
• Four artifacts satisfy nearly all of it: consent record, price history, provenance record, dependency register.
• Builders owe a dated register, a written warning, signed non-destructive releases, and test loops that keep their verdicts.
• Security controls that take no custody and can be removed cleanly deserve a proportional review — days, by the people accountable — not a six-month queue.
• Introducing evidence has never carried a penalty. Failing to have it always has.