Skip to main content

Master Salesforce Shield: Platform Encryption, Event Monitoring & Field Audit Trail

๐Ÿ’ฌ In plain words: Salesforce Shield is a premium security add-on featuring three distinct tools. Platform Encryption scrambles stored data at rest—so even users with raw database access cannot read it. Event Monitoring acts as a security camera, recording who did what (logins, API calls, data exports). Field Audit Trail acts as a time machine, extending your field history retention up to 10 years, far beyond the standard 18–24 months.

๐Ÿ”‘ Key Points

  • Standard Field-Level Security (FLS) controls who can see data on a screen. Shield controls how data is stored, monitored, and retained.
  • Encryption protects stored bytes but costs you functional operations—encrypted fields lose some filtering, sorting, and indexing behavior.
  • Do not encrypt everything. Only encrypt fields that compliance mandates (like PII, PCI, and PHI).
  • Event Monitoring is for historical investigation via SIEM, while Real-Time Event Monitoring can actively block threats as they happen.
๐ŸŽฌ Real-Life Example: Everything Encrypted, Nothing Findable

The Scenario: A bank's compliance team demanded data be unreadable at rest. To be "safe," the Salesforce team enabled Platform Encryption on every field on the Account and Contact objects.

The Old/Bad Way: They passed the security audit, but the service desk was crippled. Users could no longer filter list views by city, sort by company name, or reliably search for records. Encrypting everything isn't extra safety—it's extra breakage.

The New/Good Way: Encrypt only the specific fields the regulation actually names (personal, card, and health data). Leave operational fields unencrypted and control their visibility using standard sharing rules and FLS. The result? The audit passed, and agents got their list views back.
๐Ÿง  Scramble, Record, Rewind: Platform Encryption scrambles storage. Event Monitoring records who did what. Field Audit Trail rewinds field history for years.

๐Ÿ›ก️ Core Concept

Platform Encryption secures data at rest using org-controlled, rotatable keys—and Bring Your Own Key (BYOK) is fully supported. However, it is vital to understand that Platform Encryption is NOT a visibility tool. Field-Level Security and Sharing Rules still determine who sees the data on the screen.

Encryption protects the stored bytes to satisfy compliance mandates, but it comes with a functional cost:

  • Probabilistic Encryption: Completely blocks filtering on that field.
  • Deterministic Encryption: Allows exact-match filters only.

Beyond encryption, Event Monitoring exposes EventLogFiles—covering logins, API usage, report exports, and Apex execution—for ingestion into your Security Information and Event Management (SIEM) tool. Real-Time Event Monitoring adds Transaction Security Policies, which can actively block an action (like a 10,000-row report export from an unknown IP) while it is happening.

Finally, Field Audit Trail (FAT) handles long-term proof. Standard Salesforce tracks limited fields for about 18–24 months. FAT extends this up to 10 years in a queryable archive, providing a definitive answer to the auditor's question: "Who changed this field back in 2021?"

Salesforce Shield Platform Encryption, Event Monitoring & Field Audit Trail

๐Ÿงญ 360 Card — Salesforce Shield

  • Rule: Standard security controls access. Shield adds encrypted storage, activity recording, and long-term history retention.
  • Gain: Three clear, out-of-the-box answers to complex regulator questions with nothing custom to build.
  • Price: It is a paid add-on, and careless encryption will quietly break the search and filtering tools users rely on daily.
  • Limits: Standard field history maxes out at 18-24 months; Shield extends it to 10 years. Shield supports BYOK and key rotation.
  • At Volume: Combine Real-Time Event Monitoring with Transaction Security Policies to turn a static log into an active, automated defense mechanism.
⚠ INTERVIEW TRAP: Never tell an interviewer you would "encrypt everything just to be safe." Encrypting every field breaks filtering, sorting, and some search functionality. Always advocate for encrypting only the specific fields that regulations name.

❓ Core Q&A

Q: A financial-services client asks what Shield actually buys them over standard security. Answer as the architect.

๐ŸŽฏ Say this first: Standard security controls ACCESS. Shield adds three things: Stored data gets encrypted. Activity logs feed the SIEM at an audit grade. Field history is kept for 10 years. Confidentiality, detection, and retention.

A: Standard Salesforce already gives you strong access control via profiles, permission sets, sharing rules, and FLS. Shield answers three questions those tools cannot:

  • Is data unreadable at rest? That is Platform Encryption (with BYOK), scoped specifically to regulated fields.
  • Can we detect and respond to misuse? That is Event Monitoring streaming API and login events to your SIEM, alongside Transaction Security Policies to block risky actions live.
  • Can we prove history to an auditor years later? Field Audit Trail retains field-level changes for up to 10 years.

Be sure to clarify what Shield does not do: It does not replace your access design. A user authorized to view an encrypted field will still see it plainly on their screen.

๐Ÿš€ Scenario-Based Follow-Ups

Q1: Which fields do you encrypt, and what breaks if you encrypt carelessly?

A: You encrypt strictly what the regulation names—the PII, PCI, and PHI fields. If you carelessly encrypt everything, filters and reports on probabilistically encrypted fields stop working entirely. Some formula and matching-rule behaviors are restricted, and SOQL WHERE clauses on those fields will fail. The correct method is to inventory candidate fields, check their usage in reports/filters, use deterministic encryption where exact-match filtering is required, and thoroughly test in a sandbox.

Q2: The CISO wants alerts when anyone exports more than 1,000 records. Which Shield piece do you use, and how?

A: You use Real-Time Event Monitoring. You create a Transaction Security Policy evaluating the Report Event or list export events with a condition on the row count. The policy can instantly block the action or require Multi-Factor Authentication (MFA), while simultaneously sending a notification. For the historical investigation side, you use standard Event Monitoring to ingest EventLogFiles into the SIEM.

Q3: Design monitoring for insider risk and data exfiltration.

๐ŸŽฏ Say this first: Event Monitoring for the historical record of what happened. Transaction Security for stopping it while it happens.

A: This requires two layers. Event Monitoring streams the raw facts (logins, API calls, list view reads) into CRM Analytics or a corporate security platform via the API or Event Relay. On top of that, Real-Time Event Monitoring acts as the active guard. If someone hits the API from an unapproved country or reads records at an impossible, machine-like speed, Transaction Security Policies can step in to block the user or kill the session. Keep in mind: an alert channel that nobody actively owns and monitors is just decoration.

๐Ÿ”— Connecting the Dots

Follow-up for you: Have you audited your current org to identify which specific fields actually contain PII, PCI, or PHI before proposing a full Shield implementation?