Data Breach Notification Austria 2026: Deadlines, Thresholds and How to Notify the DSB

Data breach notification austria has become a sharper compliance concern in 2026, as the Austrian Data Protection Authority (Datenschutzbehörde, or DSB) maintains its focus on late and insufficient reports of personal data breaches. Controllers and processors operating in Austria must understand not only the substantive requirements of the General Data Protection Regulation but also how the DSB expects breaches to be assessed, escalated and reported in practice. This guide sets out the deadlines, thresholds and workflow you need to report a personal data breach to the DSB and, where required, to affected individuals. It is written for data protection officers, in-house counsel, and IT and security leaders who need clear, actionable steps rather than abstract theory.

Introduction, why data breach notification austria matters in 2026

Enforcement activity in Austria continues to demonstrate that supervisory authorities treat notification failures as serious infringements in their own right. A breach that is handled well technically can still attract a fine or reprimand if it is reported late, reported with incomplete information, or not documented adequately. In 2026, the practical message from the DSB’s published decisions is consistent: the authority scrutinises the timeline between detection and notification, the quality of the risk assessment, and the evidence a controller can produce after the fact.

The following TL;DR checklist captures the essentials before we go deeper into the workflow.

• Do. Detect, contain and assess without delay; document every step and decision as you go.
• Do. Notify the DSB without undue delay and, where feasible, within 72 hours of becoming aware of a breach that is likely to result in a risk (GDPR Art. 33(1)).
• Do. Notify affected individuals where the breach is likely to result in a high risk to their rights and freedoms (GDPR Art. 34).
• Don’t. Wait for a complete forensic picture before notifying, file an initial notification and supplement it later.
• Don’t. Decide not to notify without a documented risk assessment supporting that decision.
• Deadlines. DSB: 72 hours where feasible. Individuals: without undue delay where high risk applies.

For broader context on how the authority approaches infringements, the DSB’s own published decisions and the European Data Protection Board’s guidance complement the procedural steps set out here.

Who enforces data breach notification austria, the DSB

The Austrian Data Protection Authority (Datenschutzbehörde, DSB) is the national supervisory authority responsible for enforcing the GDPR and the Austrian Data Protection Act (Datenschutzgesetz, DSG) within Austria. It receives breach notifications, opens investigations, issues corrective measures and imposes administrative fines. The DSB also publishes selected decisions, which offer valuable insight into how the authority reasons about notification timing and content.

Because the GDPR operates across the European Economic Area, incidents affecting individuals in more than one Member State engage the cooperation and consistency mechanism. Under that mechanism, a single “lead supervisory authority”, determined by the location of the controller’s main establishment, coordinates the handling of cross-border cases with concerned authorities. For controllers whose main establishment is in Austria, the DSB will typically act as lead authority in cross-border matters, while still cooperating with other supervisory authorities where individuals in their jurisdictions are affected.

DSB contact and jurisdiction

The DSB accepts breach notifications through the channels published on its official website. Practitioners should confirm the current submission method, online form or email to the authority’s designated address, directly against the DSB site before filing, as contact points and portal arrangements are updated periodically. The authority’s jurisdiction covers controllers and processors established in Austria and, in the cross-border context, extends to its role as lead or concerned authority under the GDPR’s cooperation rules. The DSB’s official website is the authoritative reference point for its current guidance and any published decisions.

What counts as a reportable personal data breach?

The starting point is the statutory definition. Under Article 4(12) of the GDPR, a “personal data breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. This definition is broad. It captures far more than external cyberattacks: it includes internal errors, physical losses and confidentiality failures.

Not every personal data breach triggers a notification duty, however. Article 33(1) requires notification to the DSB only where the breach is “likely to result in a risk to the rights and freedoms of natural persons.” Article 34 imposes a separate, higher threshold for notifying individuals: the breach must be “likely to result in a high risk.” Understanding these two thresholds, risk versus high risk, is central to getting data breach notification austria decisions right.

Assessing “risk” is a factual, case-by-case exercise. Relevant factors include the type of breach, the nature, sensitivity and volume of the personal data involved, the ease of identifying affected individuals, the severity of potential consequences, and any special characteristics of the data subjects (for example, children or vulnerable persons). The European Data Protection Board’s guidelines on personal data breach notification provide detailed methodology for this assessment and are a key reference for practitioners.

Examples and non-examples

The following short scenarios illustrate how the thresholds apply in Austrian practice. They are deliberately simplified, real assessments turn on their specific facts.

• Employee email leak. An employee sends a spreadsheet containing customer names, addresses and payment details to the wrong external recipient. This is a confidentiality breach likely to result in a risk, so the DSB should be notified; whether individuals must be told depends on whether the risk is high (payment data and re-identification often push it there).
• Lost laptop. A company laptop with full-disk encryption is lost in a taxi. There is no sign that the encryption key was compromised. Because effective encryption renders the data unintelligible, the breach may be unlikely to result in a risk, but the controller must document that assessment, including verification that the encryption was robust and current.
• Ransomware. Attackers encrypt a database of personal data and there is evidence of exfiltration or a real risk of re-identification. This is likely to result in a risk (notify the DSB) and often a high risk (notify individuals), particularly where sensitive categories are involved.
• Accidental exposure. A misconfigured web server exposes a directory of documents containing health data for several hours before being closed. The sensitivity of health data means the DSB should be notified and individuals should generally be informed, subject to a documented high-risk assessment.

The recurring lesson across these examples is that documentation is not optional. Even where you conclude that no notification is required, the reasoning behind that conclusion must be recorded and defensible.

Deadlines and thresholds, when to notify the DSB (the 72-hour rule explained)

Article 33(1) of the GDPR sets the core timing rule for data breach notification austria: the controller must notify the competent supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware” of a personal data breach that is likely to result in a risk to the rights and freedoms of natural persons. Where notification is not made within 72 hours, it must be accompanied by reasons for the delay.

Two phrases carry most of the weight here. “Without undue delay” is the overarching standard, the 72-hour figure is a ceiling, not a licence to wait. In many cases the DSB will expect notification well inside that window where the facts are clear. “Where feasible” acknowledges that some incidents are complex and that a controller may not have all details at the 72-hour mark. In that situation, Article 33(4) expressly permits notification in phases: an initial notification followed by supplementary information as the investigation develops. Practitioners should use this phased mechanism rather than delaying the entire notification.

Article 33(1) also builds in an exception: notification is not required where the breach is “unlikely to result in a risk to the rights and freedoms of natural persons.” This is where the risk assessment described earlier becomes decisive. If you rely on this exception, keep the assessment on file, the DSB may ask to see it.

Calculating the clock and internal escalation

The 72-hour clock starts when the controller becomes “aware” of the breach, that is, when it has a reasonable degree of certainty that a security incident has occurred that compromised personal data. Awareness is not the moment a vague anomaly is first noticed; it is the point at which the controller establishes, after a prompt initial investigation, that a personal data breach has taken place. Crucially, the obligation to investigate promptly means a controller cannot delay “awareness” indefinitely by failing to look.

Practical time-keeping requires a defined internal escalation path. A workable sequence is:

1. Detection and logging. The incident is identified, logged with a timestamp, and routed to the incident response team.
2. Initial triage. Within hours, confirm whether personal data is involved and establish preliminary scope; this triage is what crystallises “awareness.”
3. Risk assessment. Assess whether the breach is likely to result in a risk (DSB threshold) and a high risk (individual threshold), documenting the reasoning.
4. Notification decision and filing. Notify the DSB where the threshold is met, using a phased approach if full details are not yet available.
5. Follow-up. Supplement the notification, notify individuals if required, and record remediation.

Where a processor detects the breach, Article 33(2) requires it to notify the controller without undue delay. The controller then remains responsible for the notification to the DSB. Processor contracts under Article 28 should specify exactly how and how quickly the processor must alert the controller, because delays at the processor level directly erode the controller’s 72-hour window.

Exceptions and late notification, mitigation strategy

If you conclude a breach is unlikely to result in a risk, no notification to the DSB is required, but the record-keeping obligation under Article 33(5) still applies. If, on the other hand, you have missed the 72-hour window, do not treat that as a reason to avoid notifying altogether. Late notification with a candid explanation is materially better than non-notification. Article 33(1) contemplates late filings by requiring reasons for delay, which signals that the regime anticipates and accommodates them.

To mitigate enforcement exposure after a delay, controllers should: notify as soon as the position is clear; explain the delay honestly and factually; demonstrate the containment and remediation steps taken; and show cooperation with the DSB. Under Article 83, timeliness, documentation quality and cooperation are among the factors a supervisory authority weighs when deciding on corrective measures and any fine.

How to notify the DSB, step-by-step and the DSB breach form

Once you have determined that data breach notification austria obligations are engaged, the mechanics of filing matter. Article 33(3) sets out the minimum content of a notification to the supervisory authority, and the DSB’s notification form is structured around these elements. At minimum, the notification must describe:

• The nature of the breach. Including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned.
• Contact details. The name and contact details of the data protection officer or other contact point where more information can be obtained.
• Likely consequences. A description of the likely consequences of the personal data breach for affected individuals.
• Measures taken or proposed. The measures taken or proposed to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.

Where you cannot provide all information at once, use the phased notification route under Article 33(4) and clearly flag which fields are provisional.

What supporting evidence to attach

A well-supported notification helps the DSB understand the incident quickly and demonstrates the controller’s diligence. Useful attachments and details include:

• An incident timeline showing detection, triage, awareness, containment and notification, each with timestamps.
• Relevant log extracts evidencing the scope and cause of the breach, redacted where necessary to remove data not relevant to the DSB’s assessment.
• The documented risk assessment supporting the notification decision and the high-risk determination for individuals.
• A description of the affected data categories and, where sensitive categories are involved, an explanation of why they engage a heightened risk.
• Evidence of remediation, patching, access revocation, forced password resets, or engagement of forensic specialists.

For drafting the “description of the breach” field, plain, factual language works best. For example: “On [date], a misconfiguration exposed [category] personal data of approximately [number] data subjects to unauthorised access for [period]. The exposure was closed at [time] on discovery.” For “measures taken,” describe both the immediate containment and the durable fixes, and note any monitoring introduced to detect recurrence.

Cross-border incidents and the lead supervisory authority

Where a breach affects individuals in more than one Member State, the cooperation mechanism determines which authority leads. If the controller’s main establishment is in Austria, the DSB will generally act as lead supervisory authority, receiving the notification and coordinating with concerned authorities in other Member States. In that scenario, a single notification to the DSB is normally appropriate, though controllers should confirm the position for their specific facts. Where there is no main establishment in the EEA, notification may be required to each concerned authority. The EDPB’s guidance on breach notification and supervisory cooperation should be consulted to identify the correct filing strategy for multi-jurisdictional incidents.

When and how to notify data subjects, tests, content and templates

Notification to the DSB and notification to individuals are governed by different tests. Article 34(1) requires the controller to communicate the breach to affected data subjects “without undue delay” where it is “likely to result in a high risk to the rights and freedoms of natural persons.” The threshold is deliberately higher than for supervisory-authority notification, reflecting the disruption and alarm that individual notifications can cause.

Article 34(3) sets out three circumstances in which individual notification is not required: where the controller had applied appropriate technical and organisational protection measures, such as strong encryption, that render the data unintelligible to unauthorised persons; where the controller has taken subsequent measures ensuring the high risk is no longer likely to materialise; or where notification would involve disproportionate effort, in which case a public communication or equivalent measure is acceptable instead. These exceptions must be assessed carefully and documented.

Under Article 34(2), the communication to individuals must describe, in clear and plain language, the nature of the breach and contain at least the DPO contact point, the likely consequences, and the measures taken or proposed, including mitigation. It should also, where appropriate, offer practical guidance, for example, advising affected individuals to reset passwords or watch for suspicious activity.

Template language, do’s and don’ts

A concise notification to individuals might read: “We are writing to inform you of a personal data breach affecting your data. On [date] we became aware that [brief factual description]. The information involved was [categories]. The likely consequences are [consequences]. We have taken the following steps: [measures]. We recommend that you [practical advice]. If you have questions, contact [DPO/contact point].”

• Do use plain language, avoid jargon, and be specific about the practical steps individuals can take to protect themselves.
• Do provide a working contact point capable of handling the volume of enquiries the notification will generate.
• Don’t minimise or obscure the facts, under-disclosure erodes trust and increases enforcement risk.
• Don’t delay individual notification pending a perfect account; where high risk is clear, communicate promptly.

Mass-notification considerations and PR coordination

When a breach affects large numbers of individuals, logistics and reputation management become significant. Where individual contact would involve disproportionate effort, Article 34(3)(c) permits a public communication or an equally effective alternative. Even so, communications should be coordinated across legal, security and communications functions so that public statements, individual notices and the DSB submission are consistent. Inconsistent messaging can itself become a compliance and reputational liability.

Practical compliance controls and recordkeeping for audits and DSB inquiries

Documentation is the backbone of a defensible breach response. Article 33(5) requires controllers to document any personal data breach, including the facts relating to the breach, its effects and the remedial action taken. This obligation applies to all breaches, including those you decide not to notify, and enables the DSB to verify compliance. A maintained breach register is therefore not merely good practice; it is a direct statutory requirement.

An effective internal framework includes a written incident response playbook with defined roles and escalation triggers, standard templates for the risk assessment and the DSB submission, log-retention policies that preserve the evidence the DSB may later request, and processor arrangements that guarantee prompt upstream notification. Preserving logs and internal escalation emails is especially important, because these are what allow a controller to demonstrate exactly when awareness arose and how quickly it acted.

What the DSB will expect to see in investigations

If the DSB opens an inquiry, it will typically want to see the breach register entry, the timeline from detection to notification, the documented risk assessment, the notification itself and any supplementary filings, communications with affected individuals, and evidence of remediation. Controllers that can produce this record quickly and coherently place themselves in a far stronger position than those reconstructing events after the fact. The ability to evidence a timely, reasoned response tends to influence outcomes.

Enforcement landscape and fines, 2026 highlights and mitigation lessons

Austrian enforcement in recent years reflects a sustained supervisory interest in how breaches are handled, with notification timing and adequacy featuring in the DSB’s reasoning. The GDPR’s two-tier fine structure means notification failures under Articles 33 and 34 fall within the tier under Article 83(4), with maximum fines of up to EUR 10 million or, in the case of an undertaking, up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. Underlying infringements of the data-processing principles or data-subject rights can attract the higher tier under Article 83(5). The DSB and the courts remain the authoritative sources for the specifics of individual cases and the factors weighed.

Top compliance takeaways

• Run breach-response simulations so that the 72-hour timeline is achievable under pressure.
• Embed clear notification and escalation obligations in Article 28 processor contracts.
• Maintain the Article 33(5) breach register for all incidents, notified or not.
• Prefer prompt phased notification over delayed complete notification.
• Consider cyber-insurance and pre-arranged forensic support to accelerate assessment.

Comparison table, notify the DSB vs notify individuals

The following decision matrix helps you determine which notification path applies. In many serious incidents, both are required.

Quick checklist and downloadable resources

Use this condensed operational checklist alongside your internal playbook:

• Log the incident with an accurate timestamp and open a breach register entry.
• Triage promptly to establish whether personal data is involved and confirm awareness.
• Assess and document risk (DSB threshold) and high risk (individual threshold).
• Notify the DSB within 72 hours where the threshold is met, using phased notification if necessary.
• Notify individuals without undue delay where a high risk exists, unless an Article 34(3) exception applies.
• Preserve logs, escalation emails, assessments and submissions for potential DSB inquiry.
• Record remediation and update the breach register on closure.

Set an internal service-level target that comfortably beats the statutory 72-hour ceiling, so that unexpected complexity does not push you past the deadline.

Conclusion

Getting data breach notification austria right in 2026 comes down to disciplined preparation and speed. The legal architecture is clear: notify the DSB without undue delay and, where feasible, within 72 hours for breaches likely to result in a risk; notify individuals where the risk is high; and document everything, including decisions not to notify. Enforcement experience shows that supervisory authorities reward prompt, well-evidenced, cooperative responses and treat notification failures as serious in their own right. Controllers that build a tested incident-response framework, maintain a rigorous breach register and use phased notification when facts are still emerging will be well placed to meet their obligations and to withstand scrutiny. Because each breach turns on its facts, obtaining tailored advice on your specific incident and sector is strongly recommended.

This article is for general information and does not constitute legal advice. For case-specific advice, please seek qualified counsel.

Sources

1. Regulation (EU) 2016/679 (GDPR), Official text (EUR-Lex)
2. Austrian Data Protection Authority (Datenschutzbehörde, DSB)
3. Rechtsinformationssystem (RIS), Austrian legal database
4. European Data Protection Board (EDPB), guidelines and documents
5. European Commission, Data protection (GDPR) pages
6. Austrian Bar Association (Österreichischer Rechtsanwaltskammertag, ÖRAK)