Shield Platform Encryption, Event Monitoring & Field Audit Trail

Salesforce Shield is a suite of three products that address enterprise compliance, audit, and data protection requirements. For CTA scenarios, Shield comes up whenever the customer has regulatory requirements (HIPAA, GDPR, PCI-DSS, SOX) or needs enhanced data protection beyond standard platform security.

Shield Components Overview

flowchart LR
    subgraph "Salesforce Shield"
        PE["Platform Encryption\n(Data at rest)"]
        EM["Event Monitoring\n(Who did what)"]
        FAT["Field Audit Trail\n(Data change history)"]
    end

    PE --> RegCompliance["Regulatory Compliance\n(HIPAA, GDPR, PCI)"]
    EM --> ThreatDetection["Threat Detection\n& Forensics"]
    FAT --> AuditCompliance["Audit Trail\n& Data Recovery"]

    style PE fill:#1565c0,color:#fff
    style EM fill:#2e7d32,color:#fff
    style FAT fill:#e65100,color:#fff

Platform Encryption

Platform Encryption encrypts data at rest in the Salesforce database. It sits on top of the standard encryption that protects data in transit (TLS) and at rest (AES-256 for all Salesforce data).

Standard Encryption vs Platform Encryption

Feature	Standard Salesforce Encryption	Platform Encryption (Shield)
Data in transit	TLS 1.2+	TLS 1.2+
Data at rest	AES-256 (Salesforce manages)	AES-256 with customer-controlled keys
Key management	Salesforce only	Customer can manage keys (BYOK, cache-only)
Field-level control	No	Yes — choose which fields to encrypt
Compliance certifications	SOC 2	HIPAA, PCI-DSS, GDPR, SOX
Functionality impact	None	Some — see trade-offs below

Encryption Schemes

Scheme	Searchability	Filter/Sort	Uniqueness	Use Case
Deterministic	Yes (exact match)	Yes (limited)	Can enforce	Fields that need filtering: Email, Phone, SSN
Probabilistic	No	No	Cannot enforce	Maximum security: Description, Notes, custom text areas

flowchart TD
    Q1{"Does the field need to\nbe searchable/filterable?"} -->|Yes| Q2{"Exact match\nor substring?"}
    Q1 -->|No| Prob["Use Probabilistic\n(Maximum security)"]
    Q2 -->|"Exact match"| Det["Use Deterministic\n(Searchable)"]
    Q2 -->|"Substring/LIKE"| Q3{"Can you use a\nmasked field instead?"}
    Q3 -->|Yes| Mask["Create unencrypted\nmasked formula field +\nEncrypt source field"]
    Q3 -->|No| DetLimited["Use Deterministic\n(Accept exact-match-only limitation)"]

    style Prob fill:#1565c0,color:#fff
    style Det fill:#2e7d32,color:#fff
    style Mask fill:#e65100,color:#fff

Deterministic Is Not Fully Searchable

Deterministic encryption only supports exact-match searches — you cannot use LIKE, CONTAINS, or wildcards. If users need to search for “John%” across encrypted Name fields, deterministic encryption will not work. Plan for this limitation in your architecture.

What Can Be Encrypted

Encryptable	Examples	Notes
Standard fields	Name (First/Last), Email, Phone, Description, Address fields	Not all standard fields are encryptable
Custom fields	Text, Text Area, Long Text Area, Email, Phone, URL, Date, Date/Time	Number and Currency supported in some editions
Files & Attachments	Files, Attachments, Content	Entire body is encrypted
Search Index	The search index itself	Additional protection for search data
Chatter	Posts, comments	Enterprise-grade Chatter security

What CANNOT Be Encrypted

Not Encryptable	Why
Formula fields	Derived from other fields — encrypt the source field instead
Auto-Number fields	Platform-generated sequences
Lookup/Master-Detail fields	Relationship fields (IDs)
Picklist fields	Limited data type; use sharing rules instead
Standard Name fields on some objects	Platform limitations per object

Encryption Trade-offs

This is where CTA candidates are tested — not on whether to encrypt, but on understanding the cost of encryption.

Capability	Without Encryption	With Deterministic	With Probabilistic
SOQL WHERE clause	Full support	Exact match only	Not supported
SOQL ORDER BY	Full support	Limited	Not supported
SOQL LIKE	Full support	Not supported	Not supported
Aggregate functions	Full support	Not supported	Not supported
Workflow field updates	Full support	Full support	Full support
Validation rules	Full support	Limited	Limited
Duplicate rules	Full support	Exact match only	Not supported
Formula fields referencing	Full support	Limited functions	Limited functions
Report filters	Full support	Exact match only	Not supported
Auto-complete/typeahead	Full support	Not supported	Not supported

Encryption Breaks Things

Platform Encryption is not free. It breaks functionality that your users depend on — SOQL filtering, sorting, LIKE queries, auto-complete, and aggregate reporting. You must do a thorough impact analysis before recommending encryption for any field. The CTA board will ask “what breaks when you encrypt this?”

Key Management

Key Option	Who Manages	Key Location	Rotation	Use Case
Salesforce-managed	Salesforce	Salesforce infrastructure	Salesforce rotates	Standard compliance; simplest
Customer-managed (BYOK)	Customer	HSM (via API upload)	Customer controls	High-security; regulatory requirement for key control
Cache-only keys	Customer	Customer infrastructure (never persisted in SF)	Customer controls	Maximum control — key only exists in SF cache

BYOK (Bring Your Own Key)

flowchart LR
    Customer["Customer HSM\n(Key generation)"] -->|"Upload via API"| SF["Salesforce\n(Key stored in\ntenant secret)"]
    SF -->|"Uses key for\nencrypt/decrypt"| Data["Encrypted Data\n(At rest)"]
    Customer -->|"Can revoke/rotate"| SF

    style Customer fill:#1565c0,color:#fff
    style SF fill:#2e7d32,color:#fff
    style Data fill:#e65100,color:#fff

Key Management Architecture

Understanding the full key management decision flow helps CTA candidates select the right approach for a given compliance scenario.

flowchart TD
    Start["Encryption key\nmanagement requirement"] --> Q1{"Does the customer\nrequire key control?"}
    Q1 -->|No| SFManaged["Salesforce-Managed Keys\n- Simplest option\n- SF handles rotation\n- Meets most compliance"]
    Q1 -->|Yes| Q2{"Must the key NEVER\nbe stored in Salesforce\ninfrastructure?"}
    Q2 -->|No| BYOK["BYOK\n- Customer generates key\n- Uploads via API\n- Stored as tenant secret\n- Customer controls rotation"]
    Q2 -->|Yes| Cache["Cache-Only Keys\n- Key sent on-demand\n- Only exists in RAM\n- Customer infra dependency\n- Maximum control"]

    SFManaged --> Deploy["Deploy to Production\n(sandbox testing first)"]
    BYOK --> Deploy
    Cache --> Avail{"Can you accept\navailability dependency\non customer key service?"}
    Avail -->|Yes| Deploy
    Avail -->|No| BYOK

    style SFManaged fill:#2e7d32,color:#fff
    style BYOK fill:#1565c0,color:#fff
    style Cache fill:#c62828,color:#fff

Cache-Only Keys

Cache-only keys provide the highest level of customer control. The key is sent to Salesforce on-demand and only exists in memory — it is never persisted.

Aspect	BYOK	Cache-Only Keys
Key persistence in SF	Yes (encrypted tenant secret)	No — only in RAM cache
Data access if key revoked	Data remains encrypted; can re-provide key	Data inaccessible until key re-provided
Availability risk	Low — key persisted	Higher — key service must be available
Control level	High	Maximum
Complexity	Medium	High

Cache-Only Key Availability

With cache-only keys, if the customer’s key service is unavailable, Salesforce cannot decrypt the data. This creates an availability dependency on the customer’s infrastructure. Architects must evaluate whether this trade-off is acceptable for the use case.

Event Monitoring

Event Monitoring captures detailed user activity logs across the Salesforce platform. It answers “who did what, when, and from where?”

Event Types

Category	Events Tracked	Use Case
Login events	Login attempts, login geography, login status	Detect unauthorized access, credential stuffing
API events	API calls, object access, query patterns	Detect data exfiltration, API abuse
Report/Dashboard events	Report runs, dashboard views, export events	Detect mass data export attempts
URI events	Page views, record views	User behavior analysis
Lightning events	LWC/Aura component interactions	Application usage analytics
Apex events	Apex execution, governor limit usage	Performance monitoring
Content events	File downloads, content access	Detect sensitive document access

Event Monitoring Architecture

flowchart TD
    subgraph "User Activity"
        Login["Login Events"]
        API["API Events"]
        Report["Report Events"]
        Content["Content Events"]
    end

    subgraph "Event Capture"
        EL["Event Log Files\n(24-hour delay)"]
        RTE["Real-Time Events\n(Platform Events)"]
    end

    subgraph "Analysis & Response"
        ELAPI["Download via API\n(EventLogFile sObject)"]
        TS["Transaction Security\nPolicies (Real-time)"]
        CRM["CRM Analytics\n(Event Monitoring App)"]
    end

    subgraph "Actions"
        Block["Block Action"]
        MFAStep["Require MFA"]
        Notify["Notify Admin"]
        Forensics["Forensic Analysis"]
    end

    Login --> EL
    Login --> RTE
    API --> EL
    API --> RTE
    Report --> EL
    Content --> EL

    EL --> ELAPI --> Forensics
    EL --> CRM --> Forensics
    RTE --> TS
    TS --> Block
    TS --> MFAStep
    TS --> Notify

    style Block fill:#c62828,color:#fff
    style TS fill:#e65100,color:#fff
    style CRM fill:#1565c0,color:#fff

Real-Time Event Monitoring

Feature	Standard Event Monitoring	Real-Time Event Monitoring
Log availability	24-hour delay (log files)	Near real-time (Platform Events)
Retention	30 days (or 1 day for some types)	Subscription-based
Automation	Download and analyze	Transaction Security policies
Use case	Historical analysis, forensics	Active threat detection, automated response

Transaction Security

Transaction Security policies evaluate events in real-time and can block, notify, or require MFA when conditions are met.

flowchart LR
    Event["User Action\n(e.g., Export Report)"] --> Policy["Transaction Security Policy\nEvaluate condition"]
    Policy -->|"Condition met"| Action{"What action?"}
    Action -->|Block| Blocked["Block the action\n+ Notify admin"]
    Action -->|MFA| MFA["Require MFA\nre-authentication"]
    Action -->|Notify| Notify["Allow action\n+ Send notification"]
    Policy -->|"Condition not met"| Allow["Allow action\n(No intervention)"]

    style Blocked fill:#c62828,color:#fff
    style MFA fill:#e65100,color:#fff
    style Allow fill:#2e7d32,color:#fff

Example policies:

• Block report exports that contain more than 10,000 records
• Require MFA when a user logs in from an unrecognized IP
• Notify admin when a user views more than 500 records in an hour
• Block API sessions that exceed normal query patterns

Field Audit Trail

Field Audit Trail (FAT) extends the standard field history tracking to support up to 10 years of data retention and up to 60 fields per object.

Standard History vs Field Audit Trail

Feature	Standard Field History	Field Audit Trail
Fields per object	20	60
Retention	18-24 months	Up to 10 years
Storage	Standard Salesforce storage	Big Object (FieldHistoryArchive)
Queryable	SOQL	Standard SOQL on FieldHistoryArchive Big Object, or Salesforce CLI
Cost	Free	Shield license
Data type support	Most field types	Same as standard
Archive policy	N/A	Configurable retention per object

Field Audit Trail Architecture

flowchart LR
    Change["Field Value\nChange"] --> FHT["Field History\nTracking\n(Standard)"]
    FHT -->|"After retention\nperiod"| Archive["FieldHistoryArchive\n(Big Object)"]
    Archive --> Query["Query via:\n- Standard SOQL on Big Object\n- Salesforce CLI\n- REST API"]
    Archive --> Retention["Retention Policy\n(Up to 10 years)"]

    style FHT fill:#1565c0,color:#fff
    style Archive fill:#2e7d32,color:#fff

Field Audit Trail Use Cases

Regulation	Requirement	How FAT Helps
SOX	Financial data change audit trail	Track changes to Amount, Stage, Close Date on Opportunities
HIPAA	Protected health information access logging	Track changes to patient fields on Health Cloud objects
GDPR	Data processing records	Track changes to consent fields, data subject attributes
PCI-DSS	Cardholder data access logging	Track access to payment-related fields

Shield Licensing and Cost Considerations

Shield Costs

Shield is an add-on license that is priced per-org, not per-user. The cost is significant — typically 30-50% of the base platform license cost. CTA candidates must weigh the compliance benefit against the cost and recommend Shield only when regulatory requirements demand it. If the scenario does not mention compliance requirements, do not recommend Shield.

Decision Factor	Recommend Shield	Do Not Recommend Shield
HIPAA/PCI/SOX compliance	Yes	N/A
Regulatory audit requirements	Yes	N/A
Customer demands key management	Yes (BYOK/cache-only)	N/A
General “we want more security”	Evaluate if standard features suffice	If standard encryption + sharing model is adequate
Data breach concern	If need forensics + real-time detection	If standard login tracking is sufficient

Related Topics

• Sharing Model — encryption protects data at rest; sharing controls who sees it
• Programmatic Security — working with encrypted fields in Apex
• Field & Object Security — FLS and profiles complement encryption
• Security Trade-offs — encryption’s impact on functionality
• Decision Guides — encryption strategy decision tree
• Data Architecture — LDV and data retention alongside FAT

Sources

• Salesforce Help: Shield Platform Encryption
• Salesforce Help: Event Monitoring
• Salesforce Help: Field Audit Trail
• Salesforce Help: Transaction Security
• Salesforce Help: BYOK
• Salesforce Help: Cache-Only Keys
• Salesforce Architects: Data Protection Strategy