The Polish PII Redaction Checklist (PESEL, NIP, REGON, KRS)
5 min read
Redacting Polish documents is harder than deleting a name, because Polish identifiers encode personal data in their digits and Polish names change spelling across grammatical cases. This checklist gives you a repeatable mask-and-verify routine — what to look for, how to mask it, and how to confirm nothing was missed — so a document is genuinely anonymized under the GDPR rather than just visually tidy.
TL;DR — the checklist in one screen
- Mask the four Polish identifiers in full: PESEL, NIP, REGON, KRS — including every formatting variant (spaces, dashes, no separators).
- Mask the quasi-identifiers too: name, date of birth, address, postcode, job title. A PESEL already encodes date of birth and sex, so leaving a separate date of birth defeats the point.
- Catch inflected names: Kowalski / Kowalskiego / Kowalskiemu / Kowalskim are the same person — a literal find-and-replace on one form leaves the others.
- Check metadata and headers/footers, not just the body text.
- Verify before you share: re-scan, spot-check the remaining fields, and ask “could these leftover details single out one person?”
- Decide reversibility on purpose: a permanent token (anonymization) or a token backed by a separately stored key (pseudonymization — still personal data).
📄 Download the one-page version: Polish PII Redaction Checklist (PDF) — print it, pin it next to your screen, run it before every export.
Step 1 — Identify what counts as personal data
Before masking, know what you are hunting for. In a typical Polish business document the personal data hides in more places than the obvious name field:
| Where it hides | Examples |
|---|---|
| Direct identifiers | Full name, PESEL, sole-trader NIP, email, phone |
| Structural identifiers | PESEL digits (date of birth + sex), REGON territorial code |
| Quasi-identifiers | Date of birth, postcode, town, job title, employer |
| Free text | Names inside sentences, signatures, “in re:” case captions |
| Non-body content | File metadata, document properties, headers, footers, tracked changes |
The Polish DPA (UODO) is explicit that anonymization does not end at covering a name: if any single unique identifier or identifying combination remains, the document is not anonymized.
Step 2 — Mask the four Polish identifiers (in full)
Each identifier needs the whole value masked, in every format it appears:
- PESEL →
[PESEL]. All 11 digits — the first six are the date of birth, so never leave them “because they’re just a date.” - NIP →
[NIP]. A sole trader’s NIP is personal data; mask it and re-check the name and address next to it. Formats:5213051000,521-30-51-000,521 305 10 00. - REGON →
[REGON]. 9 or 14 digits — a find-and-replace tuned to one length misses the other. - KRS →
[KRS]. Mask it and watch for board-member and partner names in the same entry.
Amaze detects all four out of the box, across formatting variants, and masks them with consistent tokens (same value → same label) — locally, on your own machine.
Step 3 — Catch inflected Polish names
This is where naive redaction quietly fails. Polish nouns and surnames decline across seven grammatical cases, so one person appears under several spellings:
| Case | Example |
|---|---|
| Nominative | Anna Kowalska |
| Genitive | Anny Kowalskiej |
| Dative | Annie Kowalskiej |
| Accusative | Annę Kowalską |
| Instrumental | Anną Kowalską |
A find-and-replace on “Kowalska” leaves “Kowalskiej” and “Kowalską” untouched — the document still names the person. Amaze recognizes Polish names across grammatical cases, so the inflected forms are masked too, not just the dictionary form.
Step 4 — Sweep the non-obvious places
- Metadata / document properties — author, company, last-saved-by.
- Headers, footers, and signature blocks — often skipped by a body-only pass.
- Tables and payloads — a column of PESELs or a JSON field is still personal data.
- Scanned pages — text baked into an image needs OCR before it can be masked. Amaze runs local OCR so scanned PDFs are handled like regular text, fully offline.
Step 5 — Verify before you share
Masking is not done until you have checked it:
- Re-scan the whole document, not just the part you edited.
- Read the leftovers out loud: name gone, but is there a case number, employer, and town that together point to one person? That is the re-identification problem.
- Confirm tokens are consistent — the same original should map to the same token everywhere.
- Check the format variants you might have missed (dashes vs spaces, 9- vs 14-digit REGON).
Step 6 — Decide reversibility on purpose
- Anonymization (GDPR Recital 26): permanent token, no key. If the rest of the record can’t identify anyone either, the data falls outside the GDPR.
- Pseudonymization (GDPR Art. 4(5)): token backed by a separately stored key. Still personal data, still fully in scope.
As long as a key exists anywhere that can rebuild the PESEL or NIP, it is pseudonymization — even if the document now shows only [PESEL]. Amaze makes anonymization reversible with a private mapping key when you need the originals back, and lets you go key-free when you don’t. The distinction is broken down in anonymization vs pseudonymization.
FAQ
Why isn’t find-and-replace enough for Polish data? Two reasons: Polish identifiers encode personal data in their digits (a PESEL reveals date of birth and sex), and Polish names change spelling across grammatical cases, so replacing one form leaves the others in place.
Do I have to mask a company’s NIP or KRS? Not for the legal entity itself — the GDPR doesn’t protect legal persons. But a sole trader’s NIP is personal data, and a KRS entry lists board members and partners who are natural persons, so mask defensively in mixed documents.
Is replacing a PESEL with a token anonymization? Only if no key exists to reconstruct it and the rest of the record can’t identify the person. If a mapping key is stored anywhere, it’s pseudonymization and the data stays subject to the GDPR.
Where do people most often miss data? Inflected name forms, document metadata, headers/footers, and quasi-identifiers (date of birth, postcode, employer) left behind after the name is removed.
Part of our complete guide to data anonymization.