Trust - Regulatory Compliance & Audit Patterns
Learn more about Well-Architected Trust → Compliance and Regulatory Adherence
Patterns
| Where to look | What good looks like |
|---|---|
| Infrastructure compliance | ✅ Leverage Salesforce platform certifications (SOC 2 Type II, ISO 27001, FedRAMP for Government Cloud offerings, HIPAA, PCI DSS) available at trust.salesforce.com and compliance.salesforce.com for infrastructure and shared services compliance evidence. |
| Custom solution compliance | ✅ Design custom objects, Apex code, integrations, and configurations to maintain the compliance posture that platform certifications provide. |
| Custom solution compliance | ✅ Document architectural compliance controls. |
| Responsibility boundaries | ✅ Document clear delineation: Salesforce provides compliant infrastructure (physical, network, platform security, multi-tenant isolation); architects design compliant solutions (data classification, access controls, encryption configuration, secure coding, data processing compliance). |
| Compliance documentation | ✅ Maintain architecture documentation showing how custom implementations satisfy regulatory requirements, mapped to platform certifications. |
| Compliance documentation | ✅ Create compliance matrix linking regulations → platform controls → custom controls. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Infrastructure compliance | ⚠️ Assume platform certifications mean you have no compliance responsibilities. |
| Infrastructure compliance | ⚠️ Fail to implement appropriate access controls, encryption, or data processing compliance for custom solutions. |
| Infrastructure compliance | ⚠️ Platform certifications reduce compliance burden but do not eliminate architectural responsibility. |
| Responsibility boundaries | ⚠️ Have unclear understanding of where Salesforce responsibility ends and customer responsibility begins. |
| Responsibility boundaries | ⚠️ Blame platform for compliance gaps in custom implementations. |
| Compliance documentation | ⚠️ Have no documented mapping between regulatory requirements and implemented controls. |
| Compliance documentation | ⚠️ Scramble to gather evidence during audit discovery. |
Patterns
| Where to look | What good looks like |
|---|---|
| Healthcare (HIPAA) | ✅ Enable Shield Platform Encryption for all fields containing protected health information (PHI). |
| Healthcare (HIPAA) | ✅ Implement Field Audit Trail with retention meeting HIPAA's record-keeping requirement (confirm the current period against the governing regulation). |
| Healthcare (HIPAA) | ✅ PHI is stored and processed only on Salesforce services covered by the executed Business Associate Agreement (BAA); solution designs and PHI data flows are validated against the BAA's scope. |
| Healthcare (HIPAA) | ✅ Configure Event Monitoring to detect unauthorized PHI access patterns. |
| Healthcare (HIPAA) | ✅ Implement technical safeguards: access controls, audit logging, transmission security (TLS 1.2+, certificate-based mutual auth for PHI integrations). |
| Financial Services (SOX, DORA, PCI DSS) | ✅ Implement segregation of duties through permission set design preventing single users from both creating and approving financial transactions. |
| Financial Services (SOX, DORA, PCI DSS) | ✅ Maintain change audit trails via Setup Audit Trail and custom change logging. |
| Financial Services (SOX, DORA, PCI DSS) | ✅ Avoid storing full primary account numbers (PAN) in Salesforce—tokenize cardholder data through payment processors for PCI DSS scope reduction; where PAN must be stored, use Encrypted Custom Fields under PCI DSS controls. |
| Financial Services (SOX, DORA, PCI DSS) | ✅ Design transaction monitoring for fraud detection patterns. |
| Financial Services (SOX, DORA, PCI DSS) | ✅ DORA requires operational resilience including incident response and third-party risk management. |
| Privacy Regulations (GDPR, CCPA, LGPD) | ✅ For GDPR and LGPD, design consent management capturing granular, purpose-specific opt-in consent (marketing, analytics, personalization); for CCPA/CPRA, provide opt-out mechanisms for the sale or sharing of personal information. |
| Privacy Regulations (GDPR, CCPA, LGPD) | ✅ Build data subject rights workflows (access, rectification, erasure, portability) that complete within the response window the governing regulation sets for your deployment. |
| Privacy Regulations (GDPR, CCPA, LGPD) | ✅ Implement data retention automation that purges data when consent expires or legal basis ends. |
| Privacy Regulations (GDPR, CCPA, LGPD) | ✅ Document lawful basis for each data processing activity. |
| Privacy Regulations (GDPR, CCPA, LGPD) | ✅ GDPR requires documented justification, data flow mapping, privacy impact assessments. |
| Government (FedRAMP) | ✅ Use Salesforce Government Cloud for regulated government workloads. |
| Government (FedRAMP) | ✅ Implement NIST 800-53 controls mapped to Salesforce configuration. |
| Government (FedRAMP) | ✅ Enable continuous monitoring with Event Monitoring routed to government SIEM infrastructure. |
| Government (FedRAMP) | ✅ FedRAMP requires ongoing authorization through continuous monitoring, not just initial certification. |
| Multi-jurisdiction | ✅ Map data residency requirements to Hyperforce regional deployment. |
| Multi-jurisdiction | ✅ Implement standard contractual clauses or binding corporate rules for international data transfers. |
| Multi-jurisdiction | ✅ Document data flow maps showing origin, transit, and residence locations. |
| Multi-jurisdiction | ✅ Consider multi-org architecture when conflicting residency requirements cannot be met within single org. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Healthcare (HIPAA) | ⚠️ Store PHI in standard encrypted fields relying on policy to prevent unauthorized access. |
| Healthcare (HIPAA) | ⚠️ Have no Field Audit Trail or audit retention plan. |
| Healthcare (HIPAA) | ⚠️ Expose PHI in reports, list views, or Experience Cloud without appropriate access controls. |
| Healthcare (HIPAA) | ⚠️ Allow SMS-based MFA for PHI access (vulnerable to SIM swapping). |
| Financial Services (SOX, PCI DSS) | ⚠️ Allow single users to create and approve financial transactions (no segregation of duties). |
| Financial Services (SOX, PCI DSS) | ⚠️ Store full primary account numbers (PAN) in standard Salesforce custom fields without encryption or PCI DSS controls. |
| Financial Services (SOX, PCI DSS) | ⚠️ Have no transaction monitoring for fraud detection. |
| Financial Services (SOX, PCI DSS) | ⚠️ Have no documented change audit trail for financial system modifications. |
| Privacy Regulations (GDPR, CCPA) | ⚠️ Treat consent as binary yes/no rather than granular per-purpose tracking. |
| Privacy Regulations (GDPR, CCPA) | ⚠️ Handle data subject requests manually through legal team taking months, missing the response window the governing regulation sets for your deployment. |
| Privacy Regulations (GDPR, CCPA) | ⚠️ Have no documented lawful basis for data processing activities. |
| Privacy Regulations (GDPR, CCPA) | ⚠️ Collect data "just in case" without documented purpose limitation. |
| Government (FedRAMP) | ⚠️ Use standard Salesforce orgs for government workloads requiring FedRAMP compliance. |
| Government (FedRAMP) | ⚠️ Have no continuous monitoring or NIST 800-53 control mapping. |
| Multi-jurisdiction | ⚠️ Have no data flow mapping showing where data transits and resides. |
| Multi-jurisdiction | ⚠️ Assume single global org meets all regional data residency requirements. |
| Multi-jurisdiction | ⚠️ Have no legal basis documentation for international data transfers. |
Patterns
| Where to look | What good looks like |
|---|---|
| Security Health Check | ✅ Run quarterly assessments comparing org configuration against Salesforce security baselines. |
| Security Health Check | ✅ Maintain scores of 80% or higher (Very Good or Excellent band). |
| Security Health Check | ✅ Document exceptions with business justification and compensating controls for settings below baseline. |
| Security Health Check | ✅ Health Check identifies configuration drift from security best practices. |
| Event Monitoring | ✅ Enable Event Monitoring to capture detailed logs for user activity, API calls, authentication events, data access patterns. |
| Event Monitoring | ✅ Route Event Log Files to external SIEM for long-term retention exceeding native retention limits. |
| Event Monitoring | ✅ Compliance often requires multi-year log retention; confirm the minimum period against the governing regulation for your deployment. |
| Transaction Security | ✅ Implement Transaction Security policies that evaluate events in real time and can block, require MFA step-up, or notify on policy violations. |
| Transaction Security | ✅ Use for preventive controls that stop compliance violations before they occur (e.g., block bulk data export exceeding normal patterns, require step-up auth for sensitive field access). |
| Automated compliance validation | ✅ Implement compliance checks in CI/CD deployment pipelines validating that deployments do not weaken permission models, disable audit settings, or introduce non-compliant configurations. |
| Automated compliance validation | ✅ Break deployments that fail compliance validation—compliance validation should be a deployment gate, not post-deployment discovery. |
| Continuous audit readiness | ✅ Design for continuous audit readiness rather than point-in-time audit preparation. |
| Continuous audit readiness | ✅ Compliance is an ongoing operational state requiring continuous evidence generation, not annual certification scrambles. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Security Health Check | ⚠️ Run Health Check only when auditors request it. |
| Security Health Check | ⚠️ Allow scores to drift below 80% without investigation. |
| Security Health Check | ⚠️ Have no documented exceptions for settings below baseline. |
| Security Health Check | ⚠️ Never remediate identified risks. |
| Event Monitoring | ⚠️ Rely on native retention limits for compliance evidence when regulations require multi-year retention. |
| Event Monitoring | ⚠️ Have no external SIEM routing. |
| Event Monitoring | ⚠️ Allow native Event Monitoring retention to expire, losing audit evidence. |
| Transaction Security | ⚠️ Have no real-time preventive controls. |
| Transaction Security | ⚠️ Rely solely on post-incident investigation rather than blocking policy violations before they occur. |
| Automated compliance validation | ⚠️ Have no compliance checks in deployment pipelines. |
| Automated compliance validation | ⚠️ Discover compliance violations in production after deployment. |
| Automated compliance validation | ⚠️ Allow deployments that weaken security posture without review. |
| Continuous audit readiness | ⚠️ Treat compliance as annual event requiring months of audit preparation scrambling. |
| Continuous audit readiness | ⚠️ Have no continuous evidence generation. |
| Continuous audit readiness | ⚠️ Discover gaps during audit when it's too late to remediate. |
Patterns
| Where to look | What good looks like |
|---|---|
| Setup Audit Trail | ✅ Monitor administrative configuration changes with 180-day retention (included in all editions). |
| Setup Audit Trail | ✅ Review regularly for unauthorized changes. |
| Setup Audit Trail | ✅ Use for compliance evidence of configuration management controls. |
| Field Audit Trail | ✅ Enable for Restricted and Confidential fields requiring regulatory record-keeping. |
| Field Audit Trail | ✅ Configure retention to meet compliance requirements (supports indefinite retention); confirm the required period against the governing regulation for your deployment. |
| Field Audit Trail | ✅ Requires Shield. |
| Event Monitoring long-term retention | ✅ Route Event Monitoring logs to external SIEM for retention beyond native retention limits. |
| Event Monitoring long-term retention | ✅ Required for compliance evidence when regulations mandate multi-year log retention. |
| Event Monitoring long-term retention | ✅ Configure correlation with enterprise security telemetry for cross-system investigation. |
| Transaction Security | ✅ Implement real-time policy-based evaluation of user actions (no retention, triggers on events). |
| Transaction Security | ✅ Use for preventive controls requiring immediate response (e.g., block prohibited actions, require step-up authentication, trigger incident response workflows). |
| Transaction Security | ✅ Requires Shield license. |
| Custom application logging | ✅ Implement custom Apex logging for security-relevant application events not captured by platform audit trails: business logic authorization decisions, suspicious input patterns, rate limiting enforcement, custom authentication events. |
| Log integrity | ✅ Route audit logs to immutable external storage that attackers cannot modify even with administrative Salesforce access. |
| Log integrity | ✅ Forensic evidence must be tamper-evident to support investigation and potential legal proceedings. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Setup Audit Trail | ⚠️ Never review Setup Audit Trail for unauthorized administrative changes. |
| Setup Audit Trail | ⚠️ Discover malicious configuration changes months after occurrence when evidence has expired (180-day retention). |
| Field Audit Trail | ⚠️ Have no Field Audit Trail for Restricted data subject to regulatory record-keeping. |
| Field Audit Trail | ⚠️ Configure retention shorter than the period the governing regulation requires for your deployment. |
| Event Monitoring long-term retention | ⚠️ Rely solely on native Salesforce retention windows for compliance evidence. |
| Event Monitoring long-term retention | ⚠️ Discover gaps during audit preparation when logs have already expired. |
| Event Monitoring long-term retention | ⚠️ Have no correlation with enterprise security telemetry for cross-system investigation. |
| Transaction Security | ⚠️ Have no real-time policy evaluation for high-risk actions. |
| Transaction Security | ⚠️ Discover policy violations only through manual log review days or weeks after occurrence. |
| Custom application logging | ⚠️ Have no logging for custom business logic authorization decisions or security-relevant application events. |
| Custom application logging | ⚠️ Cannot investigate authorization failures or suspicious patterns because no evidence exists. |
| Log integrity | ⚠️ Store audit logs only in Salesforce where administrators can modify or delete them. |
| Log integrity | ⚠️ Have no immutable external copies for forensic preservation. |
| Log integrity | ⚠️ Lose chain of custody for legal proceedings. |
Patterns
| Where to look | What good looks like |
|---|---|
| Hyperforce regional deployment | ✅ Select appropriate Hyperforce regions during org provisioning to meet data residency compliance. |
| Hyperforce regional deployment | ✅ Hyperforce provides regional deployment options enabling data residency compliance for regulations requiring data to remain within specific geographic boundaries. |
| Data flow mapping | ✅ Document data flow maps showing where data originates, transits through (integration middleware, external services), and resides (storage regions). |
| Data flow mapping | ✅ Required for GDPR Article 30 records of processing activities. |
| International transfers | ✅ Implement standard contractual clauses or binding corporate rules for international data transfers where required by GDPR and similar regulations. |
| International transfers | ✅ Document legal basis for each cross-border transfer. |
| Multi-org for conflicting requirements | ✅ Consider multi-org architecture when operating across multiple jurisdictions with conflicting residency requirements that cannot be met within single org with Hyperforce regional deployment. |
| Multi-org for conflicting requirements | ✅ Trade-off: multi-org provides strongest data isolation but multiplies operational complexity, licensing costs, integration requirements. |
| Multi-org governance | ✅ For multi-org architectures, maintain consistent security baselines across orgs through shared configuration-as-code repositories, cross-org monitoring, unified identity management. |
| Multi-org governance | ✅ Multi-org provides strongest isolation but multiplies governance surface area. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Hyperforce regional deployment | ⚠️ Select default US region for global org without evaluating data residency requirements. |
| Hyperforce regional deployment | ⚠️ Violate GDPR, LGPD, or regional data sovereignty laws through inappropriate region selection. |
| Data flow mapping | ⚠️ Have no documented data flow maps. |
| Data flow mapping | ⚠️ Cannot answer auditor questions about where data transits or resides. |
| Data flow mapping | ⚠️ Have no GDPR Article 30 records of processing activities. |
| International transfers | ⚠️ Transfer data internationally without standard contractual clauses, binding corporate rules, or documented legal basis. |
| International transfers | ⚠️ Violate GDPR transfer restrictions. |
| Multi-org for conflicting requirements | ⚠️ Force conflicting data residency requirements into single org causing compliance violations. |
| Multi-org for conflicting requirements | ⚠️ Alternatively, implement multi-org architecture when single org with Hyperforce regional deployment would meet requirements (unnecessary complexity). |
| Multi-org governance | ⚠️ Have inconsistent security baselines across multi-org environment. |
| Multi-org governance | ⚠️ Each org implements security differently. |
| Multi-org governance | ⚠️ Cannot demonstrate consistent compliance posture across organization. |
Patterns
| Where to look | What good looks like |
|---|---|
| Security Health Check quarterly | ✅ Run Health Check quarterly comparing org configuration against Salesforce security baselines (password policies, session settings, network access, feature configurations). |
| Security Health Check quarterly | ✅ Target scores of 80% or higher (Very Good or Excellent band). |
| Security Health Check quarterly | ✅ Document exceptions with business justification and compensating controls for settings maintained below baseline. |
| Event Monitoring analytics | ✅ Design dashboards revealing behavioral patterns requiring investigation: unusual data access volumes, off-hours administrative activity, API consumption anomalies. |
| Event Monitoring analytics | ✅ Behavioral analytics detect threats that signature-based detection misses. |
| Automated drift detection | ✅ Implement automated compliance testing in pipelines detecting configuration drift from approved baselines. |
| Automated drift detection | ✅ Alert when configurations diverge from security standards. |
| Continuous posture monitoring | ✅ Security posture degrades without active management as configurations drift, permissions accumulate, new vulnerabilities emerge. |
| Continuous posture monitoring | ✅ Design for continuous monitoring, not point-in-time assessment. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Security Health Check quarterly | ⚠️ Run Health Check only when auditors request it. |
| Security Health Check quarterly | ⚠️ Allow scores to drift below 80% without remediation. |
| Security Health Check quarterly | ⚠️ Have no tracking of posture trends over time. |
| Event Monitoring analytics | ⚠️ Have Event Monitoring enabled but no dashboards, no alerting, no investigation of anomalies. |
| Event Monitoring analytics | ⚠️ Treat audit logs as compliance checkbox rather than security telemetry. |
| Automated drift detection | ⚠️ Have no automated detection of configuration drift from approved baselines. |
| Automated drift detection | ⚠️ Discover configuration weakening only during manual audits months after change. |
| Continuous posture monitoring | ⚠️ Treat security as point-in-time certification rather than continuous operational state. |
| Continuous posture monitoring | ⚠️ Scramble to prepare for annual audits because continuous monitoring doesn't exist. |
Patterns
| Where to look | What good looks like |
|---|---|
| Security review timing | ✅ Integrate security review into Architecture Review Board (ARB) at proposal phase, before significant build investment. |
| Security review timing | ✅ Security review at the end of development is too late to influence fundamental design decisions. |
| Architecture Decision Records | ✅ Document security architecture decisions in ADRs capturing security requirements, alternatives evaluated, trade-offs accepted, residual risks, compensating controls, monitoring approach. |
| Architecture Decision Records | ✅ ADRs provide audit evidence, enable knowledge transfer, support architectural evolution by documenting why decisions were made. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Security review timing | ⚠️ Conduct security review only after development is complete. |
| Security review timing | ⚠️ Discover fundamental security flaws requiring rearchitecture when build is substantially complete. |
| Security review timing | ⚠️ Security becomes expensive afterthought. |
| Architecture Decision Records | ⚠️ Have no documentation of security architecture decisions. |
| Architecture Decision Records | ⚠️ Cannot explain why certain controls were chosen, what alternatives were evaluated, what residual risks were accepted. |
| Architecture Decision Records | ⚠️ Lack audit evidence and knowledge transfer. |
Patterns
| Where to look | What good looks like |
|---|---|
| Pre-adoption security assessment | ✅ Review AppExchange Security Review status (scope, last review date—security reviews expire), assess permission requirements (does package need more access than function justifies?), evaluate data handling practices (where does data flow, what is retained externally, data sent to third-party services?), review vendor incident response capabilities and notification procedures, understand exit procedures and data portability. |
| AppExchange permission scrutiny | ✅ Packages requesting Modify All Data, View All Data, or sensitive permissions require extra scrutiny. |
| AppExchange permission scrutiny | ✅ Document business justification for elevated permissions. |
| AppExchange permission scrutiny | ✅ Evaluate whether package functionality genuinely requires scope granted. |
| Third-party inventory | ✅ Maintain inventory of third-party dependencies (AppExchange packages, integrated services, middleware) with risk ratings, documented risk acceptance decisions, periodic review cadence. |
| Security advisory monitoring | ✅ Subscribe to security advisories for installed packages and integrated services. |
| Security advisory monitoring | ✅ Monitor for new vulnerabilities, version updates requiring patching, vendor security incidents affecting your environment. |
| Ongoing monitoring | ✅ Monitor package behavior through Event Monitoring for unexpected data access patterns or API call anomalies post-installation. |
| Ongoing monitoring | ✅ Packages run with elevated privileges and require ongoing security monitoring. |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Pre-adoption security assessment | ⚠️ Install AppExchange packages based solely on functionality without evaluating permission scope, data access patterns, vendor security practices, exit procedures. |
| Pre-adoption security assessment | ⚠️ Accept packages with excessive permissions without scrutiny. |
| AppExchange permission scrutiny | ⚠️ Grant packages requesting Modify All Data or View All Data without questioning whether functionality genuinely requires that scope. |
| AppExchange permission scrutiny | ⚠️ Have no documented business justification for elevated permissions. |
| Third-party inventory | ⚠️ Have no inventory of third-party dependencies. |
| Third-party inventory | ⚠️ Cannot answer auditor questions about third-party data access. |
| Third-party inventory | ⚠️ Have no risk ratings or review schedule for installed packages. |
| Security advisory monitoring | ⚠️ Never monitor for security advisories affecting installed packages or integrated services. |
| Security advisory monitoring | ⚠️ Remain vulnerable to known exploits months or years after disclosure. |
| Ongoing monitoring | ⚠️ Install packages and never monitor their behavior. |
| Ongoing monitoring | ⚠️ Cannot detect if package is compromised or begins accessing data beyond original scope. |
| Ongoing monitoring | ⚠️ Have no Event Monitoring for package API activity. |