Salesforce Shield: Architecture for Regulated Industries

What Salesforce Shield Is and Why It Exists

Salesforce Shield is an add-on product consisting of three security capabilities: Platform Encryption, Event Monitoring, and Field Audit Trail. It was introduced in 2015 in response to growing demand from regulated industries — healthcare (HIPAA), financial services (SOX, FINRA), and government (FedRAMP) — that needed security controls beyond what standard Salesforce provides.

Standard Salesforce provides strong security by any commercial SaaS standard: encrypted data in transit (TLS), encrypted data at rest (database-level encryption), comprehensive access controls, and detailed audit logging at the user action level. But regulated industries often require additional capabilities: field-level encryption with customer-controlled keys, API and UI event capture for security investigation, and extended data history retention for compliance audits. Shield provides these.

Understanding Shield is not just a security concern — it is an architectural concern. Shield changes how data is stored in the Salesforce database, how SOQL queries behave against encrypted fields, what can be reported on, and what custom code can and cannot do. These constraints must be understood before a Shield deployment, not discovered after.

Platform Encryption: What It Actually Encrypts

Salesforce Platform Encryption provides field-level encryption using AES-256, applied at the application layer before data is written to the database. This is different from database-at-rest encryption (which Salesforce already provides) — Platform Encryption means the data is encrypted at the application level, so even a Salesforce database administrator with direct database access sees only ciphertext, not plaintext field values.

Encryption is configured per field. Not all fields can be encrypted — standard fields (Name, Email, Phone on standard objects) can be encrypted using "deterministic" or "probabilistic" encryption. Custom fields can also be encrypted. The type of encryption matters:

Probabilistic encryption: Each encryption of the same plaintext produces different ciphertext. This is cryptographically stronger but means you cannot filter, sort, or query by the encrypted field in SOQL. If you encrypt a Name field with probabilistic encryption, you cannot do WHERE Name = 'Smith' in SOQL — the query would compare ciphertext against a non-matching encrypted comparison value.

Deterministic encryption: The same plaintext always produces the same ciphertext, using a derived key and an HMAC. This allows SOQL equality filtering (WHERE Name = 'Smith' works because both sides encrypt to the same value). However, this is cryptographically weaker than probabilistic encryption and does not protect against frequency analysis attacks.

// What works and what breaks with Platform Encryption

// Deterministic encryption — equality filter works:
SELECT Id, Name FROM Contact WHERE Name = 'John Smith'
// Works — same plaintext encrypts to same ciphertext

// Probabilistic encryption — equality filter breaks:
SELECT Id, Email FROM Contact WHERE Email = 'j.smith@example.com'
// Fails if Email is probabilistically encrypted
// The stored ciphertext won't match the encrypted comparison value

// Global search (UI search bar) — breaks for all encrypted fields:
// Users cannot search for contacts by encrypted field values
// regardless of encryption type

Key Management and BYOK

Platform Encryption uses a tenant secret combined with a Salesforce-managed key to derive the encryption key material. In the standard model, Salesforce holds the master key — meaning Salesforce technical staff could theoretically decrypt customer data by accessing the key and the database. For most organisations, this risk is acceptable given the operational controls Salesforce has in place.

For organisations that require customer-controlled key material — common in financial services and government — Salesforce Shield supports Bring Your Own Key (BYOK). In the BYOK model, the customer provides their own key material (a wrapped key) that Salesforce uses to derive encryption keys. The customer retains the root key material and can revoke access to encrypted data by destroying or rotating the key.

Key rotation is an operational requirement in most regulated environments. Shield supports key rotation — but rotation is not free. Rotating the encryption key requires re-encrypting all existing encrypted field data with the new key. For large orgs with millions of encrypted records, this re-encryption process can take hours or days and consumes significant Salesforce background processing capacity. Plan key rotation windows carefully.

Event Monitoring: The Security Audit Log

Event Monitoring captures detailed logs of every significant user and system action in the Salesforce org: every record view, every report download, every API call, every login attempt, every field value change. These events are written as files that can be downloaded via the Event Log File API or streamed in near real-time via Real-Time Event Monitoring.

Event types cover the full surface of Salesforce activity: Login events, API events (every REST and SOAP API call with the client IP and endpoint), Report events (who downloaded what report and when), Visualforce page access, Lightning component interactions, and more. For a regulated industry, this is the evidence layer required for security investigations and compliance audits.

The typical integration pattern for Event Monitoring is a SIEM (Security Information and Event Management) integration. Event logs are extracted hourly (or in near real-time with Real-Time Event Monitoring) and pushed to a SIEM platform — Splunk, Microsoft Sentinel, IBM QRadar — where they are correlated with events from other systems, rules are applied, and alerts are generated for suspicious patterns (mass data export, after-hours access from unusual IPs, excessive record views by a single user).

// Querying Event Log Files via REST API
GET /services/data/v60.0/query?q=
  SELECT+Id,EventType,LogDate,LogFileLength
  FROM+EventLogFile
  WHERE+EventType='Login'
  AND+LogDate=2026-05-15T00:00:00.000Z

// Download the log file
GET /services/data/v60.0/sobjects/EventLogFile/{Id}/LogFile
// Returns CSV with columns: USER_ID, LOGIN_STATUS, SOURCE_IP,
// LOGIN_TYPE, BROWSER_TYPE, CLIENT_VERSION, etc.

Field Audit Trail: Extended History Retention

Standard Salesforce tracks field history for up to 20 fields per object and retains that history for 18 months. For many regulated industries, 18 months is insufficient — SOX compliance may require 7 years of record history, HIPAA may require 6 years, and some government contracts require 10 years.

Field Audit Trail extends the retention period to up to 10 years and expands the trackable field count to up to 60 fields per object. The data is stored in a separate audit storage layer rather than the standard History object, which allows the extended retention without impacting query performance on the history relationship.

The architectural implication is that Field Audit Trail data is accessed through a different API and object structure than standard field history. Custom reports and dashboards built on standard field history (the FieldHistory related object) do not automatically gain access to the extended audit data. Teams building compliance reporting must query the audit trail storage separately.

Architectural Constraints and Integration Impacts

Shield's architectural constraints extend beyond the field-level encryption limitations. Every integration layer must account for Shield behaviour.

Integration middleware: When encrypted field data is extracted via the Salesforce API to a middleware layer or data warehouse, it arrives decrypted — the API layer handles decryption transparently. This means the integration system receives and stores plaintext. If the compliance requirement is "data encrypted at all points including in middleware and the data warehouse," Shield alone is not sufficient — the integration and data lake layers need their own encryption controls.

Reports and dashboards: Report filters on encrypted fields are limited by the encryption type. Probabilistically encrypted fields cannot be used in report filters. Formula fields that reference encrypted fields are not encrypted themselves and may expose sensitive values via formulas — this is a known Shield limitation that requires architectural workaround (hiding the formula field via FLS while preserving the encrypted source field).

Managed package compatibility: ISV managed packages installed in a Shield-enabled org may have compatibility issues with encrypted fields. Packages that assume certain field types are queryable or searchable break against probabilistically encrypted fields. Validate all installed packages against Shield encryption plans before activation.