---
schema_version: "1"
id: 2e7c7e00ae16703f8e9798ca01363c51c08027f6fccd657d741fcb4254466ecc
title: Data Protection Patterns
collection: architect
version: next
locale: en-us
portal_url: https://docs.salesforce.com/architect/next/en-us/well-architected/guides/trust-data-protection-patterns.md
canonical_url: https://staging.architect.salesforce.com/docs/architect/well-architected/guide/trust-data-protection-patterns.html
source_site: staging.architect.salesforce.com
content_type: documentation
content_hash: 55ec6638036322feb9e03eeb0619915373a7239b6e43fc08ffddeb532e9150a5
products:
- Well-Architected Framework
- Architect Site Content Repo
---
# Data Protection Patterns
Learn more about Well-Architected [Trust](/docs/architect/well-architected/guide/trust.html) → [Data Protection and Privacy](/docs/architect/well-architected/guide/trust.html#data-protection-and-privacy)
## Data Classification
**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 |
## Encryption
**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 |
## Data Masking
**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 |
## Privacy by Design
**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 |
## Data Residency
**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 |