Data Protection Patterns
Learn more about Well-Architected Trust → Data Protection and Privacy
Patterns
| Where to look | What good looks like |
|---|---|
| Data classification scheme | ✅ Classification scheme documented with levels (Public, Internal, Confidential, Restricted) ✅ Business examples provided for each classification level ✅ Classification scheme aligned to regulatory obligations (HIPAA, PCI DSS, GDPR) ✅ Data modelers trained to apply classification consistently during design ✅ New fields classified as part of data modeling process, not retroactively |
| Field-level classification | ✅ Classification applied at field level, not just object level ✅ Fields within a single object may have different classifications ✅ Field-level security reflects classification distinctions ✅ Unclassified data defaults to highest appropriate protection level ✅ Classification drives protection controls (encryption, access, retention) |
| Custom objects and fields | ✅ All custom objects have documented data classification ✅ Sensitive fields (salary, SSN, PHI, payment data) classified as Confidential or Restricted ✅ Public fields (company name, website) documented as Public ✅ Classification metadata captured in field descriptions ✅ Classification reviewed during code reviews and ARB |
| Standard objects | ✅ Standard object fields evaluated against classification scheme ✅ Shield Platform Encryption enabled for Restricted standard fields ✅ Field-level security applied to Confidential standard fields ✅ Reports and list views filtered to prevent exposure of sensitive standard fields |
| Integration data | ✅ Data flowing through integrations classified before implementation ✅ External system data sensitivity evaluated and documented ✅ Integration endpoints handling Restricted data use certificate-based auth ✅ Data classification preserved across system boundaries |
| Compliance mapping | ✅ HIPAA PHI fields identified and marked Restricted ✅ PCI cardholder data avoided in Salesforce where possible—tokenized via payment gateway for scope reduction; where it must be stored, use Encrypted Custom Fields under PCI DSS controls ✅ GDPR personal data identified and subject to privacy controls ✅ SOX financial data classified and subject to segregation of duties |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Uniform protection | ⚠️ Same protection applied to all fields regardless of sensitivity ⚠️ Low-value data overprotected (wasting resources) while high-value data is underprotected ⚠️ Public company information treated the same as PHI or payment card data ⚠️ Every field encrypted “just to be safe” without classification justification |
| Retroactive classification | ⚠️ Data classified after deployment to production ⚠️ Sensitive data discovered through compliance audits rather than design reviews ⚠️ Data classified only after security incidents ⚠️ “We’ll figure out classification later” is the default during development |
| Object-level only classification | ⚠️ Entire objects classified uniformly when fields have different sensitivity ⚠️ Object-level access granted without field-level security for sensitive fields ⚠️ All fields on Account or Contact objects assumed to have the same classification ⚠️ Object permissions used as the only access control for mixed-sensitivity objects |
| Tribal knowledge | ⚠️ Classification undocumented, existing only in key people’s knowledge ⚠️ Developers relied on to “just know” which fields are sensitive ⚠️ No written classification scheme accessible to all data modelers ⚠️ New team members onboarded without classification training |
Patterns
| Where to look | What good looks like |
|---|---|
| Encryption at rest | ✅ All data encrypted at infrastructure level through Hyperforce ✅ Shield Platform Encryption enabled for Restricted data ✅ Encryption scheme (probabilistic, deterministic, case-sensitive deterministic) selected based on query and uniqueness requirements ✅ Encryption trade-offs evaluated during data model design |
| Shield Platform Encryption strategy | ✅ Probabilistic encryption used for most Restricted fields (supports all query operations) ✅ Deterministic encryption used for fields requiring exact-match WHERE clauses or uniqueness ✅ Case-sensitive deterministic used where case distinction matters for business logic ✅ Encrypted field behavior tested before production deployment ✅ Formula field references to encrypted fields handled appropriately (moved to Apex if needed) |
| Key management | ✅ Key rotation procedures documented and automated ✅ Key destruction scenarios tested during disaster recovery exercises ✅ Customer-managed keys (BYOK) evaluated for compliance requiring explicit key control ✅ Key revocation procedures documented ✅ Encryption key lifecycle managed according to compliance requirements |
| Encryption in transit | ✅ TLS 1.2 or higher required for all integrations ✅ Certificate-based mutual authentication for integrations handling Restricted data ✅ HSTS headers configured for Experience Cloud sites to prevent protocol downgrade ✅ TLS certificate expiration monitored and automated renewal configured ✅ Weak ciphers and protocols disabled |
| Code and configuration | ✅ Credentials never embedded in code, configuration files, or version control ✅ Named credentials and external credentials used to manage authentication centrally ✅ Credential rotation capabilities built into architecture ✅ Named credentials abstract authentication from code, enabling updates without code changes |
| AppExchange packages | ✅ Package security requirements evaluated before installation ✅ Encrypted fields accessible to packages only when business-justified ✅ Package data access patterns monitored through Event Monitoring ✅ Packages requiring access to Restricted data subject to enhanced review |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Encryption without evaluation | ⚠️ Probabilistic encryption enabled on all fields without testing ⚠️ Critical reports found in production to fail because encrypted fields cannot be aggregated ⚠️ Encryption enabled on formula field sources without understanding impact ⚠️ Fields used in SOQL LIKE queries encrypted without switching to deterministic encryption |
| Embedded credentials | ⚠️ Credentials embedded in code, custom settings, or version control ⚠️ API keys, passwords, and certificates hardcoded in Apex classes ⚠️ Credentials committed to source control repositories ⚠️ Credentials stored in custom metadata or custom settings without encryption |
| Weak or legacy protocols | ⚠️ TLS 1.0 or 1.1 accepted (deprecated and vulnerable) ⚠️ Username-password OAuth flow allowed when JWT bearer is available ⚠️ Self-signed certificates accepted in production integrations ⚠️ Certificate validation disabled “to make integration work” |
| No key management | ⚠️ Shield Platform Encryption enabled without key rotation procedures ⚠️ No documented key destruction scenarios ⚠️ Default keys used without evaluating customer-managed keys for compliance ⚠️ Key rotation and revocation procedures never tested |
| Over-encryption | ⚠️ Public or Internal classification data encrypted, adding cost without benefit ⚠️ Shield Platform Encryption enabled on every field, creating unnecessary complexity ⚠️ BYOK used when compliance doesn’t require it (adds operational overhead) ⚠️ Encryption mandated where data classification doesn’t justify it |
Patterns
| Where to look | What good looks like |
|---|---|
| Sandbox strategy | ✅ Restricted data never enters development or testing environments ✅ Partial sandbox copying excludes Restricted objects and fields ✅ Sandbox templates define which objects and fields to include by environment type ✅ Data Mask configured for sandboxes that require production-like data |
| Data Mask rules | ✅ Data Mask rules obfuscate sensitive fields while preserving data characteristics ✅ Patterns maintain referential integrity (same input produces same masked output) ✅ Email addresses masked but remain valid format for testing ✅ Phone numbers masked but remain valid format ✅ Dates shifted consistently maintaining relative relationships ✅ Numeric fields randomized within realistic ranges |
| Synthetic data | ✅ Development environments use synthetic data generation ✅ Synthetic data has realistic characteristics enabling effective testing ✅ No production data ever required for development ✅ Test data generation automated in development pipelines |
| Non-production environments | ✅ Production data never copied to personal developer orgs ✅ Screen captures and demos use masked or synthetic data ✅ Training environments use synthetic data or heavily masked production data ✅ Contractor and vendor access to non-production data restricted to Business Use Only classification |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Production data in sandboxes | ⚠️ Full sandboxes refreshed with unmasked production data for development ⚠️ Restricted data copied to developer sandboxes for convenience ⚠️ Developers granted broad access to production-data sandboxes ⚠️ Sandboxes refreshed with sensitive data “because testing is easier with real data” |
| No synthetic data | ⚠️ Production data relied on solely for all testing ⚠️ No synthetic data generation for development environments ⚠️ “We need real data” assumed without evaluating synthetic alternatives ⚠️ Manual test data created when generation can be automated |
Patterns
| Where to look | What good looks like |
|---|---|
| Data minimization | ✅ Only data necessary for stated business purposes collected ✅ Every field addition challenged with “what architectural decision requires this data?” ✅ Data no longer serving collection purpose removed ✅ Optional fields clearly marked and not required without business justification ✅ Historical data retention aligned to legal basis, not “keep everything forever” |
| Purpose limitation | ✅ Permission sets restrict data access based on job function purpose ✅ Marketing users cannot access support case details without documented justification ✅ Sales users cannot access customer service histories unless job requires it ✅ Cross-functional data access requires explicit approval and monitoring ✅ Data access purpose documented in permission set descriptions |
| Consent management | ✅ Consent captured at individual level for marketing, analytics, optional processing ✅ Consent is granular (purpose-specific), not binary blanket consent ✅ Consent withdrawal workflows propagate across integrated systems ✅ Consent decisions tracked with timestamp, version, and mechanism ✅ Consent UI clearly explains what user is consenting to |
| Data subject rights | ✅ Access request workflows provide data copies within the deadline the governing regulation sets for your deployment ✅ Rectification workflows correct inaccuracies with audit trail ✅ Erasure workflows delete data where legally permissible (considering retention obligations) ✅ Portability workflows export data in machine-readable format ✅ Data subject rights workflows tested regularly to validate timelines ✅ Workflow automation ensures regulatory timelines met consistently |
| Privacy controls | ✅ Privacy controls enforced technically, not just through policy ✅ Sharing rules implement purpose limitation ✅ Field-level security protects sensitive attributes ✅ Audit trails capture privacy-relevant events ✅ Privacy controls validated in CI/CD pipelines |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Collect everything | ⚠️ “Collect all possible data, we might need it someday” approach ⚠️ Fields added without documented business purpose ⚠️ Data kept indefinitely without retention justification ⚠️ Optional data collected by making fields required |
| Blanket consent | ⚠️ Single “agree to terms” consent for all purposes ⚠️ Marketing consent combined with service delivery in a single checkbox ⚠️ Consent made all-or-nothing when purposes are separable ⚠️ Consent buried in 20-page terms and conditions |
| Policy without enforcement | ⚠️ Privacy policy describes ideal practices that are not technically enforced ⚠️ User training relied on to prevent inappropriate data access ⚠️ Privacy principles documented without implementing technical controls ⚠️ Policy compliance assumed without monitoring and validation |
| Manual data subject requests | ⚠️ GDPR/CCPA requests handled through manual IT tickets taking months ⚠️ No documented procedures for access, rectification, erasure, portability ⚠️ The request-completion window the governing regulation sets for your deployment is missed ⚠️ Request workflows found during audits to not exist |
| Excessive data sharing | ⚠️ Broad data access granted across departments without purpose justification ⚠️ Marketing allowed access to support case details ⚠️ Sales allowed access to customer service histories without documented need ⚠️ Public Read/Write OWD used for objects containing personal data |
Patterns
| Where to look | What good looks like |
|---|---|
| Hyperforce regional deployment | ✅ Org provisioned in Hyperforce region meeting data residency requirements ✅ Data storage and processing occur within required geographic boundaries ✅ Regional requirements documented and validated before provisioning ✅ Multi-region requirements addressed through multi-org architecture where necessary |
| Data flow mapping | ✅ Data flow maps document where data originates, transits, and resides ✅ Cross-border data transfers identified and evaluated against regulations ✅ Standard contractual clauses or binding corporate rules for international transfers ✅ Data transit paths evaluated for residency compliance, not just storage location |
| Data residency scope | ✅ Data storage location (which Hyperforce region) ✅ Data processing location (compute regions) ✅ Backup storage location ✅ Log and audit trail storage location ✅ Integration transit paths evaluated for cross-border data movement |
| Multi-org architecture | ✅ Multi-org architecture used when regulatory requirements cannot be met within single org ✅ Each org provisioned in appropriate region for its data ✅ Integration patterns respect data residency constraints ✅ Operational complexity trade-offs documented in ADRs |
| Compliance validation | ✅ Data residency requirements documented by jurisdiction ✅ Hyperforce region selection validated against requirements before provisioning ✅ Periodic audits confirm data remains within required boundaries ✅ Changes to residency regulations trigger architecture review |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Residency oversight | ⚠️ Data residency violations discovered during compliance audits ⚠️ Orgs provisioned without evaluating regional requirements ⚠️ “Cloud is cloud” assumed without considering data location regulations ⚠️ Jurisdictions added without reviewing residency obligations |
| Transit ignoring residency | ⚠️ Only storage location considered while transit paths are ignored ⚠️ Data routed through regions outside compliance boundaries ⚠️ Integration middleware used in non-compliant regions ⚠️ Backups stored in different regions than primary data |
| Unnecessary multi-org | ⚠️ Multi-org architecture used when a single org with Hyperforce regions is sufficient ⚠️ Operational complexity, licensing costs, and integration overhead multiplied without regulatory necessity ⚠️ Multi-org implemented “just to be safe” without a specific compliance requirement ⚠️ Multi-org used by default when data classification and access controls are sufficient |