Consent, sensitive data and traceability

Everything is decided when 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 form’s address 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 read as consent: it authorises nothing and it is not erased.
A withdrawal takes effect immediately: the send in progress 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 data 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

Consent to open measurement:

The two pixels are never conflated: one is exempt and writes only a date, the other exists only if consent to measurement is valid at render time.

A pixel request from 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 unchanged.

Only the performance pixel feeds a journey: the deliverability pixel emits no event, it only 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 from the mail client (RFC 8058) and the matching headers, with immediate effect. The link in the message body leads to a confirmation page with a single button, no script, showing only the masked address: a bot that follows the links in a message – an antivirus, a preview – no longer unsubscribes anyone.
Preferences: a page in the space’s branding to choose subscriptions, choose what may be measured, or stop everything.
Access and portability (GDPR Article 15): one call returns attributes, consents, subscriptions, enrolments and events – and also the messages received (subject, dates, status; no body, since none is kept), any suppression-list entry, times processed through workflows, the names of the sensitive attributes that are set and the history of the requests made.
Access history: a per-data-subject export shows everything that was done to that person, by whom and when – reads included.
Restriction of processing (Article 18): the contact is kept, readable and correctable, but nothing further is sent to them. They leave running journeys, belong to no segment, enter no list, no workflow source or action, no trigger; their score is frozen and end-of-retention anonymisation is suspended. The reason is one of the four cases the law provides for, with no free text; lifting it restores the previous status.
Restriction follows the address: a send to an ad hoc address that matches a restricted contact is refused, without saying that a contact exists.
Objection to profiling (Article 21): a dedicated purpose. A refusal or a withdrawal excludes the person from every segment and every filter, freezes their score and blocks its recomputation; they remain reachable by list and by service message.
Erasure: irreversible anonymisation of the record, with only the consent proofs and the suppression fingerprints surviving, because their purpose is to ensure the address is never written to 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 scope	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 in a list of values possible, never ordering or 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 – and a strict proof: a grant without the exact wording shown or without a source is refused.
No sensitive value is written to a contact that does not hold that grant at the time of writing: by call, by import or by workflow, the write is refused and nothing is written. A grant received in the same call is applied before the value.
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 removes the contact from 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 a statistics export, never in a webhook body – outbound payloads carry opaque identifiers only. Through a workflow, it only leaves encrypted, to an attested health connection.
Any counter served to a platform operating role below twenty people is masked, zero included, and so are the rates that could be derived from it. When a masked value could be recovered by difference with a total, one more cell is masked: the complement gives nothing away. 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 altered content apart 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.

Five consecutive entries, each carrying the hash of the previous one.

READ contact record · field names logged, values never written h 3f2a…
WRITE consent act · purpose, status, exact wording ← 3f2a… · h 9c17…
DENIED read of a record by a platform role · 404 not found · no read entry accompanies it ← 9c17… · h b48e…
EXPORT access history of a data subject · and that read is logged in turn ← b48e… · h 71d0…
READ sensitive field · named permission · distinct marker ← 71d0… · h c9a5…

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 remains readable, though 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 – the obligation never to write to an address again 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.

What leaves the perimeter is declared

The list of outbound flows is short, and each one is chosen by the space, classified and logged.

By default, no third-party e-mail service provider: the platform hands messages to the recipients’ mail servers itself. An external router is only used if the space chooses one, and never for a space that holds health data.
A workflow only delivers to the connections declared by the space, each with its data class, and every deposit is logged by field names. Health data only leaves encrypted, to an attested SFTP connection.
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 for the platform’s data: images, exports and archives stay in the deployment’s encrypted 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

Consent per purpose