---
schema_version: "1"
id: 34aba7f05489e98b2917f0cefea8a73b7cf589f3a73b9a124fb32c34419237cd
title: Shared Responsibility Model - Patterns
collection: architect
version: current
locale: en-us
portal_url: https://docs.salesforce.com/architect/current/en-us/well-architected/guides/trust-shared-responsibility-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/well-architected/guide/trust-shared-responsibility-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 5785595aabaeaec90b04f9e7fdd1f1d2d96c9e92cad6e77c2a078a3bff3bce5a
products:
  - Well-Architected Framework
  - Architect Site Content Repo
---
# Shared Responsibility Model - Patterns

Learn more about Well-Architected [Trust](/docs/architect/well-architected/guide/trust.html) → [The Shared Responsibility Model](/docs/architect/well-architected/guide/trust.html#the-shared-responsibility-model)

## Understanding Platform Responsibilities

**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 |

## Understanding Customer Responsibilities

**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 |

## Leveraging 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 |

## Responsibility Boundary Understanding

**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 |

## Industry-Specific Compliance Responsibility

**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 |

## Security Asset Inventory

**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 |