# Data Protection Patterns | Patterns Source: https://architect.salesforce.com/docs/architect/well-architected/guide/trust-data-protection-patterns.html > Patterns and anti-patterns for data classification, encryption, masking, privacy by design, and data residency in Salesforce solutions. # Data Protection Patterns Learn more about Well-Architected [Trust](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html) → [Data Protection and Privacy](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html#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