Austria DSG compliance: the technical gaps that survive every GDPR audit
Amara OkaforApril 29, 2026
Key takeaways
Unsecured Elasticsearch 7.x clusters exposing PII without authentication appeared in Austrian environments across Vulnox assessments — these pass DSG audits because auditors request encryption configuration screenshots, not live port scans.
48% of Austrian organizations assessed use Article 6(1)(f) legitimate interests as a lawful basis for processing without a completed Legitimate Interest Assessment — the Datenschutzbehorde (DSB) treats this as a standalone violation, not just an aggravating factor.
Article 17 Right to Erasure fails most often not from legal misunderstanding but from technical architecture: immutable audit logs, event-sourced databases, and blockchain-backed records cannot be fully erased, and pseudonymization alone does not satisfy the obligation when re-identification is feasible.
The DSB consistently fines for two failures above all others: undocumented lawful basis and DSARs not honored within 30 days. These are process failures, not technical ones — and they survive penetration tests entirely.
Kubernetes network policies are almost never configured in Austrian deployments assessed, leaving pod-to-pod communication unrestricted — data that should be isolated by processing purpose flows freely across namespaces.
DSG Section 24 DPO designation criteria diverge from GDPR Article 37 in ways Austrian SMBs consistently misread — organizations that do not meet the large-scale processing threshold under GDPR may still trigger DSG-specific designation requirements.
TL;DR
Austrian GDPR compliance through the DSG fails in two distinct places and organizations almost always only fix one of them. The technical gaps — exposed services, default configurations, missing access controls — are visible to anyone running a scan. The process gaps — absent LIAs, undocumented lawful bases, broken DSAR workflows — are invisible to scanners and invisible to most auditors. The DSB fines for both, separately.
The SIEM that did not make them compliant
A Salzburg manufacturing firm bought a SIEM after their previous audit flagged logging gaps. By the time Vulnox assessed them, the SIEM was running, collecting events from 14 systems, and generating weekly reports. Their audit passed. Their Elasticsearch cluster — deployed two years earlier for a product search feature and never hardened — was listening on port 9200 with no authentication, indexed with full names, email addresses, and purchase histories of approximately 340,000 customers. The SIEM had no visibility into it. The auditor had never looked for it.
The cluster was not in scope for the audit because it was not in the asset inventory. It was not in the asset inventory because it had been stood up by a product team and never registered with IT. The SIEM collected logs from everything the security team knew about. The security team did not know about this. That is the structure of most Austria DSG technical gaps: not missing controls on known systems, but controls that do not reach systems that were never mapped.
Where DSG diverges from GDPR and why it matters technically
The Datenschutzgesetz (DSG) implements GDPR in Austria with specific national derogations. DSG Section 24 sets the criteria for mandatory DPO designation, which do not map cleanly onto GDPR Article 37. An organization that concludes it does not meet the Article 37 large-scale processing threshold may still trigger a DSG Section 24 designation requirement based on processing activities that pose specific risks to data subject rights — a broader and less precisely defined standard. Austrian SMBs applying the GDPR Article 37 analysis and stopping there are making an incomplete determination.
Example
The DSB enforcement pattern reflects this. Unlike some EU DPAs that focus enforcement on high-profile technical breaches, the DSB consistently pursues organizations for two categories of failure: undocumented lawful basis for processing and DSAR non-compliance. Both are process failures. Neither shows up in a vulnerability scan or a penetration test. An organization with excellent technical controls and broken DSAR workflows will pass a technical assessment and fail a DSB investigation. An organization with documented processes and an exposed Elasticsearch cluster has the opposite problem. Both are real. Most compliance programs address only one.
Austria-specific DSG requirements also cover video surveillance and employee data with more prescriptive rules than the GDPR baseline. Video surveillance in Austrian workplaces requires documented justification and specific signage — not just a privacy notice. Processing employee data on the basis of consent is explicitly disfavored by the DSB because of the power imbalance inherent in the employment relationship. Organizations with Austrian operations that imported their global GDPR policies without DSG-specific review are carrying compliance gaps they have not identified.
What the assessments found
Assessment base: Findings from Vulnox assessments of Austrian and Austrian-market-operating organizations across manufacturing, financial services, and SaaS, 2023-2025.
Elasticsearch clusters outside the asset inventory, exposed without authentication
In Austrian client environments, Elasticsearch clusters deployed by product and analytics teams — outside formal IT provisioning processes — consistently appeared in external attack surface scans that were not part of the internal asset inventory. Version 7.x deployments without X-Pack security enabled have no authentication by default. Port 9200 is accessible from the internet. The index contains whatever was written to it at deployment: in multiple cases, customer PII including names, email addresses, and behavioral data. None of these clusters were in scope for the DSG compliance assessment because none were in the asset register.
A digital footprint scan surfaces these before an attacker does. An internal audit does not, because internal audits work from the asset inventory. The gap between what an organization believes it operates and what is actually reachable from the internet is the most reliable source of critical findings across Austrian assessments. The DSG Article 25 obligation for data protection by design applies to these systems regardless of whether they were provisioned through formal IT channels.
Legitimate Interest Assessments absent for Article 6(1)(f) processing across 48% of assessed organizations
The pattern is consistent: privacy policies list legitimate interests as a lawful basis for analytics, marketing attribution, and fraud detection processing. The Legitimate Interest Assessment that must document the three-part balancing test — whether the interest is genuine, whether processing is necessary, whether data subject interests override — does not exist. Not incomplete. Not outdated. Not present. The DSB has fined for this independently of any breach. It is a documentation failure that lives in the compliance program, not the technical stack, and it survives every technical assessment.
An LIA is not a complex document, but it must exist before the processing begins, be specific to each processing activity it covers, and demonstrate the balancing test was actually performed. Retroactive LIAs written after a DSB inquiry are treated as evidence of prior non-compliance, not remediation. Organizations that have been using legitimate interests without LIAs for two or more years are carrying accumulated exposure for every month of that processing.
Article 17 erasure architecturally impossible in event-sourced and immutable log systems
Three Austrian organizations assessed in the financial services sector were running event-sourced architectures where the event log is the system of record. Deleting a customer record means deleting events from an immutable log — which breaks the audit trail the system was designed to maintain. Two had implemented pseudonymization as their erasure mechanism: replacing identifying fields with tokens. In both cases, the tokenization table was retained, making re-identification trivial for anyone with database access. The erasure obligation was documented as met. It was not met.
Article 17 compliance in immutable systems requires architectural decisions made at design time, not remediation decisions made after a DSAR. Pseudonymization satisfies the erasure obligation only when re-identification is not reasonably possible — which requires either destroying the mapping table or demonstrating that access to it is sufficiently controlled. Neither organization had analyzed whether their pseudonymization actually prevented re-identification. They had implemented a technical measure and assumed it was sufficient.
The control that passes audits and fails breaches
Common belief
Austrian organizations that have deployed MFA across their user-facing systems believe this satisfies the Article 32 requirement for appropriate technical measures securing personal data. MFA is listed as an implemented control. The auditor notes it. The compliance report reflects it.
What we found
In assessed Austrian environments running Kubernetes, Kubernetes network policies were configured in fewer than one in five cases. Default allow-all pod communication meant that a compromise of any pod in the cluster provided unrestricted access to all data served by other pods, regardless of data classification or processing purpose. The compliance documentation listed MFA and encryption as Article 32 controls. Neither addressed this attack path.
MFA on user-facing systems does not protect data in systems that authenticate via service accounts, API keys, or internal network trust. In Kubernetes environments — increasingly common in Austrian tech companies — pod-to-pod communication within a cluster is unrestricted by default. A compromised pod can query any other pod on the cluster network, including those serving personal data, without authentication of any kind. MFA on the front door does not address lateral movement inside the cluster. The attacker who gets past the perimeter via a phishing credential or a vulnerable public endpoint does not encounter MFA again.
The DSG-specific gaps Austrian compliance programs miss
DSG Section 24 DPO designation versus GDPR Article 37
Austrian organizations applying the GDPR Article 37 analysis to determine whether a DPO is required are using an incomplete framework. DSG Section 24 specifies additional designation criteria based on processing activities that pose specific risks to data subject rights — criteria that can trigger designation obligations for organizations that fall below the GDPR large-scale processing threshold. SMBs with niche but high-sensitivity processing activities (health-adjacent data, financial behavioral data, location tracking) may meet DSG Section 24 criteria without meeting Article 37 criteria. The DSB has pursued organizations that made this determination incorrectly.
Employee data processing consent basis
The DSB has taken a consistent enforcement position that consent is not a valid lawful basis for processing employee data in most circumstances, because the power imbalance in the employment relationship makes consent inherently non-voluntary under GDPR Article 7(4). Austrian organizations that use consent as the basis for employee monitoring, performance analytics, or HR system processing — a common pattern in organizations that imported global privacy policies written for customer data contexts — are using an invalid lawful basis. The DSB does not treat this as a technicality.
Video surveillance documentation requirements
Austrian DSG video surveillance rules require more than a privacy notice. Surveillance in workplaces and customer-facing spaces requires documented operational justification specific to the surveillance purpose, works council involvement where applicable, mandatory signage meeting specific content requirements, and data retention limits. Organizations with GDPR-compliant privacy policies that do not address DSG-specific video surveillance requirements are partially compliant on paper and non-compliant in practice. This is one of the most common Austria-specific gaps found during framework gap analysis of organizations with EU-wide privacy programs.
What is coming in Austrian DSG enforcement
The DSB will issue its first significant fine for exposed internet-facing services containing personal data — citing Article 25 data protection by design — within 18 months, following an enforcement pattern already established by the Hamburg and Berlin DPAs.
The DSB has historically focused enforcement on process failures: lawful basis documentation, DSAR response times. The technical enforcement wave among German DPAs — fining for exposed services, misconfigured cloud storage, and missing encryption on transit data — has not yet fully reached Austria. The DSB has the authority and the GDPR basis. The pattern among peer DPAs makes it structurally predictable. Austrian organizations with internet-facing services containing personal data that have not been assessed against Article 25 are the likely subjects.
Confidence: mediumA DSB enforcement decision citing Article 25 as the primary basis for a fine involving an exposed technical system, by end of 2026.Event-sourced and immutable-log architectures will become a formal DSB guidance topic within two years, as erasure requests against these systems produce documented compliance failures that regulators cannot continue to treat case-by-case.
The Article 17 erasure problem in event-sourced systems is not an edge case — it is an architectural pattern used by a significant share of Austrian fintech and SaaS companies. Pseudonymization as a substitute for erasure is being documented as a compliance measure in DSAR responses to the DSB. The DSB cannot consistently accept pseudonymization as erasure for systems where the tokenization table is retained without issuing guidance that creates regulatory certainty. The volume of affected organizations makes formal guidance inevitable.
Confidence: mediumDSB formal guidance or an enforcement decision specifically addressing Article 17 compliance in event-sourced or immutable-log systems by end of 2027.
The technical assessment that does not find the process failures
Most Austrian organizations frame their DSG compliance problem as a technical one. They buy SIEMs, deploy MFA, configure encryption, and commission penetration tests. These are correct actions. They do not address the two categories of failure the DSB actually fines for: undocumented lawful basis and broken DSAR workflows. A penetration test will not find a missing LIA. A SIEM will not flag a DSAR that went unanswered for 35 days. The organizations that fail DSB investigations are not predominantly the ones with the worst technical posture — they are the ones with compliance programs that were designed by security teams and never involved the legal, HR, and operations functions that own the process controls the DSB examines first.
Counterargument
The counterargument is that technical failures are what create breaches, and breaches are what trigger investigations, so fixing the technical posture reduces regulatory exposure indirectly. That logic holds at the level of breach prevention. It does not hold at the level of investigation outcomes. An organization with a breach and documented lawful bases, completed LIAs, and functioning DSAR workflows is in a materially better position before the DSB than one with the same breach and none of those documents. The investigation examines both dimensions. Most compliance programs address one.
One thing to do this week
Run a port scan against your own external perimeter — or have someone run one — and filter for ports 9200, 9300, 5601, and 27017. Those are Elasticsearch, Elasticsearch cluster, Kibana, and MongoDB defaults. If any are reachable from the internet, check whether authentication is required before a query returns data. That check takes under an hour. If the result is that a port responds without credentials, you have an Article 25 failure that your last audit did not find.
Further Reading
Gap Analysis
framework gap analysisVulerability Assessment
vulnerability assessment servicesEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
Austria DSG compliance and GDPR technical gaps for Austrian organisationsGDPR Legal Text Official
official GDPR legal textGDPR Compliance Complete Guide
comprehensive GDPR compliance guideNIST Vulnerability Assessment Definition
NIST vulnerability assessment definition
Frequently Asked Questions
How does Austria DSG differ from GDPR and where does it create additional compliance obligations?
The Datenschutzgesetz (DSG) implements GDPR in Austria with national derogations that create obligations beyond the GDPR baseline. DSG Section 24 sets DPO designation criteria that can trigger requirements for organizations that fall below GDPR Article 37 thresholds, based on processing activities posing specific risks to data subject rights. Austrian DSG also contains more prescriptive rules for video surveillance — requiring documented operational justification, specific signage, and works council involvement — and the DSB has taken an explicit enforcement position that employee data cannot be processed on the basis of consent due to the power imbalance in the employment relationship.
What does the Austrian Datenschutzbehorde (DSB) fine for most consistently?
DSB enforcement focuses primarily on two failure categories: undocumented lawful basis for processing — particularly the use of Article 6(1)(f) legitimate interests without a completed Legitimate Interest Assessment — and failure to honor Data Subject Access Requests within the 30-day deadline. These are process failures, not technical ones. They survive penetration tests and vulnerability assessments entirely because they live in compliance workflows, not in technical systems. Organizations that invest in technical security controls without addressing DSAR and lawful basis documentation remain exposed to the DSB's primary enforcement categories.
Why do Elasticsearch clusters keep appearing as a critical finding in Austrian GDPR assessments?
Elasticsearch 7.x deployments without X-Pack security enabled have no authentication by default and listen on port 9200. When analytics or product teams deploy Elasticsearch outside formal IT provisioning, the cluster does not appear in the asset inventory and is not scoped into compliance assessments. It is reachable from the internet, contains whatever personal data was indexed at deployment, and generates no alerts. Vulnox external attack surface assessments find these clusters in Austrian environments because they scan what is actually reachable, not what is in the inventory. The compliance program scans the inventory.
How do we comply with Article 17 Right to Erasure in an event-sourced or immutable-log architecture?
Article 17 erasure in immutable systems requires an architectural decision made at design time. Pseudonymization satisfies the erasure obligation only when re-identification is not reasonably possible — which means either destroying the tokenization mapping table or demonstrating that access to it is sufficiently controlled to prevent re-identification. Retaining the mapping table while replacing identifying fields in the event log does not satisfy Article 17. The correct approaches are cryptographic erasure (destroying the encryption key for encrypted fields), hard partitioning of personal data from immutable audit records at design time, or documented retention limitation that prevents personal data from entering the immutable log in the first place.
What does a Legitimate Interest Assessment need to contain to satisfy DSB scrutiny?
A Legitimate Interest Assessment must document three things: whether the legitimate interest is real and specific (not generic business purposes), whether the processing is necessary to achieve that interest (and less privacy-invasive alternatives were considered), and whether the data subject's rights and freedoms override the legitimate interest given the nature of the data and the context of processing. The LIA must be completed before the processing begins, must be specific to each processing activity it covers, and must not be a template applied uniformly across all legitimate interest processing. The DSB treats retroactive LIAs as evidence of prior non-compliance, not remediation.
Does MFA satisfy the GDPR Article 32 technical measures requirement for Austrian organizations?
MFA on user-facing systems satisfies one component of Article 32 for one attack vector. It does not address service-to-service authentication, API key management, or internal network lateral movement. In Kubernetes environments — common in Austrian tech companies — pod-to-pod communication is unrestricted by default, meaning a compromised pod can reach any personal data served by other pods without authentication. Vulnox assessments found Kubernetes network policies configured in fewer than one in five Austrian environments assessed. Article 32 requires measures appropriate to the risk of the specific processing — a determination that must account for internal network architecture, not just perimeter authentication.
What is the fastest way to identify DSG compliance gaps in an Austrian business?
Two parallel checks surface the most critical gaps fastest. First, run an external attack surface scan against your own perimeter to identify internet-facing services containing personal data that are not in your asset inventory — Elasticsearch, MongoDB, and misconfigured cloud storage consistently appear in Austrian environments that pass internal audits. Second, list every processing activity using Article 6(1)(f) legitimate interests as the lawful basis and check whether a completed Legitimate Interest Assessment exists for each one. These two checks address the technical gap the DSB is moving toward enforcing and the process gap it already fines for consistently.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.