Classify, Then Protect

The question this module answers: Which protection does each kind of data get, for every consumer, and what does it cost?

A Label Isn’t a Lock

Back in chapter 5 we classified Steve Trucking’s data. The Recipient’s phone number: personal data. The home address: personal data. Delivery notes, which may hold a gate code or “dog in the yard”: sensitive. A DC code: not worth the governance energy. And I said it then: classification without enforcement is decoration.

This module is the enforcement. Mark the gate code Restricted and change nothing else, and every crew member, every care agent, the partner integration and the Recipient’s agent can still read it. The label is honest. The data is just as exposed as it was yesterday.

When I teach this live, I ask the room: “Somebody tell me, where do I classify data?” Someone always finds it: on the field, in Setup, public, internal, confidential, restricted or mission critical. Good. That’s the input. Now the architect’s question starts: what are we going to do differently because of that label?

Who can see it? Can it be changed, and by whom? Should it be encrypted, and does it still need to be searchable after? Can a sandbox hold the real value? Can an integration retrieve it? Can an agent? Can it go into a prompt to a large language model? How long do we keep it? Every one of those is a design decision, and the classification is what makes the decision repeatable instead of a fresh argument for every field.

Sensitivity and Use: Two Questions, Not One

A level tells you how sensitive the data is. It doesn’t tell you how the data is used, and the use changes the protection.

Take two Restricted fields at Steve Trucking. The gate code on a delivery: nobody ever searches by it. The crew assigned to that delivery reads it at the gate, and nobody else should. And a crew member’s driver’s license number, on the Crew Member HR record we split out in module 1: the HR team looks people up by it when a license is renewed, and the compliance check matches it against the state’s records.

Same level. Very different use. One is never searched; the other has to be found by an exact value. When we get to encryption, that difference decides the encryption scheme. So for every sensitive field I want two answers in the design, side by side: how sensitive is it, and what must it still be able to do?

How Many Levels?

Salesforce gives every field a Data Sensitivity Level, and its default values are Public, Internal, Confidential, Restricted and MissionCritical. They’re a picklist you can change: the values live in a standard value set your org can edit (Salesforce, Object Reference, FieldSecurityClassification (opens in a new tab), API version 68.0, checked 2026-10-28). Salesforce’s Well-Architected guidance uses four tiers: Public, Internal, Confidential and Restricted (Trust (opens in a new tab), checked 2026-10-21).

Five levels, then. What does each one add? Public, Internal, Confidential and Restricted cover the range most organizations deal with: from anyone may see it, to a small approved group, often because a law or a contract says so. MissionCritical is the level above that: a very small group, for information where exposure would do serious damage and the handling rules are usually set by law or regulation, such as national security work, critical infrastructure or certain government programs.

Most companies never need it. If nothing in your organization sits above Restricted, a fifth level is a column in the matrix that no field ever uses, and a choice people get wrong because they can’t tell it from the fourth. So for most organizations, four levels are the useful set, and that’s what Steve Trucking uses. If your company does handle that kind of information, keep the fifth level, and give it controls that are clearly stronger than Restricted, or it isn’t a level.

Whatever the number, every organization decides what its levels mean, and a level only earns its place if it changes a control. At a trucking company, the most sensitive tier might be a crew member’s medical record and the code to someone’s gate. At a manufacturer building components for defense systems, the top tier carries obligations of a different order entirely. Classification is organizational policy. Architecture implements that policy.

Steve Trucking’s four levels, with an example of each:

• Public: the tracking page’s “out for delivery” and the delivery window; DC addresses.
• Internal: Work Orders, Manifests, routes, truck numbers, the partner’s service levels.
• Confidential: the Recipient’s name, phone and address; partner contract rates; damage claim amounts.
• Restricted: gate codes and access notes; a crew member’s driver’s license number and medical certificate; the bank details for a partner’s damage credits.

Build the Protection Matrix

Here’s how I make the policy visible. Instead of security scattered across permission sets, encryption settings, sandbox refresh steps, integration users and agent configuration, put it in one matrix: the levels down the side, the controls across the top. This is Steve Trucking’s starting point. It’s not a Salesforce standard, and it’s not my policy for your company. It’s the shape of the decision, with defaults you adapt.

Level	Who sees it	Encryption	Outside production	Applications	Agents	May enter an AI prompt?	Audit
Public	Anyone, including the tracking page	None needed	Real values are fine	Any approved integration	Any agent	Yes	Standard
Internal	Employees and contractors; partners see their own through sharing	None by default	Real values are fine unless combined with personal data	Approved integrations, through their own integration users	Employee agents, as the user	Yes, inside approved agents	Standard
Confidential	Field-level security limited to the roles that need it	When a law, contract or customer requires it	Masked	Only an integration whose job needs it	Only an agent whose job needs it; never a public-facing agent	Only the fields the task needs; masking is a safety net, not the plan	Field history on key fields
Restricted	A small group; a separate object when the audience differs	Yes: Shield, probabilistic unless the use requires exact match	Never the real value	Explicitly approved, one integration at a time, audited	No direct access by default; a controlled action that returns only the answer	No, unless a reviewed exception says so	Field Audit Trail; Event Monitoring on access

Read it across a row and you get the rules for one level of data. Read it down a column and you get the rules for one kind of consumer. Most organizations already have the first three columns somewhere, in a policy document nobody opens. The last three are the ones I find missing: applications, agents and AI prompts. That’s the new world, and it’s why this matrix gets a column for each.

As sensitivity goes up, every column tightens: fewer people, more justification to store or copy or move the data, more proof that the controls work. An architect can step outside a default when a real business requirement justifies it. The point is that the exception is deliberate, written down and reviewed, not something we discover in an audit.

Click to enlarge

Test knowledge. Know Salesforce’s data classification fields on every standard and custom field: Data Owner, Field Usage, Data Sensitivity Level (default values Public, Internal, Confidential, Restricted, MissionCritical) and Compliance Categorization (such as PII, GDPR, CCPA, HIPAA, PCI). Know that they’re labels: they don’t restrict access, encrypt or mask anything by themselves.

Don’t Start With Encryption

When someone says “this field is sensitive,” the first answer I hear in the room is “encrypt it.” Maybe. But walk through what encryption at rest actually changes at Steve Trucking.

Encrypt the gate code, then leave it readable by 2,000 users. Did encryption solve the access problem? No: every one of them still sees the decrypted value on the screen. Encrypt it, then the nightly integration copies it to the partner’s warehouse in plain text. Did encryption protect it there? No. Encrypt it, then a care agent pastes it into an email. Same answer.

Encryption at rest protects the stored data from a particular set of threats, such as someone who gets at the underlying storage. It doesn’t replace access control, minimization, masking, audit, retention or integration design. So don’t start with “which encryption checkbox do I need?” Start with: what am I protecting, from whom, and while it’s doing what?

Which Levels Get Encryption

Encryption at rest is often a regulatory requirement, or a contractual one. A health regulation, a payment card standard, a customer’s security addendum: these are the usual reasons a field must be encrypted, and my position from chapter 5 holds: Shield is the answer for key regulatory requirements like it.

In the matrix, that becomes a rule by level:

• Restricted: encrypt. These are the fields a breach report would name.
• Confidential: encrypt when a law, contract or customer requires it, and document which one. Otherwise rely on access control, masking and audit.
• Internal and Public: don’t encrypt by default. Encrypting everything doesn’t make you more secure; it makes the org harder to use and harder to change, and it hides the fields that really matter among the ones that don’t.

I’ll be blunt about that last point because I’ve watched it happen: don’t encrypt every field. Encrypt the fields your policy names, and know why each one is on the list.

Two Kinds of Shield Encryption

Salesforce now offers two ways to encrypt data at rest under Shield, and the trade-offs depend on which one you have.

Field-level encryption (Shield Platform Encryption, the one most of us know) encrypts chosen fields and files in the application tier. It’s where the classic trade-offs live. With the default probabilistic scheme, an encrypted field can’t be used to filter, sort or group in queries; deterministic encryption gives up a little strength so you can filter on exact values (chapter 5 module 6 listed the considerations).

Database Encryption is newer. It encrypts the “Full transactional database,” it requires Hyperforce, and it supports filtering, sorting and search (Salesforce Help, Differences Between FLE and Database Encryption (opens in a new tab), checked 2026-10-27). That removes many of the functional costs, and it changes the conversation: the question becomes what each layer protects against, and what your regulation or contract actually asks for.

So before designing around encryption’s limits, find out which kind the org has, or will have. A design that avoids filtering on an encrypted field because of field-level encryption may not need to on Database Encryption, and a design built for Database Encryption may break if the org only licenses field-level encryption.

Check availability, too. Database Encryption comes with Salesforce Shield, and Salesforce says it “hasn’t yet been deployed to all Hyperforce regions and instances” (Salesforce Shield Platform Encryption Architecture (opens in a new tab), no page date, checked 2026-10-29). Ask your account team whether it’s available for your org before a design depends on it.

Test knowledge. Know that Shield Platform Encryption encrypts data at rest, separate from encryption in transit, and that field-level encryption limits what you can do with an encrypted field, while Database Encryption (Hyperforce) encrypts the whole transactional database and keeps filtering, sorting and search.

Probabilistic by Default, Deterministic When the Use Requires It

With field-level encryption, each encrypted field gets a scheme, and this is where the use from earlier comes back.

Probabilistic is the default. The same value encrypts to different ciphertext every time, so a pattern in the stored data reveals nothing. It’s the stronger choice, and its cost is that the field can’t be filtered: you can’t find a record by it.

Deterministic encrypts the same value the same way, so the platform can match it. Salesforce’s Help says deterministic encryption supports filtering in reports, list views and SOQL WHERE clauses, and unique and external ID fields, as case-sensitive or exact-match case-insensitive matches (Salesforce Help, Filter Encrypted Data with Deterministic Encryption (opens in a new tab), checked 2026-10-27). Exact match: not “contains”, not “starts with”.

My rule, from the interview I did for this chapter: probabilistic by default; deterministic only where exact-match filtering is essential. Back to the two Restricted fields:

• The gate code is never searched. Probabilistic.
• The driver’s license number must be found by an exact value when a license is renewed and when compliance checks it. Deterministic, case-insensitive.
• And the Recipient’s phone, if a regulation or contract makes us encrypt it, is used by duplicate matching and by the care team to find a delivery when someone calls. Deterministic, exact match. Then check that the matching rules still work, because matching on encrypted fields has its own considerations.

The question isn’t “which scheme sounds more secure?” It’s what must the field still be able to do after I protect it?

Click to enlarge

Test knowledge. Know probabilistic (the default, strongest, can’t be filtered) and deterministic (exact-match filtering in reports, list views and SOQL WHERE, case-sensitive or exact-match case-insensitive, at a small cost in strength). Choose by the field’s use.

Don’t Turn On Shield a Week Before Go-Live

Here’s the story I tell in class. A project gets to the last week before go-live, someone from security reads the policy, and the request comes in: turn on Shield. Don’t let them turn on Shield a week before go-live.

Encryption changes how fields behave. Reports that filtered on a field stop filtering. A matching rule stops matching. An integration that looked records up by a value can’t find them. A formula or a flow that used the field may need to change. None of that is visible until you test it.

So turn it on early, in a full sandbox, with the real configuration, and test everything that touches the encrypted fields: the reports, the list views, the matching rules, the integrations, the automation. Encryption is an architecture decision, which means it belongs at the start of the design, not the end of the project.

Don’t Weaken Protection for a Bad Requirement

Sometimes the conversation goes: “We need deterministic encryption because everybody searches by this sensitive number.” Maybe. Before agreeing, ask why everybody searches by it, and whether they should.

At Steve Trucking, if the care team finds deliveries by the Recipient’s phone, could they find them by the delivery number on the tracking text instead? If HR looks crew members up by license number, could they use the employee number, and keep the license number for the one compliance check that needs it? Sometimes the requirement is real. Sometimes a process has grown around a sensitive value, and we’re about to weaken a control to keep the process. Don’t only ask how to make the requirement work. Ask: should this requirement exist?

Encryption Doesn’t Fix the Screen

Encrypt the partner’s bank account number, and the care agent who opens the record still sees all of it. Encryption at rest did its job. The exposure is on the screen.

Most people who open that record need the last four digits to confirm they’re looking at the right account, nothing more. That’s a different control: limit what’s displayed, through field-level security and a field that holds only the last four digits, or a component that shows a masked value. Security covers the whole path: stored, retrieved, displayed, copied, exported, integrated and used by an agent. One control rarely covers all of it.

Masking: This Environment Doesn’t Need the Real Value

Encryption says: protect this value, and let the people and systems who need it recover it. Masking says something stronger: this environment, or this consumer, doesn’t need the real value at all.

The obvious place is the sandbox. Developers need realistic deliveries to test the routing. They don’t need real Recipients’ names, phones and gate codes. We want realistic shape, not real identity. The matrix says it per level: Public and Internal can be copied as they are; Confidential is masked; Restricted never leaves production as a real value. Chapter 5 covered the tooling and a dated change: the Data Mask managed package reaches end of service on 31 December 2026, and Data Mask & Seed is its successor.

And the question comes before the tool: if realistic, made-up data can do the testing, that’s better than masking real data.

The Best Sensitive Data Is Data You Don’t Have

Security teams spend a lot of time protecting data. Architects should also ask why we’re storing it.

Steve Trucking pays damage credits to Retail Partners. Someone proposes a bank account field on the partner account. My first question isn’t which encryption scheme. It’s: why do we need the account number in Salesforce? The payment provider already holds it. Salesforce can hold the provider’s token and the last four digits, and the payment integration can pay against the token. Now there’s no bank account number in the org to leak, export, copy to a sandbox, show on a screen or hand to an agent.

The same thinking applies to a crew member’s medical certificate. Does Salesforce need the document, or only its expiry date and a “verified” flag, with the document in the HR system that already protects it? Data you don’t collect can’t be leaked from your org. Minimization is a security control too, and often the cheapest one.

And for personal data, “why do we even have it?” isn’t only good architecture. It’s what the privacy laws ask. GDPR says personal data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed,” and kept in a form that identifies people “for no longer than is necessary” for those purposes (Article 5(1)(c) and (e), Regulation (EU) 2016/679 (opens in a new tab), checked 2026-10-28). California’s law says the same thing in its own words: a business’s “collection, use, retention, and sharing of a consumer’s personal information shall be reasonably necessary and proportionate” to the purposes it was collected for (California Civil Code section 1798.100(c) (opens in a new tab), as amended by the CPRA, checked 2026-10-28).

So at Steve Trucking, every personal field in the design needs a purpose someone can state. The Recipient’s phone: so the crew can call on arrival, and so the care team can find the delivery. The gate code: so the assigned crew can get in, for that delivery, and no longer, which is why it shouldn’t still be sitting on a Work Order years later. A crew member’s medical certificate: required for the job, but the purpose is met by the expiry date and a verified flag. When the purpose can’t be stated, the field shouldn’t be there; when the purpose ends, the data shouldn’t stay. Chapter 5 covered these laws and what they have in common (Privacy Laws). Here’s where they show up in the protection design: the first protection decision for personal data is whether you’re allowed to keep it at all.

One caution on the bank details: a Retail Partner is a company, so its business bank account isn’t personal data under those laws. Minimizing it is still the right security decision. It just isn’t the law asking.

Test knowledge. Know data minimization and storage limitation as privacy principles: GDPR limits personal data to what’s necessary for its purpose and keeps it identifiable no longer than necessary; the CCPA, as amended by the CPRA, requires collection, use, retention and sharing to be reasonably necessary and proportionate. In a design, they show up as fields you don’t create, copies you don’t make and retention you set at design time.

Applications Get Their Own Column

Module 1 introduced three kinds of consumers: humans, applications and agents. The matrix gives applications their own column because their needs often differ from the people’s.

The payment integration needs the token to pay a damage credit; the care agent doesn’t. That’s not a reason to make the field broadly visible. It’s a reason to give that integration’s own integration user exactly that access, audit it, and keep everyone else out. The reverse is just as true: a human seeing a field doesn’t mean every integration should be able to read it. The partner integration from module 1 runs as Redrock’s own integration user, and it has no business reading crew HR records just because some employees can.

Agents Get a Column, and So Do Prompts

This is the new world, and it needs two columns, not one.

The agents column asks what an agent may retrieve and do. It’s a different question from what the human using it may see. An employee might have a good reason to open one sensitive record on a screen. An agent that can search thousands of records and combine sources in milliseconds has a different risk, even when it runs as that same employee. So my position is job-based agent access: each agent gets only the data and the actions its defined job needs, and human access doesn’t automatically mean the same agent access. Module 4 goes deep on this. Here, the classification is where the policy gets written down.

The AI prompts column asks something new: which data may be sent to a large language model at all. Salesforce’s own guidance is clear about what the Einstein Trust Layer does and doesn’t do. It says the Trust Layer “operates on data in motion during inference” and “doesn’t govern data at rest in Salesforce, access controls on grounding sources.” Zero data retention by the model provider “is a contractual commitment in Salesforce agreements with LLM partners, not a technical control you can verify from your org.” And it says to “determine which data classifications can enter LLM inference for your regulatory context” (Salesforce Well-Architected, Trust for the Agentic Enterprise (opens in a new tab), checked 2026-10-28).

That last sentence is the AI prompts column. Salesforce is telling the architect to decide it, level by level. And on masking, the same page says: “Don’t design agents to send full record context to LLM inference assuming PII masking handles everything … send only fields and data the agent requires.” Chapter 3 noted that Salesforce now turns off prompt masking for agents, because it can strip the context an agent needs. So the design can’t depend on it: send fewer fields, and treat masking as the safety net.

At Steve Trucking, the Recipient’s agent that answers “where’s my delivery?” needs the delivery window and status, which are Public. It doesn’t need the Recipient’s phone to answer, and it must never see the gate code. That’s the agents column and the prompts column, filled in for one agent.

Test knowledge. Know that the Einstein Trust Layer protects data in transit to the model (masking, zero data retention by contract, audit), not data at rest or the access rules on grounding sources; that data minimization, sending only the fields the task needs, comes before masking; and that an agent’s access should follow its job, not simply the maximum access of the user running it.

Protect the Value, or Protect the Capability

Here’s the most useful pattern in this module, and we’ve already used it once. In module 1, only the assigned crew can see the gate code, so we built a controlled door: a component that checks the assignment before it reads the code. The crew never gets field-level access to the gate code. They get the capability to see it for their own delivery.

The same idea works for every consumer. Sometimes a consumer needs the value. Sometimes it only needs an answer derived from the value.

• The payment integration needs the token to pay. That’s the value, to the one consumer that needs it.
• The care agent needs to confirm the partner’s account on file. “Ending in 4471” is enough.
• An agent asked “has this partner’s bank account been verified?” needs a yes or a no. It can call an action, Verify Partner Bank Account, and get verified = true, without ever touching the number.
• The Recipient’s agent asked “will the crew be able to get in?” needs “access instructions are on file,” not the gate code.

“The agent can’t see it” can mean two very different designs: the agent’s identity can’t retrieve the field at all, or the agent can’t retrieve the raw value but can call an approved action that answers the question. The second is often the better boundary, because the agent can still do its job. Instead of “here’s the secret, please use it responsibly,” the design says: here’s the capability you’re allowed to use.

Click to enlarge

Classification Travels With the Data

We classify the gate code Restricted. Then the nightly integration copies delivery data to Redrock’s warehouse. What is the gate code there? Still Restricted. Copied into Data 360 for analytics? Still Restricted. Into a sandbox? Still Restricted, which is why it’s masked. Into a search index an agent uses for grounding? Still Restricted.

The classification belongs to the information, not to the Salesforce field where someone set the picklist. Moving the data doesn’t reset its sensitivity. So every arrow on the integration landscape that carries a Restricted field needs an answer: does it need to carry that field at all, and if so, what protects it at the other end? When the data passes through middleware or another system along the way, encrypt the data itself, not only the connection. A secure channel protects the data while it moves. It doesn’t protect it while it sits in the middle.

Derived Data Can Still Be Sensitive

The last trap is what someone can work out.

Steve Trucking never exposes a Recipient’s home security details. But a delivery history that shows “delivered Tuesdays between 2 and 4 p.m., left at the back door” tells you when nobody is home and where the door is. No single field is Restricted. Together they reveal something that should be.

The same happens with aggregates, with a formula that exposes part of a protected field, with three Internal fields an agent can combine. Agents make this sharper, because combining sources is exactly what they’re good at. So classification can’t stop at “which field has the label.” Ask what the fields reveal together, and classify the combination, the report, the export or the index that brings them together.

Prove It

The policy says what should happen. Testing proves what does. Take the three users from module 2, one who should see the data, one who shouldn’t and the one who set it up, and add the other consumers:

• Can the crew member who isn’t assigned see the gate code? On the page, in a report, in a list view, in global search?
• Can the partner’s integration user retrieve it?
• Does the sandbox have real values after the last refresh?
• Can the Recipient’s agent retrieve it directly? Through a related record? By calling an action that returns more than it should?
• Does the field still work where it must: the license lookup, the duplicate matching, the reports that filter on it?

Trust, but verify. A matrix nobody tests is the same as a label nobody enforces.

What an Architect Decides Here

• How many levels the organization uses, and what each one means in controls, not just in words.
• The protection matrix: for each level, who sees it, encryption, outside production, applications, agents, AI prompts and audit.
• Which fields are encrypted, with which Shield layer, and which scheme, decided by the field’s use, and tested early.
• Where masking or minimization beats protection, including data we decide not to store, and a stated purpose for every personal field, as the privacy laws require.
• Which consumers get the value and which get only a capability, through a controlled action.
• How classification travels with data into integrations, analytics, sandboxes and AI grounding, and what derived data reveals.

Beyond the exam: the agents and AI prompts columns are new, and most organizations haven’t filled them in yet. The architect who brings a matrix with those two columns to the first agent design meeting changes the conversation from “can we turn it on?” to “which data may it use, and for what job?” Module 4 takes that further.

Classification Should Change the Architecture

Classification isn’t documentation we add after the model is built. If something is Restricted, fewer people see it; maybe it moves to its own object; maybe it’s encrypted; it’s masked outside production; maybe it doesn’t go downstream; maybe an integration gets it while people don’t; maybe an agent gets an action instead of the value; and maybe we decide not to store it at all.

So don’t stop at “what classification is this field?” Ask: what are we going to do differently because of it? Classify, then protect.

Explore

• Salesforce, Object Reference: FieldSecurityClassification (opens in a new tab) (the Data Sensitivity Level values), API version 68.0, checked 2026-11-01.
• Salesforce Help: Filter Encrypted Data with Deterministic Encryption (opens in a new tab) and Differences Between FLE and Database Encryption (opens in a new tab), checked 2026-11-01.
• Salesforce Compliance: Salesforce Shield Platform Encryption Architecture (opens in a new tab), no page date, checked 2026-11-01.
• Salesforce Well-Architected: Trust (opens in a new tab), checked 2026-11-01, and Trust for the Agentic Enterprise (opens in a new tab), checked 2026-11-01.
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), Article 5 (data minimisation, storage limitation), and California Civil Code section 1798.100 (opens in a new tab) (CCPA, as amended by the CPRA), checked 2026-11-01.
• Chapter 3, Classify What Matters: the Taxonomy Fields, and chapter 5, Know Your Data and Protect, Retain, Prove: the classification and governance this module builds on.