Protect, Retain and Prove

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 6 of 6 in the chapter Data Quality and Governance, chapter 5 of the Data Architect course. Each module stands on its own. Previous: Consent and the Right to Be Forgotten · Next: the next chapter, Master Data and Identity

The question this module answers: How do you protect data, keep it as long as required, and prove it?

We’ve set owners and policies, kept bad data out, written the dictionary, traced lineage, classified what matters, learned the laws and modeled consent. Now we have to run it. Data arrives, gets used, copied and changed, ages, and eventually some of it has to go. And someday someone will ask: prove what happened.

Governance Follows the Data

I don’t think of governance as one feature. I think about what happens to the data from the moment it enters until we’re finished with it:

Capture → Classify → Protect → Use → Retain → Delete → Audit

Not seven technical processes: seven questions the architecture has to answer. Capture and classify we’ve covered: keep the expensive errors out (module 2), and know which data is sensitive (module 3). The classification decides what happens at every later stage, so this module picks up from there.

Click to enlarge

Seven questions across the data’s life. Tools support the policy; they don’t define it.

Protect: Match the Control to the Data

Who can see it, change it, receive it? Should it be encrypted, masked outside production, exportable, reachable by an agent? This is where Salesforce security becomes part of data governance: sharing, object and field permissions, encryption, masking, integration access. Those topics fill whole courses, so I won’t reteach them. The governance point: protection follows the classification and the policy. Not every field needs the same protection, not every user the same access, not every downstream system every field.

Encryption Is a Control, Not Compliance

For regulated data, encryption at rest may be required, and my position is that Shield is the answer for key regulatory requirements like it. Shield Platform Encryption encrypts fields and files at rest. But “we encrypted it, so we’re compliant” is wrong twice over. Encryption is one control among access, retention, audit, consent, monitoring, minimization and deletion. And it has functional trade-offs you design for up front. With the default probabilistic scheme, an encrypted field can’t be used in SOQL WHERE, GROUP BY or ORDER BY clauses or in data-management filters; deterministic encryption gives up a little strength so you can filter on the field. Encrypted fields can’t drive criteria-based sharing rules, and you can’t sort list views by them (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). So encryption isn’t a checkbox at the end. It’s an architecture decision. The data security chapter goes deeper.

Don’t Copy Production Risk Into the Sandbox

Production is locked down. Then someone refreshes a full sandbox, and developers, testers, contractors and test integrations now hold copies of real personal data they never needed. The environment changed; the data’s sensitivity didn’t. Salesforce’s masking tools exist for exactly this. Note a change: the Data Mask managed package reaches end of service on 31 December 2026, and its successor is Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). But the tool supports the policy, and the question comes first: does this environment need real sensitive data at all? If realistic, non-sensitive data can do the testing, that’s the better answer.

Use: Permission Isn’t Just About People

Users, integrations, analytics, partners, automation and agents all use the data. Consent (module 5), ownership (module 1) and classification (module 3) meet here at runtime. Should this user see the Recipient’s phone number? Should this integration get it, or Snowflake, or this agent as grounding? The answer can’t be “well, technically it can.” That’s the difference between capability and governance: architecture decides whether it should.

Retain: Keeping Everything Forever Isn’t Neutral

Many organizations have an accidental retention policy: forever. Nobody decided it; storage was available, so the data stayed. But keeping data costs storage and performance, widens privacy and security exposure, adds discovery obligations, and gives you more places to search when someone asks to be forgotten. For each important category: why keep it, how long, what starts the clock, is there a legal minimum or a privacy maximum, and what happens at the end: archive, delete, de-identify?

And archiving isn’t the same as solving retention. “We archived it.” Did the retention requirement go away? The privacy requirement? Security? You changed where the data lives, not what it is. An archive needs access controls, retention and deletion rules, discovery and audit. Move personal data into an archive everyone forgets about, and governance just got worse.

Delete: The Lifecycle Needs an Exit

Deletion isn’t only for individual privacy requests. Data reaches the end of its retention period; temporary records outlive their use; archives expire; a process de-identifies after a set time. Whatever the policy says, the architecture needs an exit, not capture → store → store more → store forever. And as module 5 showed, deleting the Salesforce record isn’t enough when copies live elsewhere.

History Is Data Too

Sometimes the current value isn’t enough. A partner’s legal name, a customer’s classification, a consent status, a financial attribute: the business or a regulator may need to know what it was before, when it changed and who changed it. That history is data, and it needs its own retention decision.

Standard field history tracking follows up to 20 fields per object and keeps changes for up to 18 months, and up to 24 months only through the API, with Data Loader or queryAll() (Field History Tracking Overview (opens in a new tab)). And for long text fields it records only that the field was edited, not what it said: a gap if that’s your evidence. Field Audit Trail, part of Shield or bought on its own, follows up to 200 fields per object and keeps the history until you delete it, in an archive you reach through the API (Field Audit Trail (opens in a new tab)). My position: standard field history is the default; use Field Audit Trail when a regulation or compliance obligation demands longer, provable history. Not because “audit sounds good.”

Auditing and Monitoring Aren’t the Same

Field history answers questions about changes to selected fields. Broader questions (who logged in, who exported data, which APIs were called, who viewed what) are monitoring, and that’s Event Monitoring. In my experience it’s typically needed with more regulated customers, and here’s my strongest position in this chapter: set it up before you need it, and funnel the events into a repository, such as Splunk or another SIEM, ahead of time.

Here’s why. Event log files are kept for 1 day without the add-on, and only for some event types; 30 days by default with Shield or the Event Monitoring add-on, and up to 365 days if you extend retention (Event Monitoring FAQ (opens in a new tab)). Anything older is gone unless you exported it. And the paid logs can’t be retrieved for any period before your contract started (same FAQ): buying the add-on after the incident doesn’t bring the past back. So one of the worst conversations an architect can have goes: “Can we see what happened six months ago?” “No.” “Why not?” “We weren’t capturing it.” You don’t run into an issue and then find out that you haven’t been capturing and storing those events. By then the answer is simply gone.

Click to enlarge

Set it up before you need it.

But don’t swing to “log everything.” What are you trying to prove? Which events matter, who needs them, how long, who may read the logs, and could the logs themselves hold sensitive data? Logging creates data, and that data needs governance too. And evidence needs an owner: who owns the repository, reviews alerts, checks retention works, notices the feed silently failed three months ago? Technology without ownership isn’t governance; we’re back to module 1’s owner, steward and custodian.

Prove the Control, Not Just the Configuration

“Recipient data is available only to the crews assigned to the stop.” How do we know? The security configuration shows what should happen. Operational evidence (who actually accessed it, unusual exports, an integration pulling it, access controls changed) shows what did happen. Good governance often needs both.

Beyond the exam: what AI changes. As agents move from answering to acting, governance needs evidence of what the agent saw, what it decided or generated, and what it did, and who or what started it, under which policy. The logging mechanisms will change; the requirement won’t: if an autonomous action matters, design now how you’ll reconstruct it later.

Steve Trucking: the Lifecycle on One Field

Take the Recipient’s phone number. Capture: it arrives on the partner’s manifest; check it’s usable where the process needs it. Classify: personal data. Protect: only people and systems with an operational need receive it, and crews see it only for their own stops, on the day. Use: the crew coordinates the delivery; messaging uses it for an approved purpose; an agent uses it only if policy permits. Retain: as long as the approved business and privacy policy says. Delete or de-identify: when that period ends or a valid request arrives, across every copy in the landscape. Audit: keep the evidence that the controls and actions happened.

Now take a distribution center code. Capture it accurately, classify it as non-sensitive reference data, protect it with ordinary operational access, use it widely, retain it as the business needs, and audit changes if they matter. Same lifecycle, different controls. That’s what classification is for.

Governance Is Never Finished

A new regulation appears. A new system or integration creates another copy. A team invents another field. A new platform goes live. An agent gets access. A retention rule changes. A new Retail Partner arrives. The architecture moves, and governance moves with it. The goal isn’t perfect data, infinite controls or a governance document nobody reads. It’s deliberate decisions about the data, built into the architecture.

What an Architect Decides Here

• Which protection controls each category of data gets, based on classification, policy and real use, including encryption’s trade-offs.
• How long data and its history are kept, what starts the clock, and what happens at the end.
• When standard field history is enough and when a regulation calls for Field Audit Trail.
• Which events are captured, where the evidence is stored beyond the platform’s retention, and who owns it.
• How the architecture proves important human, integration and agent actions after the fact.

This chapter started with one idea: governance is designed into the org, not written beside it. Owners set policy and architects enforce it. Keep bad data out where it matters. Know what your data means, where it came from and how sensitive it is. Respect the laws, model consent, control where personal data goes. Protect, retain and delete by policy. And capture the evidence before anyone asks for it, because six months after an incident is a terrible time to find out the evidence only existed for thirty days.

Explore

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) and Filter Encrypted Data with Deterministic Encryption (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Field History Tracking Overview (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Field Audit Trail (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab), checked 2026-10-14.