Privacy stopped being a legal footnote the day regulators started attaching real numbers to it. So now every team touching personal data needs the working vocabulary.
This category covers the protective techniques and the legal definitions they serve. Term by term 👇
30-Second Summary
Data protection and privacy terms cover how personal information gets shielded: masking data for safe use, pseudonymizing it to reduce risk, and understanding what counts as personal information under laws like the CCPA.
What This Category Covers
- The techniques: data masking and pseudonymization
- The legal definitions: PII under CCPA
📌 Quick take: Privacy techniques are risk dials, not on/off switches. Masking, pseudonymization, and anonymization each trade off utility against protection differently, and the law cares which one you picked.
The Terms in This Category, Walked Through
Data masking covers the substitution toolbox. Substitution, shuffling, format-preserving encryption, variance, generalization. It also covers the consistency requirement that separates production masking from find-and-replace scripts: deterministic transforms that keep joins and dedupe intact across systems and time. And there’s a rollout sequence (discover, mask riskiest environments first, validate downstream, then enforce) plus program metrics. These techniques appear everywhere from test environments to live per-role views.
Pseudonymization occupies the deliberate middle ground. Identities hide behind artificial identifiers, while a separately guarded key preserves authorized re-identification. The page builds the three-component architecture: dataset, key, governance wrapper. It threat-models the paths back that don’t need the key: quasi-identifiers, linkage, behavioral fingerprints. And it explains the specific legal position: still personal data under GDPR, yet explicitly encouraged as a safeguard.
One pattern there is worth stealing. Pseudonymize at ingestion, re-identify through one governed doorway. It’s the folder’s most reusable design.
And PII under CCPA is the legal definition that resets intuitions. Personal information means anything reasonably linkable to a consumer or household. Inferences and browsing behavior included. The page walks the consumer rights and the machinery each secretly demands, because finding every record for a person is a data-architecture capability wearing a statute. It also covers day-to-day compliance operations, and the B2B reality since the exemptions sunset: business contacts are consumers now, with everything that implies for prospecting databases.
How the Three Compose
The techniques serve the law. And the law shapes the techniques. CCPA-family statutes define what counts as personal information and what rights attach. Masking and pseudonymization are the engineering answers, ways to hold such data at reduced risk while keeping it useful.
The chain runs like this. Classify what you hold (the legal page’s definitions). Choose the technique per purpose (the decision checklist on the pseudonymization page). Then implement with the consistency and separation disciplines the masking page details. Skip any link and the others weaken. A masked dataset with unexamined quasi-identifiers, or a compliant policy atop unprotected copies, is protection in costume.
Here’s the folder’s shared premise: privacy engineering is an enabler, not a wall. Done well, it converts “we can’t use that data” into “here’s the safe version.” That unblocks analytics, testing, and partnerships that raw sensitivity would forbid. It makes the compliance story an architectural fact rather than an aspiration. The access disciplines next door supply the enforcement. This folder supplies what gets enforced.
Using This Folder
Facing a specific decision? Enter by question. “Developers need realistic data” → masking. “Analysts need personal data patterns” → pseudonymization. “What do we legally hold and owe” → the CCPA page.
Building a program? Read them in reverse. Law first, then the middle ground, then the toolbox. So the techniques land already attached to their purposes. Either path ends at the same standing habit: an inventory of personal data, a documented technique per use, and a quarterly look at whether both are still true.
Questions This Category Answers
“Can developers use production-like data safely?” Yes, through masking. Realistic substitutes with deterministic consistency, rolled out riskiest-environments-first, measured by coverage and leak scans.
“Can analysts work with personal data without seeing identities?” That’s pseudonymization‘s exact design. Pseudonyms at ingestion, analysis at full utility, and one governed doorway back to identity for authorized action.
“What counts as personal information anyway?” The CCPA page’s answer resets intuitions. Anything reasonably linkable to a person or household. Behavior, inferences, and B2B contacts included since the exemptions sunset.
“Are we actually compliant, or just careful?” The folder’s chain makes it checkable. Classified inventory → technique chosen per purpose → implemented with separation and consistency → auditable. Each link has a page. A missing link has a name.
“Does privacy work slow everything down?” Run well, the opposite. Safe versions of sensitive data unblock testing, analytics, and partnerships that raw sensitivity would forbid. Privacy engineering as the department of yes-safely.
And the closing frame for the folder: the techniques are risk dials, the law defines the dial settings, and the audit trail proves where they were set. Turn them deliberately and write it down. That sentence is most of privacy engineering.
How This Category Connects to the Rest of the Wiki
Privacy work threads through the entire estate. The test data discipline is this folder’s masking applied to engineering. The analytics folder‘s work increasingly runs on this folder’s pseudonymized flows. Model training inherits every obligation attached to its personal-data inputs, inferences included. And the CRM and platform pages hold most of what these techniques exist to protect.
The enforcement half lives next door in Security & Compliance, where access control and audit make the techniques real. Meanwhile, the legal definitions here reach back into every folder that touches a person. What counts as personal information decides what the pipelines may carry, what the analysts may see, and what the enrichment flows may resurrect after a deletion request.
One forward-looking note to close the folder. Privacy expectations only ratchet one direction. Every jurisdiction that legislates copies the broad definitions, and every enforcement action reads yesterday’s normal as today’s violation. Estates designed to this folder’s disciplines (inventoried, technique-per-purpose, provable) treat each new statute as configuration. Estates that deferred treat each one as a crisis. And the choice between those futures is made now, in architecture. That’s why these three pages earn their place beside the technical ones.
Start Here If You’re New
New to this? Begin with the CCPA page. Knowing what legally counts as personal information reframes everything else. Then masking, the most hands-on technique. Then pseudonymization, the middle ground whose design pattern rewards study. Implementing this week instead? Invert it: technique pages first, law page before anything ships.
A scope note. This folder covers the technique-and-definition layer. The enforcement machinery lives in Security & Compliance, and the GDPR-specific habits for enrichment workflows live on the blog’s compliance guides. Each page here links outward wherever those deeper dives exist.
And the folder’s parting principle: privacy done early is architecture; privacy done late is remediation. Same requirements, an order of magnitude apart in cost. The choice of which one you’re doing? Made the day the first personal record enters the system.
Frequently Asked Questions
What is data protection?
Data protection is the set of techniques and legal duties that shield personal information from misuse while keeping it usable. The techniques include masking, pseudonymization, and access control. And the duties come from laws like the CCPA and GDPR that define what counts as personal data and what rights attach.
What’s the difference between data masking and pseudonymization?
Masking replaces sensitive values with realistic substitutes and is usually irreversible; pseudonymization swaps identities for artificial identifiers with a guarded key that allows authorized re-identification. Masking suits test environments and per-role views. Pseudonymization suits analytics that may later need a governed path back to the person.
Is pseudonymized data still personal data?
Yes. Under GDPR, pseudonymized data remains personal data because re-identification is still possible. The law encourages it anyway, as a recognized safeguard that reduces risk. Full anonymization is the only exit from the personal-data category, and it’s harder to achieve than most teams assume.
What counts as PII under the CCPA?
Anything reasonably linkable to a consumer or household, including browsing behavior, inferences, and, since the exemptions sunset, B2B business contacts. That definition is far broader than name-and-SSN intuitions. It pulls prospecting databases and analytics profiles squarely into scope.