Salesforce Shield in Practice: Encryption, Event Monitoring, and Field Audit Trail

Salesforce Shield is sold as a security product but it’s more accurate to call it a compliance product. It gives you the controls required to meet GDPR Article 32, PCI-DSS, HIPAA, and SOC 2 - encryption at rest, comprehensive audit logging, and long-term field history. Understanding exactly what each component does (and doesn’t do) saves a lot of post-implementation surprises.

Shield Platform Encryption

Shield Platform Encryption (SPE) encrypts field data at rest using AES-256. The crucial distinction from standard Salesforce encryption: SPE uses a tenant-specific key that you control, not a Salesforce-wide key. You can bring your own key (BYOK) via AWS KMS or Azure Key Vault.

What Can and Cannot Be Encrypted

Not all field types support encryption. As of API v59:

This matters architecturally. If you encrypt a Phone field, you can’t filter on it in SOQL with a WHERE Phone = :phoneNumber clause - the comparison happens at the encrypted value level and won’t match. You need to use deterministic encryption for fields you intend to search on.

Deterministic vs Probabilistic Encryption

• Probabilistic: same plaintext → different ciphertext each time. Stronger security but you cannot filter/sort/group by the field.
• Deterministic: same plaintext → same ciphertext. Slightly weaker but allows SOQL filtering, deduplication rules, and matching.

Use deterministic for: email addresses, phone numbers, external IDs - anything you query on. Use probabilistic for: SSNs, credit card fragments, passport numbers - fields you only ever read, never filter on.

Key Management Architecture

The key hierarchy in Shield:

Key Management Service (KMS/HSM)
    └── Tenant Secret (rotated on your schedule)
            └── Data Encryption Key (DEK)
                    └── Field-level encryption of each record

If you use BYOK, the Salesforce infrastructure never has access to your root key. Salesforce holds the DEK but it’s wrapped with your tenant secret - useless without your KMS.

Rotation strategy: rotate tenant secrets annually at minimum; quarterly for highly regulated data. After rotation, data remains readable (Salesforce keeps old DEKs for decryption) but new writes use the new DEK.

Encryption Impact on Reporting and Flows

Encrypted fields cannot be:

• Used in report groupings (if probabilistic)
• Indexed (performance implication for large datasets)
• Used in roll-up summary fields on parent objects
• Searched via SOSL global search

In practice this means you need to design your reporting data model before enabling encryption. Extract encrypted fields to a data warehouse (via Data Loader or Data Cloud) for analytical queries.

Event Monitoring

Event Monitoring captures user and system activity as log files. Available events include:

• LoginEvent - who logged in, from where, with what method
• ApiEvent - every API call with the SOQL query
• ReportEvent - every report run and exported
• LightningInteraction - user clicks and page navigation (Lightning only)
• ApexExecution - apex execution time and CPU consumption

Streaming vs Log Files

Event Monitoring data is available two ways:

Log Files (24-hour delay, CSV format via API): suitable for batch compliance reporting and SIEM ingestion. Use the EventLogFile object and download via REST.

Real-Time Event Monitoring (sub-second, available on certain event types): use for active threat detection. Subscribes via Streaming API / CometD. Available for LoginEventStream, ApiAnomalyEventStream, CredentialStuffingEventStream.

Real-Time is where the interesting security value is. The CredentialStuffingEventStream event fires when Salesforce’s ML detects a credential stuffing attack pattern in progress - you can automate a response (freeze the account, alert the SOC) in real time using a Triggered Flow.

Building a SIEM Integration

Feed Event Monitoring logs into your SIEM (Splunk, Elastic, Microsoft Sentinel):

import requests
from datetime import datetime, timedelta

def fetch_event_logs(session_id, instance_url, event_type, since_hours=24):
    since = (datetime.utcnow() - timedelta(hours=since_hours)).strftime('%Y-%m-%dT%H:%M:%SZ')
    soql = f"""
        SELECT Id, EventType, LogDate, LogFileLength, LogFile
        FROM EventLogFile
        WHERE EventType = '{event_type}'
        AND CreatedDate >= {since}
    """
    resp = requests.get(
        f"{instance_url}/services/data/v59.0/query",
        headers={"Authorization": f"Bearer {session_id}"},
        params={"q": soql}
    )
    return resp.json()["records"]

Set up automated ingestion every 15–30 minutes. Alert on:

• Login from a new country/IP for a privileged user
• Mass data export (ReportEvent with > 10,000 rows)
• API calls querying fields in the SSN or payment data category

Field Audit Trail

Field Audit Trail (FAT) extends standard field history from 18 months to 10 years. It captures before/after values for tracked fields with timestamps and user attribution.

What FAT Is Not

FAT is not a backup. You cannot restore data from FAT - it’s an audit log, not a recovery mechanism. Each entry records the changed value but accessing historical states requires querying FieldHistoryArchive and reconstructing the timeline yourself.

FAT Setup Gotchas

The 60-field limit: FAT tracks up to 60 fields per object. Plan your field selection carefully - you can’t track everything. Prioritise: PII fields, financial data, status fields, and fields relevant to your compliance framework.

Retention vs deletion: FAT data older than your configured retention period is deleted by Salesforce - it does not accumulate indefinitely. If you need data past 10 years (some financial regulations require this), export FAT data to long-term storage before the retention window closes.

Encryption interaction: if a field is both encrypted and tracked in FAT, the historical values in FieldHistoryArchive are also encrypted. This means you cannot read historical values without an active, valid tenant secret - key rotation without retaining old keys will make historical FAT data unreadable.

Compliance Mapping

A quick mapping to common frameworks:

Shield is necessary but not sufficient for compliance. You still need: access controls, data classification, incident response procedures, and regular penetration testing.