Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Salesforce Architect
hard

How do you architect Salesforce for HIPAA / GDPR / PCI compliance?

Compliance shapes architecture deeply. Each regulation has specific requirements.

HIPAA (US Healthcare):

  • PHI (Protected Health Information) must be encrypted at rest and in transit.
  • Business Associate Agreement (BAA) with Salesforce — required.
  • Audit trails of every PHI access.
  • Authorisation tracking — who accesses what, when.
  • Right of access — patient can request their records.

Salesforce features:

  • Health Cloud with HIPAA features.
  • Shield Platform Encryption for PHI fields.
  • Field Audit Trail for retention.
  • Event Monitoring for runtime audit.
  • Salesforce signs BAA for HIPAA-eligible licenses.

GDPR (EU):

  • Lawful basis for processing personal data.
  • Right to access — user can request their data.
  • Right to be forgotten — user can request deletion.
  • Right to portability — user can request data export.
  • Data minimisation — collect only what's needed.
  • Breach notification — within 72 hours.
  • Privacy by design — built in, not bolted on.
  • DPO (Data Protection Officer) for some orgs.

Salesforce features:

  • Privacy Center — consent management, data subject requests.
  • Data Classification metadata.
  • Field Audit Trail.
  • Right-to-be-forgotten workflows (custom or via Privacy Center).

PCI DSS (Payment Card):

  • Tokenisation — don't store full card numbers.
  • Encryption — at rest and in transit.
  • Network segmentation — isolate cardholder data.
  • Audit and monitoring.
  • Vulnerability management.
  • Restricted access — least-privilege.

Salesforce approach:

  • Don't store full card data in Salesforce — use tokenisation via payment processor.
  • Reference tokens in custom fields.
  • Salesforce supports PCI DSS Level 1 but requires careful architecture.

General compliance architecture:

1. Data classification.

Every field labeled by regulation: PII, PHI, PCI, GLBA. Drives downstream decisions.

2. Access controls.

Restrict regulated data to compliance-approved roles only. Field-Level Security + sharing model.

3. Encryption.

Shield Platform Encryption for sensitive fields. Tenant-managed keys where required.

4. Audit.

  • Setup Audit Trail.
  • Field Audit Trail (Shield) for retention.
  • Event Monitoring (Shield) for runtime.
  • All retained for required durations.

5. Data lifecycle.

  • Retention policies aligned with regulation.
  • Deletion / anonymisation workflows.
  • Archival to Big Object or external for long-retention.

6. Workflow.

  • Right-to-be-forgotten requests routed and tracked.
  • Right-to-access requests fulfilled.
  • Breach notification process.

7. Documentation.

  • Compliance posture documented.
  • Auditable trail of design decisions.
  • Annual audits.

Architect role:

  • Design with compliance in mind from Discovery.
  • Engage compliance team early.
  • Choose Shield when sensitive data is involved.
  • Document architecture for auditors.

Common pitfalls:

  • Compliance as afterthought — bolting on later costly.
  • Over-classification — encrypt everything; performance cost.
  • No retention policy — violates regulations.
  • Unaudited access — can't prove compliance.

Senior architect insight: compliance is architecture, not a checklist. Designed-in compliance is sustainable; bolted-on compliance is fragile.

For regulated industries, expect compliance to drive 20-30% of architecture decisions. Budget for it.

Why this answer works

Senior. The regulation-specific guidance and "architecture not checklist" framing are mature.

Follow-ups to expect

Related dictionary terms