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.

Mailchimp keeps the wording in a second place too. The consent text you add to your form is what the contact sees in the double opt-in confirmation email, so a copy of it lands in their own inbox, dated, outside your account.

The filing matters later. On Mailchimp the wording stays attached to the audience's GDPR settings, which is the durable place for it, as long as somebody turns those fields on for every audience rather than the first one.

What does Mailchimp actually keep?

The dates, and little else. An audience export carries four dated consent fields: OPTIN_TIME, the moment a contact reached your signup form, OPTIN_IP, then CONFIRM_TIME, the moment they clicked the link in the confirmation email, and CONFIRM_IP (Mailchimp, View or Export Your Contacts). Two of the five records, right there in a CSV.

What 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, next to "a complete record of contact profile updates" (Mailchimp, View or Export Your Contacts). You read the source one contact at a time, in the interface. You cannot get it out, and you cannot reconstruct who changed what.

The blind spot: the proof you can export is thinner than the proof you hold

The dates come out of Mailchimp. The context does not. The vendor lists email signup source and "a complete record of contact profile updates" among the data not included in an audience export (Mailchimp, View or Export Your Contacts). Your CSV proves when someone consented, and says nothing about where, or about what happened to their record afterwards.

Put that against the retention window. The CNIL allows prospect data to be kept for three years from collection or from the last contact. That is a long time for a provenance that lives only on a screen, one contact at a time.

The practical consequence fits in one sentence: get the proof out of the tool on a schedule. Export the audience with its opt-in fields every quarter, and archive it next to a dated capture of the form wording. An export you ran is a record. An export you could have run is not.

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.

The same shape appears around settings. The GDPR fields have to be switched on audience by audience, so an audience created later by a different team starts without them, and nobody is told.

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.