Many Salesforce orgs never need Shield. Shield is a paid bundle of four tools: Platform Encryption, Event Monitoring, Field Audit Trail and Data Detect. Together they add encryption at rest under keys you control, detailed activity logs, field history kept for up to ten years, and automated scanning for sensitive data. Buy it when a regulator, auditor, customer contract or security team asks for one of those specific controls. If the real concern is who can see which records, sharing and field-level security already handle that.
What Shield includes today
Salesforce currently lists four core Shield components and says they can also be bought individually when you only need one. Security Center, which pulls security settings and permissions from several orgs into one set of dashboards, is marketed alongside Shield but sold separately. The useful way to read the bundle is component by component, next to what your edition already gives you.
| Shield component | What it adds | Closest standard feature |
|---|---|---|
| Platform Encryption | AES-256 encryption at rest for standard and custom fields, files and attachments, with Salesforce-managed keys, Bring Your Own Key or the Cache-Only Key Service | Classic Encryption: a special custom text field, 175 characters maximum, masked for users without View Encrypted Data |
| Event Monitoring | Log files for dozens of event types, such as report exports, API calls and page views, plus Transaction Security Policies that can alert on or block activity as it happens | Login History, Setup Audit Trail and a handful of free event log files kept for one day |
| Field Audit Trail | Field change history retained for up to ten years, on up to 200 fields per object | Field History Tracking with its standard retention window |
| Data Detect | Scans chosen objects and fields for sensitive data using preconfigured categories, custom patterns and keywords | Data classification metadata on fields, filled in by hand |
Encryption does not decide who sees what
This is a common misunderstanding. Shield Platform Encryption protects data stored in Salesforce's infrastructure, but it is not a visibility control. Salesforce's own guidance is plain: anyone with read access to an encrypted field sees its value in clear text. If a sales rep should not see a client's tax ID, the fix is field-level security, the sharing model and object permissions, whether or not you encrypt the field.
Encryption also changes how fields behave. You cannot sort list views by an encrypted field, and probabilistic encryption, the stronger default, blocks filtering. Deterministic encryption allows exact-match filters in reports and list views at some cost to encryption strength. Encrypted values take more storage, which can shorten the maximum length of fields such as Address and Subject. Some managed packages and custom code were not written with encrypted fields in mind. Plan on a sandbox test of every report, list view, Flow and integration that touches a field before encrypting it in production.
Situations that genuinely call for Shield
Salesforce positions Shield for companies holding sensitive customer data in regulated industries and cites frameworks such as HIPAA, GDPR, SOX and FINRA rules. None of those frameworks names Shield. What matters is whether your compliance program, auditors or customers require a control that only Shield supplies. These are the requests that usually tip the decision:
- A security policy or customer contract requires encryption at rest with keys your company generates, rotates or can revoke.
- Auditors or regulators expect you to show who changed a regulated field, and when, for longer than standard field history keeps it.
- You must be able to prove which users viewed, exported or pulled records through the API, and keep that evidence for months rather than a day.
- The security team wants alerts or blocks when someone runs an unusually large report export or logs in from an unexpected place.
- Nobody can say with confidence where Social Security numbers, account numbers or health details have ended up across notes, text fields and custom objects.
- Your security operations tools need a steady feed of Salesforce activity to correlate with other systems.
Wealth management firms, lenders, insurers and health organizations meet these requests most often, but a software company selling to banks can face the same demands through vendor security questionnaires. The trigger is the requirement, not the industry label.
What standard features already cover
Before scoping Shield, confirm the org is using the controls it already pays for. In our experience, orgs that ask about Shield often have broader gaps in the basics, and closing those gaps satisfies much of what the compliance team actually asked for.
- Private organization-wide defaults, a role hierarchy that reflects real visibility needs, and field-level security on every sensitive field.
- Classic Encryption for a small number of short values, such as a partial account number, where masking for most users is enough and nobody needs to filter on the field.
- Field History Tracking on the fields auditors care about, with a documented process for exporting history you must keep longer.
- Data classification metadata, which records a data owner, sensitivity level and compliance category for each field and can be reported on.
- Health Check, Setup Audit Trail and Login History, reviewed on a schedule rather than only after an incident.
- Minimizing what you store: a field that holds only the last four digits carries far less risk than one holding the full number.
If these are in place and a written requirement still points to a Shield capability, you have a clear case. If they are not, buying Shield first tends to produce encrypted fields that the wrong people can still read.
Buying one component instead of the bundle
Because the components can be licensed separately, map each written requirement to the component that answers it. A firm whose auditors only ask for long-term change history may need Field Audit Trail alone. A company worried about data leaving through exports may get most of the value from Event Monitoring and its Transaction Security Policies. Encryption is usually the component with the largest effect on day-to-day use, so it deserves the most testing, and it is the one we see bought too early.
Data Detect is best used as a first step rather than an afterthought. A scan shows which fields actually contain sensitive values, including free-text fields where users typed them, and Salesforce's recommendations from the scan feed directly into classification, encryption policies, transaction security and masking in sandboxes with Data Mask. Knowing where the data sits makes the encryption and monitoring scope much smaller and cheaper to test.
How to decide in four steps
First, collect the written requirements from compliance, security and key customer contracts. Second, review access: sharing, field-level security, integration users and exports, since those gaps matter whether or not you buy Shield. Third, map each remaining requirement to one component and note what standard feature falls short. Fourth, if encryption is on the list, run it in a full or partial copy sandbox against real reports, automation and integrations before committing. Pricing depends on your edition and contract, so ask your Salesforce account team for a quote per component as well as for the bundle.
