Last updated: 2026-11-06
Legal status: German Telecommunications Act (Telekommunikationsgesetz, TKG) as amended on 22 October 2026, Regulation (EU) 611/2013 and the GDPR as published in the Official Journal, checked on 6 November 2026. This page provides general information, not legal advice. Whether a specific breach must be notified and whom you must inform is a data protection question for the individual case. Clarify it with your data protection officer and, if in doubt, with a lawyer admitted in Germany. Quotations from German statutes on this page are our own unofficial translations. Only the German text is legally binding.
When is there a personal data breach?
Whenever a breach of data security leads to the loss, unlawful erasure, alteration, storage, disclosure or other unlawful use of personal data, and whenever there is unlawful access to such data. This is the definition in Section 3 no. 71 TKG. Unlike Section 168, Section 169 has no significance threshold: under Article 2(1) of Regulation (EU) 611/2013 every breach must be notified to the authority. Anyone who, in operations, gains unauthorised knowledge of the content or the detailed circumstances of a communication also touches on the secrecy of telecommunications under Section 3 TDDDG.
Examples are invoices or itemised call records sent to the wrong recipients, unauthorised access to the customer database, a lost device holding customer data, or a service provider whose system has been compromised. A mere suspicion does not yet trigger the duty to notify. Under Article 2(2) of the Regulation the breach counts as detected as soon as the provider has enough information to make a meaningful notification. The deadline runs from that point.
Who has to notify under Section 169?
Providers of publicly available telecommunications services, such as internet access, telephony or e-mail for end customers. Section 169 does not mention operators of public telecommunications networks that do not provide such a service themselves. Whether your company provides a publicly available service is explained on the page am I a telecom provider?
If another operator of a publicly available service without its own customer relationship has been commissioned to deliver part of your service, it must inform you immediately of a breach (Article 5 of the Regulation). Other service providers, for example for billing, hosting or the customer portal, must in the view of the BfDI be contractually obliged to inform you without undue delay, so that you can meet your notification duty. The provider with the customer relationship makes the notification.
To whom, how and by when?
Notifications always go to both authorities, the Bundesnetzagentur and the BfDI, not to the Federal Office for Information Security (BSI). Section 169 itself requires notification “without undue delay”. Regulation (EU) 611/2013, which applies directly, specifies this:
| Step | Deadline | Legal basis |
|---|---|---|
| Initial notification to BNetzA and BfDI | within 24 hours of detection, where feasible | Section 169(1) sentence 1 TKG, Article 2(2) Regulation 611/2013 |
| Second notification, if information was missing from the initial one | as soon as possible, no later than three days after the initial notification; anything still missing is supplied later with reasons | Article 2(3) Regulation 611/2013 |
| Notification of affected persons, where required | without undue delay (Section 169 and the Regulation, which counts from detection), independently of the notification to the authorities | Section 169(1) sentence 2 TKG, Article 3(3) Regulation 611/2013 |
| Entry in the inventory | for every breach | Section 169(3) TKG |
The BfDI provides a notification form (as of February 2022), intended only for providers of publicly available telecommunications services. Information that is not yet known in the first hours may be left open as “not yet known”. According to the BfDI, the form must be completed in full for every follow-up notification, because the latest notification always counts as current, and sent to both authorities again. The BfDI page and the form do not give the same e-mail addresses for the authorities. The BfDI page on the procedure under Section 169 TKG (German) is authoritative, and it also provides a PGP key for encrypted transmission.
Every notification must at least state the nature of the breach, contact points for further information and recommendations for limiting adverse effects. Notifications to BNetzA and BfDI must also cover the consequences of the breach and the measures planned or taken (Section 169(2)). Section 42(4) and Section 43(4) of the Federal Data Protection Act (BDSG) apply accordingly: in our reading, the notification may only be used in criminal or administrative fine proceedings against the notifying party with its consent.
When must affected persons be notified?
Under Article 3(1) of Regulation (EU) 611/2013, when the breach is likely to adversely affect the personal data or privacy of the persons concerned. Section 169(1) sentence 2 TKG requires that end users or other persons are seriously affected in their rights or legitimate interests. The Regulation names circumstances for the assessment: the nature of the data, in particular financial data, location data, internet log files, web browsing histories, e-mail data and itemised call lists; the likely consequences such as identity theft, fraud or damage to reputation; and the circumstances, for example whether data were stolen. The notification must be clear and easy to understand and must not be used for advertising.
The Regulation applies directly and takes precedence over conflicting national law. In our reading its lower threshold therefore applies; if in doubt, a lawyer can give a binding answer. A decision not to notify should be justified in writing against the criteria of the Regulation.
Encryption exception: Under Section 169(1) sentence 3, notifying affected persons is not required if the security concept demonstrates that the data were protected by appropriate technical measures, in particular secure encryption. The BfDI adds that the evidence can also be provided outside the concept, that notification of the authorities remains mandatory in every case, and that a data loss after which the data are no longer available to the provider may require notification despite encryption. The BNetzA can order notification regardless. How encryption is described in the concept is shown on the page security concept under Section 166 TKG.
What goes into the inventory of breaches?
Under Section 169(3) every provider keeps an inventory of all breaches with the circumstances, the effects and the remedial measures taken. The entries must allow BNetzA and BfDI to check whether notification of the authorities and of affected persons was correct. Breaches more than five years old no longer need to be included. An example entry is in the scenario below.
What else does Section 169 cover?
Subsections 4 to 7 deal with disruptions caused by users' equipment, such as infected routers: the provider informs the users known to it, which is mandatory after the BSI has reported specific significant threats, and may restrict or redirect use or filter traffic to and from sources of disruption if the user does not remedy the problem. These subsections have nothing to do with notifying a personal data breach under subsection 1.
How does Section 169 relate to Section 168 TKG and Article 33 GDPR?
Three reporting routes can apply to the same incident. The table sets them side by side:
| Section 168 TKG | Section 169 TKG | Articles 33, 34 GDPR | |
|---|---|---|---|
| Trigger | significant security incident | personal data breach, no significance threshold | personal data breach, unless it is unlikely to result in a risk |
| Who | network operators and providers of publicly available services | only providers of publicly available services | controller |
| To whom | BNetzA and BSI | BNetzA and BfDI | competent supervisory authority |
| Deadline | 24 hours, 72 hours, one month | without undue delay, under Regulation 611/2013 within 24 hours, second notification within three days | without undue delay, where feasible within 72 hours |
| Affected persons | inform users of a particular and significant threat (Section 168(7)) | if adversely affected under Article 3 Regulation 611/2013; Section 169: seriously | if likely to result in a high risk (Article 34) |
| Documentation | no separate documentation duty in the TKG, reports up to the final report | inventory; breaches older than five years need not be included | documentation of all breaches (Article 33(5)) |
| Fine range (Section 228 TKG) | report: up to EUR 10,000 (subsection 2 no. 39) | notification: up to EUR 100,000 (no. 40); inventory: up to EUR 10,000 (no. 41) | under the GDPR, not covered here |
Section 168 and Section 169: The two duties apply side by side. The Act does not count one notification towards the other (our derivation from the wording). An attack on customer data can therefore trigger a report to BNetzA and BSI under Section 168 and a notification to BNetzA and BfDI under Section 169. The stages under Section 168 are explained on the page incident reporting under Section 168 TKG.
Section 169 and the GDPR: Under Article 95 GDPR the Regulation imposes no additional obligations on providers where the ePrivacy Directive pursues the same objective. The BfDI concludes that where only data are affected for which the Telecommunications Digital Services Data Protection Act (TDDDG) contains its own rules, Section 169 applies. In mixed cases, where the same incident also breaches GDPR provisions, a notification under Section 169 is sufficient in the view of the BfDI, for example for traffic and customer data. This is the authority's view, not the wording of the law. According to the BfDI, other cases follow Article 33 GDPR; in our reading this covers, for example, a breach that affects only employee data or data from another line of business.
Decision tree: which reporting route?
The decision tree is our derivation from the Act, the Regulation and the guidance of the BfDI. It helps you not to overlook anything in an emergency and does not replace the assessment of the individual case.

| Step | Question | Yes | No |
|---|---|---|---|
| 1 | Have personal data been lost, unlawfully erased, altered, stored, disclosed or used, or has there been unlawful access to them (Section 3 no. 71 TKG)? | continue with 2 | no reporting route under Section 169 or the GDPR, continue with 5 |
| 2 | Is the company concerned a provider of a publicly available telecommunications service, and does the breach affect that service? | continue with 3 | Section 169 does not apply, check Article 33 GDPR; as a commissioned operator without a customer relationship, inform the commissioning provider immediately |
| 3 | Are data affected for which the TDDDG contains its own rules, such as traffic or customer data? | notification under Section 169 to BNetzA and BfDI, where feasible within 24 hours of detection, second notification no later than three days after that; in mixed cases, according to the BfDI, only Section 169 | notification under Article 33 GDPR to the competent supervisory authority, where feasible within 72 hours, unless the breach is unlikely to result in a risk |
| 4 | Is the breach likely to adversely affect the data or privacy of the persons concerned (Article 3 Regulation 611/2013; Section 169(1) sentence 2 TKG requires “seriously”)? | notify affected persons without undue delay, unless secure encryption has been demonstrated and no data have been lost | document the reasons using the criteria of the Regulation; the BNetzA can still order notification |
| 5 | Is there also a significant security incident under Section 168(3)? | additional reports to BNetzA and BSI after 24 hours, 72 hours and one month | document the assessment |
| 6 | Was a notification made under Section 169? | entry in the inventory of breaches | file the assessment in the incident log |
Example: mixed-up itemised call records at a municipal utility
Fictitious example, not a client. A municipal utility (Stadtwerk) offers internet access and telephony to around 8,000 households and business customers through its telecoms arm. After an update of the billing system, 140 invoices are sent by e-mail with another customer's itemised call record. We count the deadline from the point at which the utility knows enough for a meaningful notification. When that is the case in legal terms has to be assessed in the individual case.
| Time | Event | Role | Decision or result |
|---|---|---|---|
| Tue 08:10 | a customer reports having received a stranger's call overview | customer service | case passed to IT and the data protection officer |
| Tue 09:30 | IT confirms: 140 invoices from Monday's run were sent with a mixed-up itemised call record | head of IT | sending stopped; detection recorded internally: 09:30 |
| Tue 10:30 | assessment: disclosure of traffic data (steps 1 to 3); itemised call records are a criterion for notifying affected persons under Article 3 Regulation 611/2013 (step 4); significant security incident under Section 168 ruled out in the example, with reasons (step 5) | data protection officer, security officer | notification under Section 169, notification of the 140 affected persons; assessment recorded in writing |
| Tue 15:00 | initial notification on the BfDI form to BNetzA and BfDI, number of recipients and cause still “not yet known” | data protection officer, approval by management | with detection at 09:30, the deadline would be Wed 09:30 |
| Wed 16:00 | notification of the 140 customers: what happened, contact point, recommendation, no advertising | customer service, approval by management | wrong recipients also asked to delete the records |
| Fri 11:00 | second notification, form completed in full: cause (assignment error in the update), number of persons affected, measures | data protection officer | to both authorities; the deadline of three days after the initial notification would be Fri 15:00 |
| Fri 14:00 | entry in the inventory, check step introduced for billing runs after updates | data protection officer | see entry below |
This is what the entry in the inventory under Section 169(3) can look like, all details invented:
| Field | Entry |
|---|---|
| Number, date of detection | DSV-2026-03, Tuesday 09:30 |
| Circumstances | update of the billing system on Monday, error in assigning itemised call records, sent by e-mail to 140 invoice recipients |
| Data affected | traffic data: numbers of the other parties, date, time and duration of calls; name and customer number |
| Effects | 140 customers whose call data were received by another customer; no indication of further disclosure |
| Notifications | initial notification Tue 15:00, second notification Fri 11:00, each to BNetzA and BfDI |
| Notification of affected persons | yes, Wed 16:00 by letter; reason: itemised call records, disclosed to third parties |
| Assessment under Section 168 | no significant security incident, reasons in the incident log |
| Remedial measures | sending stopped, wrong recipients asked to delete, sample check before every billing run after an update |
Three typical gaps
| Gap | Cause | Effect | Remedy |
|---|---|---|---|
| Notification goes to only one authority | the data protection process follows the GDPR model and knows only one supervisory authority | the notification under Section 169(1) is incomplete, which is subject to a fine under Section 228(2) no. 40 TKG | set BNetzA and BfDI as fixed recipients in the procedure, including for every follow-up notification |
| 72-hour deadline planned | the deadline from Article 33 GDPR is applied to telecoms data | the 24 hours under Regulation 611/2013 are missed | distinguish in the procedure between Section 169 (24 hours) and Article 33 GDPR (72 hours), keep the notification form to hand |
| Service providers do not report | billing, hosting or the customer portal run at third parties, and the contracts contain no duty to inform | the provider learns of the breach late or not at all, while the deadline still runs | add a duty to inform without undue delay to the contracts, name contact persons |
If you want to review your procedures for Section 168 and Section 169 together, start with the status review (stage 1). We have acted as security officers under Section 166 TKG and have drawn up and updated security concepts and agreed them with the Bundesnetzagentur.
Frequently asked questions
Do I have to notify if the data were encrypted?+
Does Section 169 also apply to network operators without their own service?+
What if not everything is known after 24 hours?+
Do I also have to notify under Article 33 GDPR?+
What fine applies to the notification?+
Read more
- Section 168 TKG: Reporting Security Incidents to BNetzA and BSI
- Section 166 TKG Security Concept: German Telecommunications Act
- Section 5 TKG: Am I a Telecom Provider? Roles, Notification
- Section 165 TKG: Protective Measures, Ten Minimum Measures
- Secrecy of Telecommunications: Section 3 TDDDG for Providers
- German Telecommunications Act (TKG): Telecom Security Services
Sources
- Section 169 TKG: data and information security (gesetze-im-internet.de, German) (retrieved 2026-11-06)
- Section 3 TKG: definitions, no. 71 (gesetze-im-internet.de, German) (retrieved 2026-11-06)
- Section 168 TKG: reporting security incidents (gesetze-im-internet.de, German) (retrieved 2026-11-06)
- Section 228 TKG: fines (gesetze-im-internet.de, German) (retrieved 2026-11-06)
- Section 17 Administrative Offences Act: amount of the fine (gesetze-im-internet.de, German) (retrieved 2026-11-06)
- Regulation (EU) No 611/2013 on the measures applicable to the notification of personal data breaches (Official Journal L 173/2) (retrieved 2026-11-06)
- Regulation (EU) 2016/679, General Data Protection Regulation, Articles 33, 34, 95 (Official Journal L 119/1) (retrieved 2026-11-06)
- BfDI: the procedure under Section 169 TKG (German) (retrieved 2026-11-06)
- BfDI: form for notifications under Section 169(1) sentence 1 TKG, as of February 2022 (PDF, German) (retrieved 2026-11-06)
This content provides general technical and organisational information and does not constitute legal advice (no legal services within the meaning of the German RDG).
