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 surfaces whenever the customer has regulatory obligations (HIPAA, GDPR, PCI-DSS, SOX) or needs data protection beyond what standard platform security provides.

Shield Components Overview

Figure 1. Shield bundles three distinct compliance capabilities. Each addresses a different audit dimension: encryption protects data at rest, Event Monitoring answers who accessed what data and when, and Field Audit Trail provides the long-term change history required by SOX and HIPAA retention mandates.

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

Figure 2. Encryption scheme selection is driven entirely by how the field is queried. Fields that need substring search (LIKE, CONTAINS) cannot be fully satisfied by either scheme. The masked formula field pattern is the only workaround that preserves partial display without exposing the source value.

Deterministic Is Not Fully Searchable

Deterministic encryption only supports exact-match searches. LIKE, CONTAINS, and wildcards do not work. If users need to search for “John%” across encrypted Name fields, deterministic encryption will not satisfy that requirement. Plan for this limitation up front.

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 are not supported for field-level encryption (they break aggregation, reporting, and roll-up summaries)
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

Database Encryption (Hyperforce)

Database Encryption (also called Transparent Data Encryption) encrypts the entire database at the storage layer, rather than selectively encrypting individual fields. It is available only on Hyperforce with a Shield license.

Aspect	Field-Level Encryption (FLE)	Database Encryption
Approach	Application-layer, per-field	Storage-layer, whole-database
Functional Impact	Breaks aggregate/sort/filter (unless deterministic)	Zero; transparent to the application
Granularity	Selective (choose specific fields)	Entire database (not selective)
Key Management	BYOK, Cache-Only Keys, SF-managed	BYOK, SF-managed (no Cache-Only Keys)
Requirement	Any infrastructure	Hyperforce only

Because Database Encryption operates at the storage layer, it has none of the field-type restrictions that FLE has. Number, Currency, and all other field types are encrypted transparently without breaking queries, sorting, aggregation, or reporting. The trade-off: you cannot selectively encrypt specific fields. It is all or nothing at the database level.

CTA Decision: FLE vs Database Encryption

If the scenario is on Hyperforce and the compliance requirement is “encrypt data at rest” without needing field-selective control or Cache-Only Key management, recommend Database Encryption for zero functional impact. If the scenario requires selective field encryption, crypto-shredding via Cache-Only Keys, or is not on Hyperforce, FLE remains the only option despite its functional trade-offs.

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.

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 users depend on: SOQL filtering, sorting, LIKE queries, auto-complete, and aggregate reporting. A thorough impact analysis is required before encrypting 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)

Figure 3. BYOK gives the customer control over encryption key generation and rotation while Salesforce retains a copy as a tenant secret. The key trade-off versus cache-only keys: the key is persisted in Salesforce infrastructure, which simplifies availability but gives the customer less absolute control.

Key Management Architecture

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

Figure 4. Cache-only keys provide maximum control but introduce an availability dependency: if the customer’s key service is down, Salesforce cannot decrypt data. When the customer cannot accept that risk, BYOK is the correct fallback, as it offers key control without the availability dependency.

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.

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

Figure 5. Event Monitoring splits into two paths: log files for retrospective forensic analysis (with a 24-hour delay) and real-time platform events that feed Transaction Security policies for immediate automated responses like blocking or requiring MFA re-authentication.

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.

Figure 6. Transaction Security evaluates policies in real time at the moment of the user action. The three response options (block, MFA step-up, and notify-only) allow graduated responses: blocking for high-risk actions like mass data export, MFA step-up for sensitive record access, and notification-only for audit visibility.

Example policies:

• Block report exports containing 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 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

Figure 7. Field Audit Trail extends standard field history by archiving changes to a Big Object, enabling up to 10 years of retention with 60 fields per object. The FieldHistoryArchive Big Object is queried like any other object via SOQL, making historical data accessible for SOX and HIPAA audit responses.

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 priced per-org, not per-user. The cost is significant, typically 30-50% of the base platform license cost. 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