DSB Austria: Schrems & Data Transfers
Austria's Datenschutzbehörde (DSB) is the home regulator for NOYB. NOYB stands for None of Your Business. Max Schrems founded the group. It has filed over 1,000 GDPR complaints since 2018. The DSB handled 422 of those cases between 2022 and 2024.
That track record matters. The DSB sits at the center of two legal battles that already reshaped EU transfer law.
NOYB and the DSB: A Pattern
Schrems I (2015): Schrems filed a complaint about Facebook's EU-US flows. The CJEU struck down Safe Harbor. More than 4,000 firms used that framework at the time.
Schrems II (2020): A second challenge hit Privacy Shield. Over 5,000 firms relied on it. Its collapse forced new talks. The result was the EU-US Data Privacy Framework (DPF). The DPF took effect in 2023.
Anticipated Schrems III (2025–2026): NOYB has challenged the DPF adequacy decision. Its argument: FISA Section 702 still conflicts with GDPR. A CJEU referral is expected.
78% of DSB cases involve cross-border transfers or third-party tools. That focus sets Austrian regulators apart from other EU bodies.
The DSB's Google Analytics Ruling
The DSB's January 2022 Google Analytics decision set the template for transfer cases.
Three key findings came out of it:
- IP addresses are personal data. Even truncated IPs can enable re-ID inside Google's systems. Session records make it worse.
- US vendor access counts as a transfer. When US engineers can reach EU user records, that access is a transfer under GDPR. This covers support, upkeep, and legal orders alike.
- SCCs without a TIA are not enough. Standard Contractual Clauses need a Transfer Impact Assessment. The TIA must show US spy laws do not cancel the SCC protections.
The DSB found the Austrian site operator liable — not Google. The operator was the controller. This applies to every EU business that embeds third-party scripts. See our GDPR compliance guide for controller duties.
Extra Technical Measures
After Schrems II, the EDPB published guidance on extra technical measures. These apply when SCCs fall short on their own. The DSB enforces this guidance.
Three approaches pass DSB scrutiny:
Encryption with EU-held keys. Encrypt records before they leave the EU. Keep decryption keys in EU hands. If US authorities compel the vendor to hand over files, they get ciphertext they cannot read.
Pseudonymization before transfer. Send only pseudonymous tokens across borders. Hold the re-ID key inside the EU. The transferred files carry no direct personal data.
Local processing. Run all processing on EU-hosted servers. Transfer only aggregate, truly anonymous stats. No personal records cross borders at all.
The DSB has confirmed this stance. Groups using US SaaS vendors for EU personal data must apply at least one of these approaches. Or they must prove the transferred content is truly anonymous.
The Schrems III Risk
Firms that rely only on the DPF face a clear risk. If NOYB's CJEU challenge succeeds, those firms must find new transfer tools fast. That is exactly what happened in 2015 and 2020.
Groups using extra technical measures are shielded. If content is truly anonymous, no GDPR transfer occurs. A DPF collapse changes nothing for them.
For Austrian ops: analytics tools (Google Analytics, Mixpanel, Amplitude) all create DSB exposure. So do CRM systems with US parent firms (Salesforce, HubSpot). Cloud platforms where US staff hold admin access carry the same risk.
The fix is the same in each case. Make sure personal records are truly anonymous before they reach the vendor. Or encrypt them with keys the EU controller holds alone. Our security and compliance overview explains how zero-knowledge design removes the transfer problem at its source.
When This Approach Has Limits
Encrypting with EU-held keys, pseudonymizing before transfer, or sending only truly anonymous aggregates is the right hedge against a possible Schrems III collapse — but limits remain worth stating plainly.
Pseudonymization before transfer keeps data in scope and moves the key burden. Sending pseudonymous tokens across borders while holding the re-identification key inside the EU is a valid supplementary measure, but it does not take the data out of GDPR. The transferred set is still personal data, and the protection now rests entirely on key custody, which becomes a control you must secure, rotate, and audit. The DSB's claim that only truly anonymous output removes the transfer is the sharp distinction here: pseudonymized is not anonymized, and treating the two as equal is the failure mode these cases punish.
Anonymity claims depend on detection and quasi-identifiers, not intent. Sending "aggregate, truly anonymous stats" only holds if the underlying records were fully de-identified first, and the DSB's Google Analytics ruling shows how low that bar sits: even truncated IP addresses counted as personal data because they enabled re-identification in combination with session records. Quasi-identifiers can rebuild an identity after direct identifiers are stripped. Test what your output actually reveals against held-out data before calling it anonymous, because a mislabelled aggregate reopens the transfer you thought you had closed.
The tool supports a TIA but does not constitute compliance. The DSB holds the Austrian controller liable, not the vendor, and it assesses the whole arrangement: the SCC, the Transfer Impact Assessment, US surveillance exposure under FISA Section 702, and the specific supplementary measures in place. Encryption with EU-held keys is one such measure, not a complete defense. The organization still owes a documented TIA and legal review of every analytics, CRM, and cloud flow, so the tooling supports the assessment rather than replacing the judgment the DSB audits.
Sources
- DSB: Austrian Data Protection Authority — VERIFIED-EXTERNAL
- NOYB: Strategic Litigation — VERIFIED-EXTERNAL
- CJEU: Schrems II Decision C-311/18 (2020) — VERIFIED-EXTERNAL
- EDPB: Recommendations 01/2020 on extra transfer measures — VERIFIED-EXTERNAL