---
schema_version: "1"
id: c21c892074016eb17aabd5941f2d9be72c2d21afa94fa33d227f34a79217d483
title: Trust — Patterns
collection: architect
version: current
locale: en-us
portal_url: https://docs.salesforce.com/architect/current/en-us/well-architected/guides/trust-overview.md
canonical_url: https://architect.salesforce.com/docs/architect/well-architected/guide/trust-overview.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 8c4d36c2d874e48e5d9446ec98bc9762291399995bdd64e803aa588f6b801182
products:
  - Well-Architected Framework
  - Architect Site Content Repo
---
# Trust — Patterns

The Trust pillar focuses on security, compliance, data protection, identity and access management, incident response, and shared responsibility between you and Salesforce. These patterns turn the pillar's design principles into concrete, reviewable practices: what to look for in a solution, what good looks like, and the anti-patterns that undermine it.

## Design Principles

These patterns put the Trust pillar's design principles into practice. Read them alongside the [Trust pillar](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.md) for the full guidance behind each one.

- **Apply zero trust across all layers** — verify every access request explicitly rather than trusting it for its network location or origin.
- **Grant least privilege by default** — start from the most restrictive access and expand deliberately based on documented business need.
- **Implement defense in depth** — layer preventive, detective, and responsive controls so failure of one doesn't compromise the system.
- **Integrate security by design** — build threat modeling and security requirements into every architecture phase, before build begins.
- **Embed security in automation** — build security controls into CI/CD pipelines, configuration-as-code, and platform defaults.
- **Design for privacy** — architect for data minimization, purpose limitation, consent management, and data-subject-rights workflows.
- **Design for traceability** — make every consequential action attributable and reconstructable through preserved, tamper-resistant audit trails.
- **Design for incident response** — design for detection, real-time intervention, recovery, and response procedures you have tested.

## How to Use These Patterns

Each category pairs **patterns** (what good looks like) with **anti-patterns** (what to avoid), organized so you can review a solution area by area. Start from the trust outcome you need:

- **Establishing who can access what?** Use **Identity and Access Management** for authentication, authorization, MFA, OAuth, and session management.
- **Protecting sensitive data?** Use **Data Protection and Privacy** for encryption, field-level security, data residency, and privacy controls.
- **Meeting regulatory obligations?** Use **Compliance and Regulatory** for audit trails, certifications, and governance.
- **Detecting and responding to threats?** Use **Incident Response and Security Operations** for security monitoring, event detection, and response.
- **Building security into the pipeline?** Use **Secure Development Lifecycle** for shift-left security, OWASP Top 10 defenses, and security testing.
- **Clarifying who owns which control?** Use **Shared Responsibility** to divide security duties between platform features and your implementation.
- **Operating agents in production?** Use **Agentic Patterns** for prompt injection defense, model monitoring, and secure agent-to-agent communication.

## Pattern Categories

### [Agentic Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-agentic-patterns.md)
Trust-specific patterns for agentic systems including prompt injection defense, model monitoring, and secure agent-to-agent communication.

### [Compliance and Regulatory](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-compliance-patterns.md)
Patterns for regulatory compliance, audit trails, certifications, and governance.

### [Data Protection and Privacy](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-data-protection-patterns.md)
Patterns for data encryption, field-level security, data residency, and privacy controls.

### [Identity and Access Management](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-identity-access-patterns.md)
Patterns for authentication, authorization, MFA, OAuth, and session management.

### [Incident Response and Security Operations](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-incident-response-patterns.md)
Patterns for security monitoring, event detection, incident response, and security operations.

### [Secure Development Lifecycle](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-secure-development-patterns.md)
Patterns for shift-left security, OWASP Top 10 defenses, secure pipeline design, and security testing.

### [Shared Responsibility](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-shared-responsibility-patterns.md)
Patterns clarifying security responsibilities between platform features and architect implementation.

## Related Resources

- [Trust pillar](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.md) — the design principles and architectural guidance these patterns implement
- [Trust for the Agentic Enterprise](https://architect.salesforce.com/docs/architect/well-architected/guide/agentic-enterprise-trust.md) — trust guidance for agent-based solutions
- [Well-Architected Framework](https://architect.salesforce.com/docs/architect/well-architected/guide/framework.md) — how Trust fits alongside the other pillars
- [Patterns and Anti-Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/patterns-and-anti-patterns.md) — the full pattern library across all pillars
