ÚOOÚ and Rodné Číslo: Gender Encoding Under GDPR
Updated for 2026
The Czech data body is ÚOOÚ. In full: Úřad pro ochranu osobních údajů. It issued 58 rulings in 2024. One finding appears across many cases. The rodné číslo (birth number) was processed without detection. The PII tool used was built for German or English. It had no logic for this identifier. ÚOOÚ is clear: tools must detect the rodné číslo with checksum validation and correct gender-offset handling.
Rodné Číslo: Special Category Data by Structure
The rodné číslo, or RČ, uses the format RRMMDD/XXXX.
- RR — last two digits of birth year.
- MM — birth month. For women, 50 is added. Month 01 becomes 51. Month 12 becomes 62.
- DD — birth day.
- XXXX — a short sequence of 3–4 digits plus a check value (modulus 11).
The women's month offset makes this number a marker of biological sex. That offset is not incidental. The civil registration system uses it for admin lookup. GDPR Article 9 covers data that reveals personal traits. Sex is one of them. ÚOOÚ's view: any document with a rodné číslo carries special-category-adjacent data. Stronger protection applies.
How the check value works: For 10-character numbers (issued after 1954), the full 9-character base must divide evenly by 11. For 9-character numbers (issued before 1954), no check value exists. Tools must handle both.
What ÚOOÚ Calls Adequate Detection
ÚOOÚ's 2024 technical guidance for PII tools sets three requirements.
Gender-offset handling: Numbers with month values 51–62 are valid identifiers for women. A tool that treats those as invalid dates misses roughly half of the adult female population's primary ID.
Format variants: Pre-1954 births give 9-character numbers with no check value. Post-1954 births give 10-character numbers with one. Both must be supported.
Context signals: In native-language documents, the identifier appears near labels such as "Rodné číslo:", "RČ:", or "r.č.:". Language-aware NER helps find these signals even in free-form text.
The German Parent Company Problem
67% of firms in the country deploy German or English-configured PII tools. ÚOOÚ found this in a survey. The failure chain in manufacturing is predictable.
A German parent deploys a scanning tool. It is set up for German identifiers. HR data — contracts, health records, payroll — contains birth numbers. The tool has no logic for this identifier type. Every birth number is missed. Employee health and pay data moves without the controls ÚOOÚ requires. In an audit or breach, the local firm cannot show "appropriate technical measures" under GDPR Article 32.
ÚOOÚ holds the local controller responsible. "Our parent company chose the tool" is not a valid defense. GDPR's accountability rule does not allow it.
Compliance Checklist for Manufacturing Firms
These controls apply to industrial firms with German parent company tooling.
- Birth number detection: Both 9-character and 10-character formats. Gender-offset month handling (50+). Modulus-11 check value for 10-character variants.
- Native-language NER: spaCy
cs_core_newsor an equivalent model. Generic tools show 23% lower NER accuracy for this language. Local models close the gap. - Číslo OP detection: The občanský průkaz (national ID card) is a 9-character number. It appears alongside the birth number in many document types.
- IČO and DIČ: Business ID and tax numbers appear in contracts. Both need coverage.
- Multi-language pipeline: Mixed environments have documents in the local language, German, and English. A single-language pipeline misses cross-language co-occurrence.
ÚOOÚ enforcement is consistent. Firms that show technical evidence in an audit face much lower fines. Firms that cannot show it face higher exposure.
For a broader look at how national IDs create GDPR exposure, see our EU national tax ID detection guide.
For a similar Nordic identifier, see our Datatilsynet CPR technical guide.