Shared Responsibility Model - Patterns
Learn more about Well-Architected Trust → The Shared Responsibility Model
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Security | ✅ Architecture designs assume physical data center security, surveillance, and environmental safeguards are handled by Salesforce (or AWS for Hyperforce) |
| Platform | Security | ✅ Network security designs leverage platform-provided DDoS mitigation and intrusion detection systems without duplicate investment |
| Platform | Security | ✅ All traffic encryption in transit (TLS 1.2+) and at rest (AES-256) is provided by platform infrastructure |
| Platform | Security | ✅ Platform hardening, vulnerability management, and patch deployment are Salesforce responsibilities; architects plan around scheduled maintenance windows |
| Platform | Security | ✅ Multi-tenant security and tenant isolation architecture ensuring data separation are platform-provided guarantees |
| Platform | Compliance | ✅ Platform compliance certifications (SOC 1/2/3, ISO 27001/27017/27018, FedRAMP for Government Cloud offerings, HIPAA, PCI DSS, GDPR) are available at trust.salesforce.com and compliance.salesforce.com |
| Platform | Security | ✅ Platform encryption services and backup infrastructure are platform-managed capabilities architects leverage without implementation responsibility |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Security | ⚠️ Architecture designs include custom physical security controls, network perimeter defenses, or OS-level hardening duplicating platform-provided capabilities |
| Platform | Security | ⚠️ Security reviews question platform encryption at rest or network security without consulting trust.salesforce.com documentation of existing controls |
| Platform | Compliance | ⚠️ Compliance assessments re-audit platform infrastructure security controls instead of leveraging existing SOC 2/ISO certifications |
| Platform | Security | ⚠️ Architecture assumes responsibility for patching platform infrastructure or managing multi-tenant isolation |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Identity | ✅ Identity and access management (roles, profiles, permission sets, MFA, SSO, least privilege) are designed and configured by architects |
| Platform | Identity | ✅ User lifecycle management and access recertification processes are implemented with documented quarterly reviews |
| Platform | Data | ✅ Data governance including classification, masking, object/field/record-level security, CRUD permissions, and sharing rules are architect responsibilities |
| Platform | Integration | ✅ Integration security (OAuth 2.0, JWT authentication, named credentials, secure endpoints, external system validation) is designed and maintained by architects |
| Platform | Security | ✅ Monitoring and response capabilities (Event Monitoring, audit trails, SIEM integration, incident response procedures) are implemented by architects |
| Platform | Development | ✅ Application security including secure custom code (Apex, Lightning), input validation, injection prevention, and secure development practices are architect and developer responsibilities |
| Platform | Compliance | ✅ Solutions maintain compliance posture through privacy/consent management, data retention policies, and compliance configuration aligned to regulatory requirements |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Identity | ⚠️ Identity and access management is treated as “platform security” without designing roles, profiles, permission sets, or MFA requirements |
| Platform | Data | ⚠️ Data governance is assumed to be platform-provided; no data classification, sharing rules, or field-level security is configured |
| Platform | Integration | ⚠️ Integration security relies on network-level controls without implementing OAuth, credential management, or endpoint validation |
| Platform | Security | ⚠️ Monitoring and incident response are treated as Salesforce responsibilities; no Event Monitoring, SIEM integration, or response procedures exist |
| Platform | Development | ⚠️ Custom code security is not validated; injection vulnerabilities, missing CRUD/FLS enforcement, and insecure patterns accumulate |
| Platform | Compliance | ⚠️ Compliance configuration is never implemented; solutions violate regulatory requirements despite platform certifications |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Compliance | ✅ Platform certifications (SOC 2 Type II, ISO 27001, FedRAMP for Government Cloud offerings, HIPAA, PCI DSS, GDPR) are referenced in compliance documentation as covering infrastructure responsibilities |
| Platform | Compliance | ✅ Audit preparation leverages trust.salesforce.com and compliance.salesforce.com documentation for platform infrastructure controls |
| Platform | Compliance | ✅ Compliance documentation clearly delineates platform-provided certifications vs. architect-implemented controls for custom solutions |
| Platform | Architecture | ✅ Custom objects, Apex code, integrations, and configurations are designed to maintain the compliance posture the platform provides |
| Platform | Compliance | ✅ Architecture documentation explicitly maps how custom solutions satisfy regulatory requirements while leveraging platform certifications |
| Platform | Compliance | ✅ Regional certifications and compliance requirements drive Hyperforce region selection during org provisioning |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Compliance | ⚠️ Platform certifications are assumed to cover all compliance obligations; no custom solution controls are implemented |
| Platform | Compliance | ⚠️ Audit preparation attempts to re-audit platform infrastructure controls instead of referencing existing certifications |
| Platform | Architecture | ⚠️ Custom code, configurations, and integrations violate compliance requirements despite platform having appropriate certifications |
| Platform | Compliance | ⚠️ Compliance documentation does not clearly separate platform certifications from architect-implemented controls |
| Platform | Compliance | ⚠️ Architecture lacks documented mapping of how custom solutions maintain compliance posture while leveraging platform certifications |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Security | ✅ Incident response procedures document collaboration: Salesforce provides platform detection and response; architects provide solution-level detection and response |
| Platform | Security | ✅ Vulnerability management responsibilities are clearly documented: Salesforce patches platform; architects patch custom code and installed packages |
| Platform | Security | ✅ Security monitoring combines platform-generated events (Event Monitoring) with architect-configured analysis, alerting, and response workflows |
| Platform | Architecture | ✅ Every design principle, topic section, and checklist item in Trust pillar is treated as architect responsibility within the Shared Responsibility Model |
| Platform | Security | ✅ Design decisions explicitly reference Shared Responsibility Model boundaries, distinguishing platform-provided controls from architect-configured controls |
| Platform | Architecture | ✅ Architecture Decision Records document responsibility boundaries for security controls, compliance requirements, and incident response |
| Platform | Security | ✅ Security reviews validate that architect responsibilities (configuration, access controls, custom code) are implemented appropriately on platform-provided foundation |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Security | ⚠️ Incident response procedures assume Salesforce handles all aspects; no solution-level detection, response, or recovery capabilities exist |
| Platform | Security | ⚠️ Vulnerability management does not address custom code; only platform patches are considered |
| Platform | Security | ⚠️ Security monitoring relies entirely on platform-native tools without architect-configured analysis or response workflows |
| Platform | Architecture | ⚠️ Design decisions do not reference Shared Responsibility Model; confusion exists about who secures what |
| Platform | Architecture | ⚠️ Architecture Decision Records omit responsibility boundaries; security assumptions are implicit rather than explicit |
| Platform | Security | ⚠️ Security reviews assume platform certifications eliminate architect security responsibilities |
Patterns
| Where to look | What good looks like |
|---|---|
| Healthcare | HIPAA | ✅ Shield Platform Encryption is enabled for all fields containing protected health information (PHI) |
| Healthcare | HIPAA | ✅ Field Audit Trail is configured with retention meeting HIPAA’s record-keeping requirement for PHI access tracking (confirm the current period against the governing regulation) |
| Healthcare | HIPAA | ✅ Event Monitoring is configured to detect unauthorized PHI access patterns with alerts routed to security teams |
| Healthcare | HIPAA | ✅ Technical safeguards required by HIPAA Security Rule (access controls, audit logging, transmission security) are implemented through architect configuration |
| Financial | SOX/PCI | ✅ Segregation of duties is implemented through permission set design preventing single users from creating and approving financial transactions |
| Financial | PCI DSS | ✅ Complete primary account numbers (PAN) are kept out of Salesforce where possible and tokenized through payment processors for scope reduction; where PAN must be stored, it uses Encrypted Custom Fields under PCI DSS controls |
| Privacy | GDPR/CCPA | ✅ Consent management is implemented with granular per-purpose consent tracking and withdrawal workflows |
| Privacy | GDPR/CCPA | ✅ Data subject rights workflows (access, rectification, erasure, portability) complete within the response window the governing regulation sets for your deployment |
| Privacy | GDPR/CCPA | ✅ Data retention automation purges data when consent expires or retention periods end |
| Government | FedRAMP | ✅ Salesforce Government Cloud is used for regulated government workloads requiring FedRAMP compliance |
| Government | FedRAMP | ✅ NIST 800-53 controls are mapped to Salesforce configuration with documented implementation for each applicable control |
| Government | FedRAMP | ✅ Continuous monitoring with Event Monitoring is routed to government SIEM infrastructure for real-time threat detection |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Healthcare | HIPAA | ⚠️ PHI is stored in standard encrypted fields without Shield Platform Encryption or Field Audit Trail |
| Healthcare | HIPAA | ⚠️ Event Monitoring is not configured to detect unauthorized PHI access; violations occur undetected |
| Financial | SOX/PCI | ⚠️ Single users can both create and approve financial transactions; segregation of duties is not enforced |
| Financial | PCI DSS | ⚠️ Complete primary account numbers (PAN) are stored in standard Salesforce fields without encryption instead of using payment processor tokenization or PCI DSS-compliant encrypted storage |
| Privacy | GDPR/CCPA | ⚠️ Consent management is not implemented; data is processed without granular consent or withdrawal capabilities |
| Privacy | GDPR/CCPA | ⚠️ Data subject rights requests are handled manually through the legal team instead of automation sized to the regulation’s response window |
| Privacy | GDPR/CCPA | ⚠️ Data retention is manual; data accumulates indefinitely despite expired consent or retention period completion |
| Government | FedRAMP | ⚠️ Regulated government workloads run on commercial Salesforce instances instead of Government Cloud |
| Government | FedRAMP | ⚠️ NIST 800-53 controls lack documented mapping to Salesforce configuration; compliance gaps exist |
| Government | FedRAMP | ⚠️ Event Monitoring is not routed to government SIEM; continuous monitoring requirements are not met |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Security | ✅ Users with critical system permissions (View All Data, Modify All Data, Manage Users) are inventoried and tracked as elevated-privilege assets |
| Platform | Shield Event Monitoring | ✅ Event Monitoring captures event logs covering logins, report and data exports, permission changes, and API calls for security analysis |
| Platform | Shield Event Monitoring | ✅ Event Monitoring logs are routed to an external SIEM platform for correlation with non-Salesforce security events |
| Integration | SIEM | ✅ SIEM correlation rules detect privilege escalation, such as permission changes outside approved change windows and API volume anomalies above baseline |
| Integration | SIEM | ✅ SIEM dashboards provide visibility into security asset changes such as privileged-user grants and data exports |
| Platform | Documentation | ✅ Security asset inventory is documented with asset categories (users, data, integrations, packages, configurations), owners, and review cadence |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Security | ⚠️ Security asset inventory is maintained manually in spreadsheets that become outdated immediately after creation |
| Platform | Security | ⚠️ Security assets are tracked through tribal knowledge without documented, queryable inventory accessible during incidents |
| Platform | Security | ⚠️ Security audits occur only during annual compliance reviews with no continuous monitoring between audits |
| Platform | Security | ⚠️ Security asset inventory is collected but never reviewed; dormant accounts, orphaned integrations, and excessive permissions persist indefinitely |
| Platform | Security | ⚠️ Official integration users are tracked but business units create ad-hoc Connected Apps bypassing security review and credential rotation policies |
| Platform | Shield Event Monitoring | ⚠️ Event Monitoring is enabled but events are not routed to SIEM; security events remain siloed in Salesforce without correlation |
| Platform | Integration | ⚠️ Shadow IT integrations bypass inventory tracking; unauthorized API activity creates data exfiltration risks |