Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Consent preference keeper series ~5 min read

How a withdrawal propagates

The resolver being right is necessary and not sufficient, because several systems in any real business hold their own list and send from it. A withdrawal that is recorded correctly and not pushed is, from the recipient’s point of view, no withdrawal at all.

Key takeaways

  • Every system that holds its own list gets the withdrawal pushed to it.
  • The push is verified by reading back, not assumed from a success response.
  • A system that cannot be pushed to gets a task for a person, on a clock.
  • Unverified suppressions after 24 hours are escalated as a real finding.
  • A quarterly reconciliation compares every list against the authoritative state.

Push, then verify

How a consent withdrawal is pushed to downstream systems and verifiedA vertical chain of five steps entered by a box labelled A withdrawal event, recorded. Step one asks which systems hold a copy, from a register that records a push method for each. Step two pushes the suppression per system with retries; a system with no API exits to a task for a person. Step three reads it back to check whether it now shows as suppressed; not confirmed exits to retry and then escalate. Step four records confirmation with a timestamp per system. Step five is All systems confirmed, at which point it is real. A note says reading back is the step that catches the API that returns two hundred and does nothing.AWS ACCOUNTA withdrawal eventrecordedWhich systems hold a copy?from the registerSystem registerpush method eachPush the suppressionper system, retriedNo APIa task for a personmanualRead it backdoes it show suppressed?Not confirmedretry, then escalatenoRecord confirmedwith a timestamp, per systemAll systems confirmednow it is realReading back is the step that catches the API that returns 200 and does nothing.
Fig 1. How a withdrawal reaches every system. The read-back is the difference between believing a suppression happened and knowing it did.
  • Machine learning
  • Security & identity
  • Management
  • Analytics
  • People

Why read back

A suppression API returning success means the request was accepted, which is not the same as the person being suppressed. In practice several common platforms will accept a suppression against an address that is not in the list they will actually send from, accept one with a subtly different email casing, or queue it behind a sync that runs hourly.

Reading the person’s status back a few seconds later catches all of those, costs one extra call per suppression per system, and converts “we sent the suppression” into “the suppression is in place”, which is the claim that has to be true.

Systems with no API

Every small business has one: a tool with no programmatic suppression, a spreadsheet somebody mail-merges from, a partner who sends on your behalf. Those cannot be pushed to and pretending they can be is worse than admitting it.

So the register records the push method per system, and a manual one produces a dated task for a named person with the specific address and a link. It is on the same clock as every other system: unconfirmed after twenty-four hours is escalated.

The twenty-four hour rule

How an unconfirmed suppression is escalatedA horizontal row of five boxes. Withdrawal recorded: the state is immediate. Pushed: to four systems. Three confirmed: within seconds. One unconfirmed: after twenty-four hours. Escalated: as a compliance finding. A note says this is the finding that matters and everything else in the system is bookkeeping.AN UNCONFIRMED SUPPRESSIONWithdrawal recordedstate is immediatePushed4 systems3 confirmedwithin seconds1 unconfirmedafter 24 hoursEscalatedas a compliance findingThis is the finding that matters. Everything else in the system is bookkeeping.
Fig 2. What happens when a suppression cannot be confirmed. This is the one thing in the system that escalates as a genuine finding rather than a task.
  • Machine learning
  • Security & identity
  • Management

Twenty-four hours is chosen because it is well inside any reasonable expectation and because most transient failures resolve within minutes. A suppression still unconfirmed the next day is not a transient failure; it is a system that is going to keep sending.

Quarterly reconciliation

The push handles changes. It does not handle the list that drifted for reasons nobody saw: an import that added people, a sync from an old backup, a system that was re-connected and re-populated from stale data.

So once a quarter, every system’s full list is pulled and compared against the authoritative state. Anybody present in a downstream list who should be suppressed is a finding, and the count of those over time is the honest measure of whether the propagation is actually working.

In practice the first reconciliation always finds something, usually in the system that was connected last, and finding it that way is much better than finding it because somebody complained.

Next: what the evidence has to look like.

All posts