GDPR for SFMC Devs: What to Ask, What to Build

Developers don't need to read the GDPR text. The legal team will handle interpretation. But the developer does need to know which questions to raise during discovery and which fields to configure in SFMC so the setup doesn't block go-live when legal finally reviews it.

Here's the short version we share with every engineer joining an SFMC engagement.

Questions to raise during discovery

Any "no" or "unsure" answer is not a developer decision - escalate it to the client's legal team and wait for direction. Building on an unclear compliance foundation is the kind of thing that gets flagged in a post-go-live audit.

What to build in SFMC when GDPR applies

Consent_DE to prove consent exists

Create a Data Extension that captures the consent event for each subscriber. Minimum fields:

This is the record you point to when a regulator asks "prove this subscriber consented." Without it, consent is unverifiable, which under GDPR means it doesn't exist.

Double Opt-In on every new subscriber form

When a user submits a form on the client's website, the flow should be:

1. Form submit writes to Pending_Subscribers_DE.
2. SFMC sends a confirmation email with a confirmation link.
3. Link click writes the record to Master_Customer_DE + Consent_DE.
4. No email marketing until step 3 completes.

Double opt-in drops your spam complaint rate, improves deliverability, and produces the audit trail GDPR wants. It also filters out typos and bot submissions.

Data Retention Policy on Data Extensions

SFMC has a built-in Data Retention Policy setting per DE. Configure it:

• Never keep raw tracking data longer than the client's policy allows (often 2 years).
• Delete records that haven't been active in X months, where X is defined by the client's policy.
• For DEs that hold PII, always set a retention policy. "Keep forever" is not a defensible answer under GDPR.

Contact Delete for Right to be Forgotten

If a subscriber exercises their Right to Erasure under GDPR, the client has up to 30 days to delete their data. SFMC provides a Contact Delete feature:

• Setup > Contacts > Contact Delete
• Request deletion by Subscriber Key.
• Data Extensions with the subscriber's records get purged on a scheduled job.
• Cannot be undone. Confirm with the client in writing before executing.

Document the process. Once the feature runs, the subscriber is gone - no rollback.

Patterns we avoid

• Pre-checked opt-in boxes - not valid consent under GDPR.
• Forcing email to purchase without a separate marketing opt-in - transaction email OK, marketing email requires its own consent.
• Importing a subscriber who previously unsubscribed - regardless of source, re-importing an unsubscribe is a violation.
• Purchased lists from "GDPR-compliant" vendors - no such thing. Consent is given to a brand, not resold.

What's not the developer's call

The legal interpretation of what counts as "consent" under GDPR belongs to the client's legal team. The developer's job is:

1. Ask the right discovery questions.
2. Build the mechanisms that let the client be compliant.
3. Document how consent flows through SFMC so legal can review it.

Going beyond that - approving whether a specific campaign is compliant, drafting privacy notices, deciding retention windows - is the client's legal team's call.

Takeaway

GDPR stops being scary once you learn the eight fields it actually wants you to capture. Build the Consent_DE, turn on Double Opt-In for new forms, configure retention policies, and document the Contact Delete process. Legal will tell you when the content is compliant. The plumbing is the developer's responsibility, and it's not complicated.

---

Shipping an SFMC build with EU subscribers? Our Salesforce team sets up consent capture, preference centers, and retention policies on production engagements. Get in touch ->

See our full platform services for the stack we cover.