Episode 31 · Module 7 · Data Protection

PII Handling and Anonymisation

19 May 2026 · 8:16 · Security for Legal SaaS

8:16 8:16

Most SaaS platforms handle personally identifiable information (PII) — names, email addresses, phone numbers. Legal SaaS platforms handle PII that is often simultaneously legally privileged. A client's name attached to a litigation strategy memo. A witness's home address in a deposition transcript. Financial records produced in discovery. This is not just personal data under privacy regulations — it is data protected by attorney-client privilege, work product doctrine, or court-ordered confidentiality.

Today’s Lesson

Security for Legal SaaS — Episode 31: PII Handling and Anonymisation

Personal Data in Legal Tech Is Double-Sensitive

Most SaaS platforms handle personally identifiable information (PII) — names, email addresses, phone numbers. Legal SaaS platforms handle PII that is often simultaneously legally privileged. A client's name attached to a litigation strategy memo. A witness's home address in a deposition transcript. Financial records produced in discovery. This is not just personal data under privacy regulations — it is data protected by attorney-client privilege, work product doctrine, or court-ordered confidentiality.

The sensitivity is compounded, and so is the obligation. Get PII handling wrong in a generic SaaS product and you face regulatory fines. Get it wrong in legal SaaS and you face regulatory fines, malpractice liability, and potential waiver of privilege.

What Counts as PII in Legal Tech

PII is any information that can identify a specific individual, either directly or in combination with other data. In the legal technology context, the scope is broader than most developers expect:

Category	Examples	Why It Matters in Legal Tech
Direct identifiers	Full name, SSN, passport number, email address	Present in virtually every legal document
Case metadata	Case numbers, court filing dates, docket entries	Combined with public records, can identify parties
Financial records	Bank statements, tax returns, billing records	Common in discovery; regulated by multiple frameworks
Health information	Medical records, insurance claims	Subject to HIPAA in the US; frequent in personal injury and employment cases
Communications metadata	Email timestamps, call logs, IP addresses	Can reveal attorney-client relationships even without content
Biometric data	Voice recordings (depositions), facial images	Increasingly regulated; used in remote hearings

Key principle: In legal SaaS, always assume data is PII unless proven otherwise. A document number that seems anonymous can become identifying when cross-referenced with a public court docket.¹

Data Minimisation: Collect Less, Protect Less

The first line of defence is not a technical control — it is restraint. GDPR Article 5(1)(c) codifies data minimisation: personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."²

For legal SaaS, this means:

Collect only what your feature requires. If your document review tool needs to classify documents by type, it does not need to index the full text of every exhibit.
Retain only as long as necessary. Define retention periods per data category. Case data may need to be retained for the statute of limitations period. Audit logs may have a different retention schedule. Activity analytics should expire after months, not years.
Delete completely when the period expires. This means database records, search indices, backups, caches, log files, and — as we discussed in Episode 29 — crypto-shredding of encrypted data by destroying its encryption keys.

Pseudonymisation vs. Anonymisation: The Difference Matters

These two terms are frequently confused, and the distinction has direct legal consequences under GDPR:³

Property	Pseudonymisation	Anonymisation
Definition	Replace identifiers with artificial tokens; the mapping exists somewhere	Remove or transform identifiers so that re-identification is impossible
Reversible?	Yes — with the mapping key	No — by definition, irreversible
Still personal data under GDPR?	Yes — GDPR still applies in full	No — falls outside GDPR scope entirely
Example	Replace "Jane Smith" with "Client-7A3F" in a case file; store the mapping in a separate secure system	Aggregate case outcomes into statistics with no individual-level records

Pseudonymisation is a security measure, not a de-identification technique. GDPR Article 4(5) defines it as processing personal data so it "can no longer be attributed to a specific data subject without the use of additional information," provided that additional information is kept separately with appropriate technical controls.⁴

Anonymisation removes the data from GDPR scope entirely — but the bar is high. The Article 29 Working Party (now the EDPB) requires that re-identification must be impossible considering "all the means reasonably likely to be used" — including cross-referencing with other datasets, future technological advances, and publicly available information.⁵

The misclassification trap: Research consistently shows that organisations confuse pseudonymisation with anonymisation. If your legal SaaS platform pseudonymises client data (replacing names with tokens) but still stores the mapping, that data is personal data under GDPR. Treating it as anonymous — for example, sharing it with analytics vendors or using it for model training without consent — is a compliance violation.⁶

Tokenisation for Search: Maintaining Functionality

A practical challenge in legal SaaS is maintaining search functionality without exposing raw PII. If a lawyer needs to search for "all documents mentioning Jane Smith," but Jane Smith's name has been pseudonymised to "Client-7A3F" in the search index, how does the search work?

Tokenisation addresses this. The application:

Tokenises PII at ingestion (replacing "Jane Smith" with a deterministic token derived from a keyed hash).
Stores the token in the search index alongside non-PII metadata.
At search time, applies the same tokenisation function to the search query, so the lawyer searching for "Jane Smith" generates the same token and matches the indexed records.
The display layer de-tokenises for authorised users, showing the original name.

The search index never contains raw PII. The tokenisation key is managed through the key management infrastructure covered in Episode 29. If the tokenisation key is destroyed, the search index becomes permanently unlinkable — another form of crypto-shredding.⁷

Data Subject Access Requests: The Technical Architecture

Under GDPR, individuals have the right to request access to their personal data (Article 15), correction (Article 16), and deletion (Article 17). For legal SaaS platforms, this means you need a technical architecture that can:⁸

Discover all PII for a given individual across all systems (database, search index, backups, logs, third-party integrations).
Export that data in a portable format (Article 20 — data portability).
Delete it completely, or document why deletion is legally excluded (e.g., legal hold, regulatory retention requirement).
Respond within 30 days (extendable to 90 for complex requests).

This requires a PII inventory — a mapping of every data store that contains personal data, what PII fields it holds, and how to query it for a specific individual. Without this inventory, DSAR fulfilment becomes a manual, error-prone scramble across dozens of systems.

Legal Holds and the Deletion Tension

Legal SaaS faces a unique tension: data protection law says "delete personal data when no longer needed," but litigation holds say "preserve everything potentially relevant to pending or anticipated litigation." These obligations can conflict directly.

The resolution is documented exception handling:

Legal holds override deletion timelines for data within the hold's scope.
Hold metadata (which case, which custodian, which date range) must be tracked so that once the hold is released, deletion resumes.
Privilege logs documenting why specific data was retained satisfy both the data protection authority and the court.

Real-World PII Failures in Legal Technology

Incident	What Went Wrong	Impact
Orrick, Herrington & Sutcliffe (2023)	Attackers accessed personal data — names, SSNs, financial data, health information — of over 600,000 individuals stored in the firm's systems	$8 million class action settlement; reputational damage⁹
Latitude Financial (2023)	Retained driver's licence numbers and passport data years beyond any legitimate business need; attackers exfiltrated 14 million records	Demonstrated that data minimisation failures multiply breach impact; retained PII that should have been deleted years earlier
Clearview AI (multiple, 2020-2024)	Scraped billions of facial images from public sources for biometric identification; regulators in multiple jurisdictions found GDPR violations	Fines exceeding EUR 20 million; demonstrated that "publicly available" does not mean "lawfully processable"

For legal SaaS developers, the Orrick breach illustrates a pattern: the firm stored PII from individuals who were not even clients — they were individuals whose data was held because Orrick served as legal counsel to other companies that had been breached. The firm became a secondary target because it accumulated PII through its advisory role. Data minimisation — deleting data as soon as the advisory engagement ends — would have limited the exposure.

The privilege multiplier: When PII in a legal SaaS system is also covered by attorney-client privilege, a breach creates a dual harm: the privacy violation under data protection law AND potential waiver of privilege. Courts have held that failure to maintain reasonable security for privileged communications can constitute waiver. The PII breach becomes a privilege breach.¹⁰

What's Next

Episode 32 covers Database Security Hardening — protecting the system where all this PII ultimately lives, from network isolation to audit logging to backup encryption.

Sources & Further Reading

Sources & references

GDPR Local, Data Pseudonymisation vs Anonymisation: Key Differences.
GDPR, Article 5(1)(c) — Principles Relating to Processing of Personal Data.
MOSTLY AI, Pseudonymization vs Anonymization: Ensure GDPR Compliance.
GDPR, Article 4(5) — Definition of Pseudonymisation.
ENISA, Pseudonymisation Techniques and Best Practices.
Privacy Company, What Are the Differences Between Anonymisation and Pseudonymisation.
Protecto AI, Pseudonymization vs Anonymization: Key Differences, Examples & GDPR Guide.
GDPR, Article 15 — Right of Access by the Data Subject.
GDPR Register, Is Pseudonymised Data Personal Data? 2025 Guide.
Xata, Data Pseudonymization Explained: When Anonymization Isn't Enough.
Piwik PRO, The Most Important Benefits of Data Pseudonymization and Anonymization Under GDPR.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 31 — PII handling and anonymisation. Alice, personal data protection is a huge topic. What makes it different for legal tech specifically?

Alice: The double sensitivity problem. Most SaaS platforms handle personally identifiable information — names, emails, phone numbers. Legal SaaS handles PII that is often simultaneously legally privileged. A client's name attached to a litigation strategy memo. A witness's address in a deposition transcript. Financial records produced during discovery. This isn't just personal data under privacy regulations — it's data protected by attorney-client privilege or work product doctrine. Get PII handling wrong in a regular SaaS product and you face regulatory fines. Get it wrong in legal SaaS and you face fines, malpractice claims, and potential waiver of privilege.

Dan: That's a much higher stakes version of the same problem. So let's start with the basics — what actually counts as PII in a legal tech context?

Alice: More than people expect. The obvious ones — full names, Social Security numbers, passport numbers, email addresses — those are in virtually every legal document. But in legal tech, you also have case numbers and filing dates that seem anonymous until you cross-reference them with a public court docket. You have communications metadata — email timestamps, call logs, IP addresses — that can reveal attorney-client relationships even without showing the content. And increasingly, you have biometric data from remote depositions and hearings. The safe assumption in legal SaaS is: treat everything as PII unless you can prove otherwise.

Dan: So what's the first principle for handling all of this?

Alice: Collect less. It sounds simple, but it's the most powerful protection. The GDPR calls it data minimisation — Article 5(1)(c) says personal data must be limited to what is necessary for the purpose you're processing it. For a legal SaaS developer, that means: if your document review tool only needs to classify documents by type, don't index the full text of every exhibit. If your analytics feature works on aggregate numbers, don't store individual-level records. Every field of PII you don't collect is a field that can't leak.

Dan: Yeah. The data you don't have can't be stolen. Now, I keep hearing pseudonymisation and anonymisation used interchangeably. Are they the same thing?

Alice: They are absolutely not, and confusing them is one of the most common compliance mistakes in the industry. Let me use a legal analogy. Pseudonymisation is like redacting a name in a court filing but keeping the unredacted version in a sealed envelope held by the court. The name is hidden, but it can be recovered. Anonymisation is like shredding the original document so thoroughly that no one — not the court, not forensic experts — can reconstruct the name. Ever.

Dan: Mm-hmm. And that distinction matters legally?

Alice: It matters enormously. Pseudonymised data is still personal data under GDPR. All the obligations still apply — consent, data subject access requests, breach notification, everything. Because the mapping exists somewhere, the data can theoretically be linked back to the individual. Anonymised data, on the other hand, falls entirely outside the GDPR's scope. But the bar for true anonymisation is extremely high. The European regulators say re-identification must be impossible considering all means reasonably likely to be used — including future technology and cross-referencing with other datasets.

Dan: Hmm. So a lot of what people call "anonymised" is probably just pseudonymised?

Alice: <sigh> Exactly. If you replace "Jane Smith" with "Client-7A3F" in your database but store the mapping between the name and the token — that's pseudonymisation. The data is still personal data. If you then share that pseudonymised data with an analytics vendor or use it to train an AI model without consent, thinking it's "anonymous," you've violated the GDPR. This misclassification happens constantly, and regulators are increasingly aware of it.

Dan: Right. So for the legal SaaS developer who does need to pseudonymise — say, for search functionality — how does that work technically?

Alice: Good practical question. You need your lawyers to search for "all documents mentioning Jane Smith," but you don't want raw PII sitting in your search index. The solution is tokenisation. When a document is ingested, you pass the PII through a keyed hash function — the same function every time, using a key managed through the key management system we covered in Episode 29. "Jane Smith" always becomes the same token, say "7a3f9b2c." You store that token in the search index. When the lawyer searches for "Jane Smith," the application applies the same hash, generates the same token, and matches the indexed records. The display layer then shows the original name to authorised users. The search index itself never contains raw PII.

Dan: Mm. That's a clever pattern. What about when someone exercises their right to access or delete their data — the DSAR requests?

Alice: Data Subject Access Requests are a technical architecture problem, not just a legal one. Under GDPR, an individual can request access to all their personal data, request corrections, or request deletion — and you have thirty days to respond. For a legal SaaS platform, that means you need to be able to discover all PII for a given individual across every system — your production database, search indices, backups, log files, analytics stores, and any third-party integrations. You need to export it in a portable format. And you need to delete it completely or document why you legally can't — for example, because of an active litigation hold.

Dan: Yeah, that's where things get complicated. Litigation holds and data protection can pull in opposite directions.

Alice: Exactly. Data protection law says "delete when no longer needed." A litigation hold says "preserve everything potentially relevant." When these conflict, the hold wins — but you need to document it. Track which case imposed the hold, which data it covers, and which custodians are affected. Once the hold is released, deletion resumes. And you maintain a privilege log explaining why specific data was retained. That satisfies both the data protection authority and the court.

Dan: Mm. What's the practical minimum for a legal SaaS team that's building this from scratch?

Alice: Three things. First, a PII inventory — a mapping of every data store that contains personal data, what fields it holds, and how to query it for a specific individual. Without this, DSAR fulfilment is a panicked scramble. Second, defined retention periods per data category — case data, audit logs, analytics, and temporary processing data should all have different lifespans. Third, crypto-shredding capability tied to your key management architecture — when it's time to delete, destroy the encryption key and the data becomes mathematically unrecoverable.

Dan: Next episode — Database Security Hardening. The system where all this PII actually lives, and how to lock it down properly.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.