# Shared Responsibility Model - Patterns | Patterns Source: https://architect.salesforce.com/docs/architect/well-architected/guide/trust-shared-responsibility-patterns.html > Proven patterns for understanding and implementing security responsibilities aligned to the Well-Architected Trust pillar. # Shared Responsibility Model - Patterns Learn more about Well-Architected [Trust](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html) → [The Shared Responsibility Model](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html#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