How do you design a Salesforce data model that supports GDPR compliance?

GDPR touches the model itself, not just the security settings on top of it:

1. Know where personal data lives: Build a field-level inventory using the Data Classification attributes — Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization — and keep it current by re-running a metadata extract each release.
2. Minimise: Challenge every personal field on the model. If there is no processing purpose, do not collect it. This is the cheapest control available and the one most often skipped.
3. Record lawful basis: Use the standard consent model — Individual, ContactPointConsent, and the related objects — so consent and preferences are captured as data rather than inferred from a checkbox on Contact.
4. Design for erasure: The right to erasure has to be executable. That means knowing every object holding personal data, including custom objects, attachments, field history, archives, and sandboxes, and having a documented hard-delete or irreversible-anonymisation process. Anonymisation is often the practical answer where transactional history must be retained.
5. Retention and audit: Field Audit Trail for defined retention on tracked fields, an agreed retention policy per object, and a legal hold process that overrides it.
6. Protect: Shield Platform Encryption for genuinely sensitive attributes — noting that encrypting a field affects matching rules, filtering, and sorting, so it is a design decision, not a checkbox.