GDPR by design: what should you record at the point of collection?

Jean RubensUpdated August 20269 min read

Whether your collection is compliant gets decided before the first send, in the structure of the form. Afterwards it's too late. You can't back-date a consent timestamp, and nobody accepts a good-faith reconstruction.

That's the whole point of the phrase "by design". It isn't about intent, it's about plumbing. Here's what that plumbing has to produce, and what your tools actually produce today.

What do you actually have to prove?

That the person consented, when, and in what terms. Article 7(1) of the GDPR is blunt: "the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data" (GDPR, Regulation (EU) 2016/679, Article 7). In 2025, France's CNIL received 20,150 complaints, ten percent more than in 2024.

The word "demonstrate" does all the work. It turns a good practice into a documentation duty. You don't have to prove that your form is well built. You have to prove what one specific contact saw, and did, on one specific day.

The CNIL puts it plainly: the controller must be able to demonstrate at any time that the person did consent, under valid conditions (CNIL, Conformité RGPD: comment recueillir le consentement des personnes?). "At any time" includes three years after collection.

This proof duty doesn't stand alone. Article 5(2) sets out the controller's general accountability, which includes being able to demonstrate compliance. For the full framework, see our GDPR email compliance guide for marketing teams.

The five records to keep at every collection

The CNIL asks controllers to document the conditions under which consent was collected, and suggests keeping a register of consents (CNIL, Conformité RGPD: comment recueillir le consentement des personnes?). That register comes down to five columns, and each one answers a question a complainant can ask.

The five records follow from the conditions of collection the CNIL asks controllers to document. The right-hand column lists losses we have watched happen on shared accounts.

Look at that third column. None of those losses comes from bad intent. Every one of them comes from a default setting, a rushed import, or a form rebuilt without keeping the old one. That is precisely what Article 25 of the GDPR aims to head off, by requiring measures "at the time of the determination of the means for processing".

Why does the exact wording matter more than the box?

Because consent has to be specific, and specificity lives in the words. The CNIL notes that consent must correspond to a single processing operation, for a defined purpose (CNIL, Conformité RGPD: comment recueillir le consentement). A ticked box without its text therefore proves no purpose at all.

Take the common case. You rebuild your form in March, widening the notice to "our offers and those of our partners". A contact who signed up in January never saw that sentence. Without an archive of January's wording, nothing in your list separates the two populations any more.

Mailchimp has understood this and documents it. For an audience with GDPR fields enabled, the vendor says it records "a plain-text version of your form" at signup (Mailchimp, Collect Consent with GDPR Forms). That's the wording, frozen, as it was seen.

Brevo keeps the wording too, just somewhere else. The consent text you add to your form ends up inside the double opt-in confirmation email, whose content gets logged. Brevo calls that log "crucial", because it proves you asked for consent and gave the person the information they needed.

The difference is one of filing, and it matters later. On Mailchimp the wording is attached to the audience; on Brevo it's attached to a log. Logs get purged. Audiences don't.

What do Brevo and Mailchimp actually keep?

Both keep the essentials, but not in the same place. Mailchimp exposes four dated fields in an audience export: OPTIN_TIME, OPTIN_IP, CONFIRM_TIME and CONFIRM_IP (Mailchimp, View or Export Your Contacts). Brevo files the proof in its logs instead.

And it splits it across two distinct logs. The event log holds the form submission, its time and the address. The transactional log holds the confirmation email, its content, then the date of confirmation. Brevo's own conclusion: "Exporting both log types is essential to track the end-to-end DOI process" (Brevo, Double opt-in (DOI)).

One detail is reassuring and worrying at once. The transactional log keeps the content of the confirmation email, "including the confirmation link and consent text you've added". So the wording is retained, but inside a log rather than on the contact's record.

What Mailchimp is missing sits elsewhere, and it stings during an audit. The vendor lists email signup source among the data that is "not included" in an audience export (Mailchimp, View or Export Your Contacts). You read it one contact at a time, in the interface.

The blind spot: a retention ceiling below the retention window

A Brevo retention rule can store logs "anywhere between 1 and 24 months" (Brevo, Configure a custom retention period for your transactional logs). The CNIL, meanwhile, allows three years of prospect data retention. The ceiling on the proof sits twelve months below the floor of the need.

Good news first. With no rule configured, logs are stored indefinitely, so the default doesn't betray you. The risk only appears the moment somebody decides to tidy up.

Who in your organisation knows that this slider touches compliance? It lives in the transactional email settings, under a heading that talks about performance and storage. Nothing in that screen mentions consent.

A second limit applies to high volumes. Since 1 January 2025, an account that has accumulated more than ten million email events has anything older than twenty-four months deleted, whatever its own settings say (Brevo, About the data retention policy for email events).

That deletion doesn't only hit the logs. It also strips those events from the history shown on your contacts' own detail pages. And Brevo notes that you can't currently view your account's event count, so you don't know whether you're near the threshold.

The fix fits in one sentence, and Brevo is the one who supplies it. The vendor recommends extracting transactional logs from the platform regularly, for archiving. In other words: get the proof out of the sending tool.

Why does multi-team sending break traceability?

Because compliant collection is configured at audience level, not account level. Mailchimp enables its GDPR fields audience by audience, through each one's form settings (Mailchimp, Collect Consent with GDPR Forms). Three teams, three audiences, three possible standards of rigour.

The scenario repeats everywhere. The central team wires its main audience properly. A regional team spins up its own for a trade show without enabling GDPR fields, because the option doesn't appear in the creation flow. Six months later the two audiences get merged.

Which brings compliant collection back to a question of access. Who can create an audience, import a file into it, edit a form? On Mailchimp, audience-level access control doesn't exist at any tier, as we set out in our piece on restricting a Mailchimp user to certain audiences.

On Brevo the problem takes another shape. Granular permissions do exist, but they don't cover everything, and some account settings stay bundled with other powers. We documented that mechanism for billing in who can change the plan or buy an add-on.

How do you wire compliance into collection?

In four moves, none of which means changing tools. Article 25 of the GDPR asks for measures taken "at the time of the determination of the means for processing", and Article 25(2) requires that by default only necessary data is processed. These four moves turn both paragraphs into settings.

The fourth one holds up least well on its own, because it rests on the discipline of teams that don't have GDPR as a priority. It holds up better when imports go through a person, or through a layer, rather than through direct access to the audience.

The natural next reading splits in two. How sharing one account redistributes responsibility, in our guide to Mailchimp governance for teams. And how uncoordinated sending degrades a reputation everybody shares, in our piece on deliverability on a shared account.

Frequently asked questions

Jean Rubens

Co-founder, Sendgate

Jean is a co-founder of Sendgate. He writes about email sending governance for teams: frequency visibility, access partitioning and deliverability across shared sending accounts.