Consent, sensitive data and traceability

Everything is settled as the prospect comes in. They do not consent “to messages”: they consent to a purpose, on a date, on a precise wording — and their proof comes in with them.

A prospect arrives through a form, a preference page, an import or an API call — and arrives with their proof: the source of the collection, the address of the form and the exact wording of the box ticked are recorded at the moment of the act, never reconstructed afterwards.
An append-only register of acts: one act = one purpose × one status, with its own proof context.
Purposes are distinct — prospecting, open measurement, click measurement, processing of sensitive attributes — and are never inferred from one another.
A refusal is kept as proof, never applied the other way round: it authorises nothing and it is not erased.
A withdrawal takes effect immediately: the running send stops, the segments that depend on it exclude the contact, the derived journeys release them.
The current state per purpose and the full register are readable by API call, and included in the right-of-access export.

What a consent act contains

The purpose and the status: granted, refused, withdrawn.
The date of the act, in universal time.
The collection source: form, preference page, import, API call.
The exact wording presented to the person when they ticked the box.
The address of the form and, where applicable, the address of a proof kept by the controller.

Two pixels, two regimes

An e-mail may carry two pixels that look alike technically and have nothing in common legally. They are never conflated.

	Deliverability pixel	Performance pixel
Regime	Exempt from consent	Subject to consent
Inserted	If the template enables it	Only with a valid open-tracking consent at render time
What is written	The last-open date, to the day, overwritten	An open event and the day’s aggregate
Never kept	IP, user agent, precise time, history	IP, user agent
Purpose	Adapt frequency, stop writing to inactive contacts	Measure performance, on consenting contacts only

The pixel request of a contact who objected, unsubscribed or withdrew consent writes nothing — not even an application trace carrying their address. Links are only rewritten if click-tracking consent is valid at render time; otherwise the original link goes out as it is.

Only the performance pixel feeds a journey: the deliverability pixel emits no event, it writes a date.

Data-subject rights

What a person can obtain, and by which path.

Unsubscribe: a link in every marketing e-mail, one-click unsubscribe (RFC 8058) and the matching headers, with immediate effect.
Preferences: a page in the space’s branding to choose subscriptions, choose what may be measured, or stop everything.
Access and portability: one call returns attributes, consents, subscriptions, enrollments and events.
Access history: a per-data-subject export says everything that was done to that person, by whom and when — reads included.
Erasure: irreversible anonymisation of the record, with only the consent proofs and the suppression fingerprints surviving, because they exist to never write again.

Sensitive attributes

Every contact attribute carries a class. This is not an interface convention: the class decides, server-side, where the value is written, who may read it back, and what is logged about it.

Class	What it holds	Where the value is written	Who may read it
Technical	Counters, statuses, preferences with no personal reach	With the contact record	All roles
Personal	Name, e-mail address, phone, postal address	With the contact record	Customer roles only
Sensitive	Answer to a questionnaire, from a closed list of values	Dedicated table, encrypted, outside the record	Customer roles holding the named permission, every read logged

Whatever derives from sensitive data is sensitive too: membership of a segment defined on that criterion, the journey assigned, the events of the differentiated series. The “not concerned” cohort is sensitive data just as much as the other one.

Encrypted, and still segmentable

Column-level encryption (AES-256-GCM), key version recorded next to the value, rotation by a scheduled job.
Beside the encrypted value, a one-way derived index: it makes equality and membership of a value list possible, never ordering nor substring matching. Any other operator is refused.
A sensitive attribute has a closed list of values; a value outside the list is refused, and the error response never repeats the value sent.
The class cannot be undone: the attribute cannot be reclassified, a value still carried by a contact cannot be removed from the list, and the definition cannot be deleted while a segment uses it.

Dedicated consent, minimisation and threshold

A consent purpose of its own for the processing of that data, collected with its proof like every other.
Without it, the contact belongs to no segment built on a sensitive attribute, enters no journey derived from one and is part of no derived audience. Withdrawing it exits them immediately.
A sensitive value is not a merge variable: the message is differentiated by choosing the journey, never by inserting it into the body of the e-mail.
Never in an application log, never in an export, never in a webhook body — outbound payloads carry opaque identifiers only.
Any counter served to a platform operation role below twenty people is masked, zero included, and so are the rates that could be derived from it. A customer role receives the exact value.

Audit log

Reading a record, listing contacts, downloading an export, sending a series: every access to personal data and every change is written to an append-only, hash-chained log, kept in the same database as the data.

Tamper-evident: update and delete are refused by the database itself. Every entry carries the fingerprint of the previous one, and a daily chain verification tells a changed content from a removed or reordered link.
Named on the actor side: the key used, and the person who triggered the action when it comes from an administration interface, through a signed header that names without authorising.
A refusal is logged with the operation attempted, and no read entry accompanies it: a person’s history never fills up with accesses that did not happen.
Per-data-subject export: everything that was done to that person, by whom and when, returned in one call — and that read is itself logged.
Nothing is shipped to an outside tool: the log does not leave the deployment’s perimeter.

What is written, and what never is

Written: the actor, the date in universal time, the call, the resource, the request identifier, the nature of the operation.
Written: the names of the fields read or written, and a distinct marker when a sensitive field was touched.
Never written: the value of a field — no address, no attribute, no search term.
Never written: a raw IP address. A truncated, salted fingerprint correlates two requests from one origin without ever recovering the address.
Nothing at all when a role that does not see a field queries the record: there was no consultation.

Retention, anonymisation, reversibility

Periods configurable per space, an irreversible exit, and a way out that is not in our hands.

Six periods configurable per space — contacts, events, audit log, webhook deliveries, export files, test sends — enforced by an automatic purge.
The audit log is subject to a contractual floor: a lower value is refused, never silently raised. A setting that does not do what it says is worse than a refusal.
Irreversible anonymisation of an inactive contact, in one transaction: address, address fingerprint, names, external identifier, personal attributes, sensitive values, consent acts and memberships destroyed; the pseudonym derives from the internal identifier, never from the address. The record stays readable, empty, so that its audit history still means something — and it is excluded by construction from every segment, hence from every send.
Statistical aggregates are untouched: they only ever carried identifiers and numbers.
What is never purged: the consent proofs of still-active contacts, the aggregates, and the suppression-list fingerprints — never writing to an address again is an obligation that outlives the record it came from.

Reversibility export and permanent deletion

A complete archive, one file per table, encrypted for the customer’s public key: the platform never receives a private key.
The archive comes with an inventory of the tables included and the reason for each exclusion; the operation is logged with the number of people concerned.
Permanent deletion happens in two steps: a first call checks that a recent export exists and issues a short-lived confirmation token; the second triggers the erasure.
The report — table names, counts, timestamps, signature — is written before the log is purged and outlives the deleted space. It contains no personal data.

No data leaves the perimeter

The list of outbound flows is short, and none of them carries personal data.

No third-party e-mail service provider: the platform hands messages to the recipients’ mail servers itself.
No third-party audience analytics or telemetry — not on this website, not in the platform, not in the public pages sent to recipients.
No external object storage: images, exports and archives stay in the deployment’s encrypted, backed-up database.
Webhook bodies and export files: opaque identifiers only, never an address.
Logs built from an allowlist: only explicitly permitted keys are written, including in error traces.
Background job payloads reduced to identifiers: content is read back from the database at execution time, never carried in the queue.

What the platform knows, and what it refuses to know