Privacy Laws Shape the Design
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)
Module 4 of 6 in the chapter Data Quality and Governance, chapter 5 of the Data Architect course. Each module stands on its own. Previous: Know Your Data · Next: Consent and the Right to Be Forgotten
The question this module answers: What do privacy and industry regulations ask of a Salesforce design?
When I worked in Australia, I met plenty of aspiring architects who’d never heard of GDPR. Europeans often haven’t heard of California’s privacy law, or Canada’s, or Brazil’s. That’s natural: you know the rules where you work. But these laws reach across borders, and they shape system design even though none of them is about Salesforce. So they belong in a data architecture course.
You don’t need to become an attorney. You do need to see that a regulation can change where data is stored, what you collect, who sees it, why you may use it, how long you keep it, where you send it, whether you can delete it, what history you keep, and what you can prove later. Those aren’t only legal questions. They’re data architecture questions.
This module is architecture guidance, not legal advice. Legal and compliance teams decide which laws apply and what they require. The architect turns those requirements into enforceable design.
Laws Don’t Stop at the Border
Section titled “Laws Don’t Stop at the Border”The biggest misconception first: “we’re not in Europe, so GDPR doesn’t apply.” Maybe, maybe not. GDPR’s territorial scope reaches organizations outside the EU that offer goods or services to people in the EU, or monitor their behavior there (Article 3, Regulation (EU) 2016/679 (opens in a new tab)). So where your company is headquartered isn’t the end of the question. Where are your customers, employees, the people whose data you hold, your systems, your processors? Where does the data travel? That’s chapter 4’s landscape again. You can’t make good privacy decisions without knowing where the data goes.
The Regulations You Should Recognize
Section titled “The Regulations You Should Recognize”Here are the names an architect should know, with what each covers. It’s a recognition table, not an applicability matrix: don’t read it and decide “we have customers in California, so requirement X applies.” That’s Legal’s call. Your job is to know enough to ask the question before the system is built.
| Law or standard | Where or what | Why an architect should recognize it |
|---|---|---|
| GDPR (opens in a new tab) | European Union | Personal data, lawful processing, individual rights, retention, transfers, privacy by design |
| CCPA, as amended by the CPRA (opens in a new tab) | California | Consumers’ rights over the personal information businesses collect about them |
| PIPEDA (opens in a new tab) | Canada | How private-sector organizations handle personal information |
| LGPD (opens in a new tab) | Brazil | Brazil’s general personal-data protection law |
| Privacy Act 1988 (opens in a new tab) | Australia | How organizations handle personal information, under the Australian Privacy Principles |
| HIPAA (opens in a new tab) | US healthcare | Protected health information in covered contexts |
| PCI DSS (opens in a new tab) | Payment cards | Protecting payment-card account data |
| Sarbanes-Oxley (SOX) (opens in a new tab) | US public companies | Controls and evidence behind financial reporting |
| COPPA (opens in a new tab) | US, children online | Personal information collected online from children |
The list grows (more US states have their own laws), and the laws change. That’s why I don’t want you memorizing a table and thinking you’ve learned privacy architecture. Learn the names, then learn the questions that survive them.
What the Laws Have in Common
Section titled “What the Laws Have in Common”The details differ, but the big privacy laws keep coming back to the same few things, and each one lands on the architecture.
Rights. People can ask to see their data, correct it, delete it and take it with them; under California’s and Brazil’s laws they can also opt out of having it sold. Every one of those requests means finding the person’s data, all of it.
Transfers. GDPR and LGPD control personal data leaving their jurisdiction and ask for adequate protection where it goes; PIPEDA expects the same level of protection when a third party processes the data, wherever it is. That’s the landscape again: which arrows cross a border?
Breach notification. When personal data is exposed, the laws expect you to tell the authorities, and sometimes the people affected, within a deadline that varies by law. You can’t notify about data you didn’t know you had, or say what was exposed if you can’t find the copies.
Accountability. You have to be able to show compliance: records of what you process and why, impact assessments for high-risk processing, and, under GDPR and LGPD, a data protection officer. The architecture has to produce the records.
Start With What’s Personal
Section titled “Start With What’s Personal”Before protecting personal information, find it. Some is obvious: name, home address, phone, email. Some isn’t: location, device identifiers, IP addresses, images, behavioral data, anything that can be linked back to a person. And context matters. A Steve Trucking delivery carries the Recipient’s name, address, phone number, delivery notes and photos. A photo might show a box on a porch, or a person, or the inside of a home. The delivery is operational data, but some of its attributes are personal. That’s why module 3 classified fields: privacy starts with knowing what you hold.
Where Does It Live?
Section titled “Where Does It Live?”“Salesforce.” Probably not just Salesforce. Did it come from a Retail Partner? Was it copied to Snowflake, ingested by Data 360, written to an integration log, exported by a user, left in field history, archived, copied into a sandbox, passed to a partner, used in an agent’s conversation? Personal data spreads. So when Legal asks “where do we hold this person’s information?”, “we know where the current value is” isn’t an answer. I want the landscape and the lineage: where the copies went.
One phone number, many copies. Privacy applies to the copies too.
Why Are You Allowed to Use It?
Section titled “Why Are You Allowed to Use It?”Having data and being allowed to use it aren’t the same thing. Steve Trucking has a Recipient’s phone number to coordinate today’s delivery. Does that make it a marketing list? No. The legal basis depends on the jurisdiction and the situation, and Legal guides that, but the architecture has to carry the answer: why it was collected, what use was authorized, whether consent was needed, given, withdrawn, and for which channel, address and purpose. Permission to use data has to be representable as data, because a policy document can’t make a decision at runtime. The next module models it.
Collecting Less Is an Architecture Decision
Section titled “Collecting Less Is an Architecture Decision”One of the strongest privacy controls is not collecting the data, or not copying it where it isn’t needed. Does Snowflake need the Recipient’s phone number? Does analytics need the full street address? Does the sandbox need real delivery photos? Does an agent need the Recipient’s personal details to answer this question? If not, the strongest control may be not putting it there. Every copy you don’t make is one you don’t have to secure, retain, delete, track consent for, audit or report in a breach. The cheapest sensitive data to govern is the data you never copied.
Retention Is Part of the Model
Section titled “Retention Is Part of the Model”“We’ll keep everything for now” is a retention policy. It’s just a bad one. For important data I want to know at design time how long we need it and why; whether a regulation sets a minimum or another sets a maximum; when the clock starts; and what happens at the end: delete, archive, de-identify, and where are the copies? Financial records may have to stay for a set period. A Recipient’s gate code has no purpose years after the delivery. Those decisions don’t wait until the database is big.
Anonymized, Pseudonymized, Encrypted, Masked
Section titled “Anonymized, Pseudonymized, Encrypted, Masked”Replace “Jane Smith” with 7F92A1. Is Jane anonymized? Not if another table still says 7F92A1 = Jane Smith. That’s pseudonymization: the direct identifier is replaced, but the data can be re-linked using information kept separately, and under GDPR pseudonymized data is still personal data (Article 4(5)). Anonymization goes further: the data can no longer reasonably be linked to the person (Recital 26). So when someone says “we don’t need to delete it, we’ll just remove the name,” be careful. If the person can still reasonably be identified, you haven’t crossed that line. Whether a result satisfies the law is Legal’s call; the architect’s job is to say exactly what the system does: can it be re-linked, what keys remain, where are the mappings?
Use the words precisely, because they solve different problems. Encryption protects data from unauthorized disclosure; an authorized user can still decrypt it. Masking changes what particular users or environments see. Pseudonymization separates direct identity while keeping a way back. Anonymization removes the reasonable ability to identify the person. Only the last one takes data out of “personal.”
Regulation Becomes Requirements
Section titled “Regulation Becomes Requirements”Legal doesn’t need to tell me to create a permission set; that’s my side of the line. Legal might say “only employees with a legitimate business need may access this category of personal information.” Then I translate: who are they, how do we identify the category, how is access granted, what happens when someone changes jobs, can an integration read it, can an agent, can it be exported, and how do we prove who saw it? Owners set policy; architects enforce it. Legal and compliance establish the obligation, data owners set the business policy, and the architect designs the enforcement.
From regulation to evidence: Legal interprets, the owner sets policy, the architect makes it work and provable.
And compliance isn’t a product. You can’t buy “compliance: on.” Encryption can support a requirement, audit features provide evidence, retention tooling executes policy, consent data supports permitted use, but licensing a feature doesn’t make an architecture compliant. Compliance comes from the whole design: people, policy, process, data, controls and evidence. Salesforce is part of it, not all of it. And if a policy matters enough to enforce, ask whether it matters enough to prove: who accessed this record on March 17, who changed this field, what did that export contain? Module 6 covers the evidence.
Privacy Changes the Landscape
Section titled “Privacy Changes the Landscape”At Steve Trucking, the Recipient’s personal data arrives through three partner integrations. Salesforce needs it to run deliveries; crews need some of it, only for their own stops, only on the day; Snowflake wants delivery analytics; finance needs enough to bill, but not what the crew sees. And one Retail Partner must never see another’s Recipients. Privacy changes the arrows: certain fields don’t go to Snowflake, analytics gets a less identifiable version, crews see just their stops, downstream retention differs from operational retention. The privacy requirement doesn’t sit beside the landscape diagram. It changes it.
Questions That Outlive the Regulations
Section titled “Questions That Outlive the Regulations”Regulations change, so carry a durable set of questions for any sensitive or regulated data:
- What is it? Personal, sensitive, financial, health, payment, children’s or otherwise regulated?
- Where does it live? Every copy: integrations, history, analytics, archives, sandboxes, logs, AI use.
- Why may we use it? What purpose and legal basis apply? Is consent involved?
- Who may use it? People, systems, partners, integrations, agents.
- How long do we keep it, and what happens at the end?
- Can the person exercise their rights over it? Access, correction, deletion, portability, objection, as the law provides.
- Can we prove what happened? Access, changes, exports, consent, deletion, retention.
AI Governance Is Becoming Law
Section titled “AI Governance Is Becoming Law”AI adds another consumer of governed data. Can an AI system use this data, for what purpose, as grounding, combined with what, repeated in its output, logged where, for how long? Governance of AI is moving from company policy into law: the European Union’s AI Act (Regulation (EU) 2024/1689 (opens in a new tab)) is the first broad example. What it requires depends on the system and the use. The direction for architects is clear: AI doesn’t sit outside governance; it’s another consumer of governed data.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Where regulated or sensitive data enters, lives, moves and gets copied across the landscape.
- How legal and compliance policy becomes enforceable requirements, without the architect interpreting the law.
- Whether each system that receives sensitive data needs it, or a less identifiable version would do.
- How retention, deletion, anonymization, pseudonymization, protection and evidence shape the data’s lifecycle.
- What evidence must exist to show the important controls actually worked.
Regulations don’t become architecture by putting their names on a slide. They become architecture when they change how data is collected, classified, moved, protected, retained, deleted and proven.
Explore
Section titled “Explore”- The regulations’ official sources are linked in the table above, checked 2026-10-14.
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab): Article 3 (territorial scope), Article 4(5) (pseudonymization), Recital 26 (anonymous information).
- Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab), EUR-Lex.