Objection Register

A team moves personalisation from consent to legitimate interests to raise coverage. Nothing in the code changes and that is the bug. A consent design is default-deny: absence of a grant means no processing, so a broken permission lookup produces missed emails. A legitimate-interests design is default-allow with a right to object, so the same broken lookup produces processing of people who told you to stop.

The failure mode inverts, and it inverts towards the worse of the two. A missed send is a revenue annoyance. Marketing to someone who objected is a breach of an absolute right, since the right to object to direct marketing under GDPR Article 21(2) has no balancing test and no exception, unlike the qualified objection right at Article 21(1) that applies to other legitimate-interests processing.

An objection register is the structure that makes default-allow safe: one durable, append-only store of who objected, to what, and when, consulted at the point of use by everything that processes.

Why it matters

Most organisations have a consent store and treat opt-outs as a flag on a marketing list. That works until the second channel appears. The register is the single place all of them read, which is what makes the answer to "prove nobody who objected was processed" a query rather than an investigation.

It also carries a second obligation the consent store does not. For objections under Article 21(1) the controller may continue only where it can demonstrate compelling legitimate grounds that override the person's interests, so the register must hold the outcome of that assessment and who made it, not just the objection.

Implementation patterns

• Append-only rows of (subject identifier, scope, channel, timestamp, source, outcome). Scope matters: an objection to profiling is not an objection to transactional email.
• Identifier plurality. People object by email address, phone number, device identifier or account id, often not the one you key on. Index all of them and resolve at query time rather than merging at write time.
• Consulted at use time by batch jobs too. The classic gap is not the request path; it is the nightly segment build that snapshotted the audience yesterday. Pass the register as a filter at send time, not at segment time.
• Propagated to processors with a tighter clock than your own. A partner that syncs suppressions weekly makes your register decorative.
• Retained after account deletion. A suppression record must outlive the data it suppresses, or a re-import resurrects the person. Keep the minimum: a hashed identifier and a date.

Industry example

The pattern is in production in any large consumer platform that runs both transactional and marketing messaging through the same delivery infrastructure. The suppression check sits in the sending service rather than in each campaign tool, because the alternative is one check per tool and one gap per tool. Organisations that learned this the hard way generally learned it from a campaign sent by a newly integrated vendor that had never heard of the register.

Failure scenarios

• Objection recorded centrally and honoured nowhere. The register is correct and the send list was built from a 24-hour-old export.
• Scope collapsed to a boolean. An objection to profiling suppresses the delivery receipt too, and the business quietly disables the check.
• Identifier mismatch. The objection arrives from an email address; the campaign keys on device id; both belong to the same person and neither knows it.
• Register purged with the account, so a later re-import from a backup or a partner file recreates the contact and the objection is gone.
• Basis switched without the register built. The team flips personalisation to legitimate interests on a Tuesday and has no default-allow guardrail until the following quarter.

Trade-offs

A register is a hot dependency on the send path, which costs a lookup per recipient of roughly 2 ms to 5 ms against an indexed store, and an availability requirement: if it is down, the correct behaviour is to stop sending, which means marketing outages. That is the price of default-allow. Consent, by contrast, is safer by construction and reaches fewer people, and that reach difference is precisely why teams switch.

The second trade is assessment cost. Legitimate interests requires a documented balancing test per purpose, maintained as the purpose evolves, where consent requires a dialogue.

When not to use it

If every purpose in the product runs on consent, a register adds a second permission store for no benefit: the consent store's absence of a grant already means no. Build one when a purpose genuinely runs on legitimate interests or on a legal obligation with an objection right attached. And do not switch basis to avoid a consent dialogue if you cannot build the register first, because the switch takes effect the day it is made and the guardrail takes a quarter. For a product with one channel and a few thousand customers, a suppression table with a single owner is the whole pattern and anything larger is over-built.

Interview question

Q: Your company changes the lawful basis for product recommendations from consent to legitimate interests. Marketing expects coverage to roughly double. What do you build before that change ships, and what would you tell the board is now riskier?

What a strong answer covers: the inversion from default-deny to default-allow and why it makes a lookup failure unlawful rather than merely lossy; the register consulted at send time by batch jobs as well as the request path; identifier plurality and scope; suppression records outliving the account; propagation clocks for processors; and the point that the absolute objection right for direct marketing does not allow the balancing argument that justified the switch elsewhere.

Quick check

Quiz: Why is a broken permission lookup worse under legitimate interests than under consent? Because consent is default-deny so a failure means nobody is processed, while legitimate interests is default-allow so the same failure means people who objected are processed.

Flashcard: Where does an objection register have to be consulted that a consent flag usually is not? In the batch path: the nightly segment build must be filtered at send time, since an audience snapshot taken yesterday cannot know about today's objections.