Security and compliance

Missivia is designed for regulated environments. This page lists verifiable facts about how the platform handles data; it is written for data protection officers and chief information security officers. It describes what is in place, not what is planned.

This page is a summary of the posture. Details of authorisation management are on Authorisation and access; details of consent, sensitive data, the audit log and retention are on Consent, sensitive data and traceability.

The central point

Authorisation management

Who sees what is never decided by the interface. Every call is arbitrated by the server, from a single matrix that combines the space concerned, the person’s role, their named permissions and the class of the key used.

Entities, spaces and memberships

An organisation holds spaces, one per data perimeter: a brand, a subsidiary, an environment. Each space carries its own contacts, lists, journeys, sending domains, quotas and retention periods.
A person reaches a space through a membership, which carries their role in that space; the same person may be an editor here and a plain viewer elsewhere.
The space concerned by a call is derived from the authentication token and never accepted as a parameter. Every database query goes through an access layer that enforces it.
A resource belonging to another space answers “not found”, never “forbidden”. Every resource type has an automated isolation test, run in continuous integration.

How an authorisation is computed

1
Space
The call is bound to a space, derived from the token. It cannot name another one.
2
Role
The membership brings a role, that is, a set of capabilities inherited as a whole – not a checkbox per screen.
3
Named permissions
They add to the role, one at a time, and are granted to a designated person: access to sensitive fields is one of them.
4
Key class
Every API key carries a class that caps the whole: what it cannot reach, no role can give back to it.
5
Decision
A single matrix decides, server-side, and records its decision in the audit log – refusals included.

Rights that are inherited, cumulative and capped

Inherited. A role is a coherent set of capabilities, not a list of exceptions. You change the role of a membership; you do not revisit thirty checkboxes.
Cumulative. A named permission – access to sensitive fields, for instance – adds to the role without replacing it. It is granted and withdrawn separately, and its grant is dated and logged.
Capped. The class of the API key bounds the result: a capability may be stored on the key and never exercised, and a key meant for technical operations does not reach a contact record, whatever role accompanies it. Creating a key with a capability outside its class is refused, with the list of rejected capabilities.
Verifiable. One dedicated call returns what the key can effectively do: the intersection of what it carries and what its class allows. An interface builds its navigation from that.

Technical / data separation. The platform’s operating roles run the sends and administer the technical side; none of them reads a record, an identifiable event, a message or an identifiable export.
No impersonation. A platform role cannot borrow a customer user’s account, or “view as” them.
Indistinguishable refusals. Access that has not been granted returns “not found”: whether someone has access to people cannot be observed. The refusal is recorded in the log, and no read entry is, because there was no read.
Two-factor authentication mandatory for everyone, with no exception by role; single sign-on through the customer’s identity provider is available.
Least privilege on keys: explicit capabilities, restriction by IP address or range, rate-limited authentication failures, immediate revocation, secret never returned after creation.

The matrix, in plain words

What each role reaches. “Read” means consultation without modification; “—” means the operation does not exist for that role. The first three columns are roles of the customer, who is the data controller; the last two are platform operating roles.
What is requested	Data administrator	Editor	Viewer	Operations	Technical administration
Records, histories, identifiable exports	Yes	Yes	Read	—	—
Sensitive fields of a record	With a named permission, and logged			—	—
Consents and data-subject rights	Yes	Yes	Read	—	—
Lists, segments, journeys, campaigns	Yes	Yes	Read	Yes	—
Templates, files, public pages, webhooks	Yes	Yes	Read	Yes	Yes
Statistics	Exact values	Exact values	Exact values	Aggregates, masked below threshold	Aggregates, masked below threshold
Retention periods, full export, permanent deletion	Yes	—	—	—	—
Keys, domains, integrations, job health	Yes	—	—	—	Yes
Audit log	With identities	With identities	With identities	Without identities	Without identities

The restriction is published in the API contract, operation by operation: it can be read before it is tested, and an automated check fails if an operation serving personal data is added without being covered.

Hosting: two deployment modes

The same product is deployed in two ways. The standard mode is the default; it is not health data hosting.

Standard, by default

Hosted in France, in the Paris region, with a French hosting provider named in the contract.
Encryption in transit and at rest, isolation per space, chained audit log, automatic database backups with the hosting provider.
For any use without health data.

Health, as an option, under contract

The same product, as a dedicated instance, deployed with a hosting provider certified as an Hébergeur de Données de Santé (HDS, the French certification for health data hosting).
The scope, the deployment environment and the responsibilities of each party are defined in the contract.
The certification applies to the hosting provider, not to the platform: see Health data hosting.

The product’s guarantees apply in both modes: consent per purpose, sensitive data encrypted outside the record, statistical masking below the display threshold, tamper-evident audit log, authorisation computed server-side.

Sub-processing and outbound calls

A single sub-processor for the platform: the hosting provider. The platform’s operational e-mails go out through that same provider’s mail relay.
By default, no third-party e-mail service provider: the platform hands messages directly to the recipients’ mail servers, from its own IP addresses. A space without health data can entrust delivery to an external router, using its own account: that provider is then chosen by the customer. A space that holds health data stays on built-in delivery, by construction.
No third-party analytics or telemetry, on this website, in the platform, or in the public pages sent to recipients.
No external object storage for the platform’s data: images, exports and attachments stay within the perimeter, in the encrypted database of the deployment.
Outbound calls made by the platform itself: recipients’ mail servers (e-mail delivery), certificate authority (issuance and renewal of TLS certificates), mailbox-provider reputation services (aggregates about our own IP addresses and domains). What a space sends out through a workflow only goes to the connections it has declared, classified and logged (see Workflows).

Data protection

Encryption in transit: TLS with HSTS for the API, the public pages and this website; STARTTLS for SMTP exchanges.
Encryption at rest of signing keys (DKIM), webhook secrets and test-send addresses with AES-256-GCM; API keys stored hashed; passwords hashed with Argon2id.
Automatic database backups, with the hosting provider.
No rendered message body is kept: the e-mail is composed at delivery time, and on demand for its online version. The most exposed copy of the most sensitive data simply does not exist.
Logs built from an allowlist: only explicitly permitted keys are written. No e-mail address, no subject, no body, no attribute value – 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.
Space isolation enforced on every query; a resource belonging to another space is reported as not found.

Sensitive data and health data

Every contact attribute carries a class – technical, personal, or health – declared by the customer. The class decides where the value is written, who may read it back and what is logged about it.

A health-class value is never written with the record: it goes into a dedicated table, encrypted at column level with AES-256-GCM, with the key version recorded beside it and rotation by a scheduled job.
Beside the encrypted value, a one-way derived index allows segmentation by equality or membership in a list of values – never ordering, never substring matching. Any other operator is refused.
A health attribute takes values from a closed list; a value outside it is refused, and the error response never echoes the value that was sent.
The health class is irreversible: 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: a purpose of its own for the processing of health data, collected with its proof. Without it, the contact belongs to no segment built on a health attribute and enters no journey or audience derived from one. Withdrawing it immediately removes the contact from every running derived journey.
Minimisation: a health value is not a merge variable – differentiation comes from the choice of journey, never through inserting the value into the e-mail. It appears in no log, no statistics export and no webhook body, which carry opaque identifiers only.
Aggregation threshold: any counter served to a platform operating role below a threshold (twenty people by default) is masked, zero included, and so are the rates that could be derived from it. A customer role always receives the exact value.

Consent per purpose, with proof: who, when, wording shown, source of collection. A refusal is kept as proof.
Two separate pixels: a deliverability pixel (exempt, writes only the last-open date, to the day) and a performance pixel, inserted only if a valid tracking consent exists at render time.
Unsubscribe link in every marketing e-mail, one-click unsubscribe (RFC 8058) and List-Unsubscribe / List-Unsubscribe-Post headers.
Preference page in the customer’s branding: subscriptions, measurement permissions, global unsubscribe. Every change writes a consent act with its exact wording, its source and the URL of the form.
Service messages kept separate from prospecting sends: distinct legal basis, no performance measurement.
Access and portability: one call returns a person’s attributes, consents, subscriptions, enrolments, events and messages received – with no message body. Restriction of processing and objection to profiling are enforced by the server (see Data-subject rights).

Audit log

Every read of personal data and every write is logged: actor (key, named user or automated job), role, action, resource, call, request identifier, UTC timestamp.
Only the names of the fields read or written are recorded, never their values – no address, no attribute, no search term. No raw IP address: a truncated, salted fingerprint correlates two requests from the same origin without ever recovering the address.
A distinct marker flags that a health field was touched. A read by a role that does not see the field produces no such marker: nothing was accessed.
Tamper-evident: the log is append-only; update and delete are refused by the database itself, and writes go through a database function that only accepts an append at the end of the chain. Every entry carries the fingerprint of the previous one and is sealed with a platform key – actor, resource and timestamp included. A daily chain verification detects any break and raises an alert.
Anchored and verified from outside: every day, the head of each chain is deposited in immutable object storage (thirteen-month compliance lock, in France), and a verification independent of the application process re-reads every version of the anchors, checks them against the database and recomputes every chain. A discrepancy is treated as a potential security incident.
Per-data-subject export: everything that was done to a person – reads included – by whom and when, returned in one call. That read is itself logged.
An authorisation refusal is recorded with the attempted operation; no read entry accompanies it. A person’s history never fills up with accesses that did not happen.
Actions taken from an administration interface are attributed to the human user who triggered them, through a signed header, alongside the key used. The header grants nothing: authorisation still rests on the class of the key.
The administration console’s own acts – invitations, roles, revealing an address, account management – are relayed to that same chained log, timestamped on receipt by the server, with an attestation of the actor, with a pseudonymised actor and no e-mail address; a relay replayed with different content is refused.
In the log served to platform operating roles, every identifier tied to a person is masked.

Retention, anonymisation and reversibility

Periods configurable per space for contacts, events, the audit log, webhook deliveries, export files and test sends, enforced by automatic purge.
The audit log is subject to a contractual floor – the contact retention period plus one year. 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 inactive contacts, in one transaction: address, address fingerprint, names, external identifier, personal attributes, health values, consent acts and memberships are destroyed; the pseudonym derives from the internal identifier and not from the address. The record remains readable, though emptied, so that its audit history still makes sense, and it is excluded by construction from every segment, hence from every send.
Statistical aggregates are untouched: they only ever held identifiers and numbers.
Reversibility export: a full archive, one file per table, encrypted member by member for the public key supplied by the customer. The platform never receives a private key. The archive comes with an inventory of the tables and the reason for each exclusion; the operation is logged with the number of data subjects concerned.
Permanent deletion 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 is never purged: consent proofs of contacts that are still active, aggregates, and suppression-list fingerprints – the obligation never to write to an address again outlives the record it came from. The addresses on that list are stored encrypted, bound to their row, never in clear text.

Operations and deployment

No manual operation in production: schema migrations are code embedded in the release and executed at deployment, never a command run by hand.
Deployment by verified build artefact – no history, no tests, no development tooling – published only after a green continuous integration run. Rolling back means redeploying the previous release.
Blocking continuous integration: static analysis, type checking, API contract regenerated and compared, unit, integration and space-isolation tests, secret scanning, dependency audit, actual start-up of the artefact.
A separate pre-production environment, with a dedicated database and generated synthetic data, where every version is validated before production. No production data outside production: no backup copy, no restore elsewhere, no extract in an integration artefact.
No secrets in the repositories: every sensitive variable is set in the runtime environment. Start-up refuses an empty value, a sample value, an insufficient length or two identical secrets.
Operations secret vault: secrets are kept in the hosting provider’s secret manager and projected at run time; they appear neither in the deployment manifests nor in the images.
Infrastructure access keys are subject to a scheduled annual rotation.

Operational security

Brute-force protection on API keys: authentication failures rate-limited per IP address. Per-token rate limiting on public pages.
Security event logging: rejected authentications, revoked keys, threshold breaches, audit chain break, anchor discrepancy.
Export files encrypted at rest, delivered through a signed link valid for fifteen minutes and limited in number of downloads; the link never appears in the webhook delivery log.
Messages DKIM-signed by the platform at send time (keys never leave the perimeter), signed return addresses: a forged bounce or complaint is refused before being read. Webhooks received from providers signed with a timestamp, replay refused.
Monitoring and alerts: service availability, public probes and TLS certificates watched continuously, alerts sent to operations.
The platform’s operational e-mails sent from a dedicated domain, separate from customers’ sending domains, authenticated with SPF, DKIM and DMARC, through a relay that requires TLS.
Guard against internal targets (SSRF) for webhooks, workflow connections and their verification: addresses canonicalised before deciding, connection pinned to the validated address, redirects never followed.
Size bounds on what comes in and what is computed: imported archives, workflow files, CSV records, values produced by rendering; regular expressions run by a linear engine, within a budget.
Monitoring of software dependencies and published vulnerabilities.
Written security incident procedure: qualification, containment, notification to the French data protection authority within 72 hours, informing the customers concerned.
Responsible disclosure of a vulnerability: security@dataventure.com.

Health data hosting (HDS)

Missivia is not itself HDS-certified, and cannot be: the certification applies to a legal entity that hosts health data on behalf of a third party, not to a piece of software. When the data calls for it, the platform can be deployed in Health mode, on HDS-certified hosting, under a contract defining the scope, the deployment environment and the responsibilities of each party.

The standard mode is not health data hosting: outside such a contract, no health data should be entrusted to the platform.

Last update: 2026-10-13 · Questions and reports: security@dataventure.com