Drucksache 17/13000
84 ––
–– 84
grund einer 18-monatigen Übergangsfrist bis zum 23. Dezember 2012 umzusetzen. Somit war ein den Vorgaben
des Gesetzes entsprechender Betrieb der Notrufortung an
Weihnachten 2012 zu erwarten.
Weil die Mobilfunknetzbetreiber bei der Implementierung
technische Probleme feststellten, mussten einige Vorschriften der Notrufverordnung geändert werden (vgl. auch Bundesratsdrucksache 595/12). Obwohl sich alle Seiten um
eine möglichst schnelle Umsetzung bemühten, konnte der
Termin nicht gehalten werden. Da die Änderungen der
Technischen Richtlinie erst spät an die Hersteller der Notrufabfragestellen weitergegeben wurden, muss mit einer
Verzögerung von einigen Monaten gerechnet werden, bis
die übermittelten Standortdaten in den Rettungsleitstellen
ausgewertet werden können. Aus diesem Grunde habe ich
einen zeitlich begrenzten Weiterbetrieb des Notrufortungssystems von AOS bis Ende März 2013 akzeptiert. Ich gehe
davon aus, dass spätestens an Ostern die Notrufortung gesetzeskonform betrieben wird.
Einige Punkte in der TR Notruf sind noch offen. So wird
gefordert, Standortinformationen auch bei Verbindungen
zwischen Netzbetreibern zu übermitteln. Natürlich ist es
sinnvoll, etwa bei der Internettelefonie (VoIP), den Standort des Anrufers zu ermitteln. Durch die mögliche „nomadische“ Nutzung muss der Standort aber nicht mit dem
Wohnort des Nutzers übereinstimmen. Somit muss anhand der IP-Adresse der Internetanbieter ermittelt und um
Auskunft zum Standort befragt werden. Wie dies für beliebige Internetanbieter mit wirtschaftlich vertretbarem
Aufwand und gleichzeitig ausreichender Sicherung gegen
Missbrauch durchgeführt werden kann, lässt die TR Notruf offen. Mir sind noch keine Lösungen bekannt.
In der TR Notruf wird auch ein optionales Verfahren geregelt, wie eine zusätzliche Übermittlung von Standortdaten
durch ein Handy bei einem Notruf erfolgen kann. Diese
Standortangaben, etwa von einer Satellitenortung, können
deutlich genauer sein als die durch ein Mobilfunknetz ermittelten Standorte. Die zusätzliche Übermittlung wäre
durchaus sinnvoll, da so bei einem Rettungseinsatz wertvolle Zeit gespart werden kann. Ein Anrufer sollte jedoch
hierüber informiert sein und zumindest die Möglichkeit haben, diese Übermittlung im Einzelfall auszuschließen.
Weiterhin halte ich die Forderung, dass Notrufanschlüsse
mit dem Leistungsmerkmal „Malicious Call Identification“
auszustatten sind, für problematisch. Dieses für sog. Fangschaltungen verwendete Leistungsmerkmal dürfte aufgrund der generellen Rufnummernanzeige bei Notrufanschlüssen zur Ermittlung von Spaßanrufern nur einen
begrenzten Mehrwert bieten. Regelungen, wie lange hier
Verkehrsdaten gespeichert werden sollen, sucht man in der
Richtlinie vergebens. Somit ist zu erwarten, dass ich mich
weiterhin mit der Notrufthematik zu beschäftigen habe.
6.7
Leitfaden zur Speicherung von
Verkehrsdaten
Vom „Leitfaden zum Datenzugriff“ zum „Leitfaden zur Speicherung von Verkehrsdaten“. Er soll zu einer datenschutzgerechten und einheitlichen Auslegung des TKG führen.
Die Veröffentlichung des „Leitfadens zum Datenzugriff,
insbesondere für den Bereich der Telekommunikation“
BfDI 24. Tätigkeitsbericht 2011-2012
Deutscher Bundestag – 17. Wahlperiode
der Generalstaatsanwaltschaft München, hat großes öffentliches Interesse an der tatsächlichen Speicherdauer
von Verkehrsdaten geweckt. Telekommunikationsanbieter standen in der Kritik, die zu einem Teil berechtigt war.
Diese Thematik wurde deswegen beim „Jour Fixe Telekommunikation“ im Herbst 2011 diskutiert, einem regelmäßigen Treffen des BfDI mit Datenschutzbeauftragten
der Netzbetreiber. Als Ergebnis habe ich gemeinsam mit
der Bundesnetzagentur (BNetzA) einen Leitfaden zur
Speicherung von Verkehrsdaten erarbeitet. Die Netzbetreiber wurden um Kommentierung eines im Frühjahr
2012 vorgelegten ersten Entwurfs gebeten. Der endgültige Leitfaden konnte im Herbst 2012 veröffentlicht werden. Er soll zu einer datenschutzgerechten und einheitlichen Auslegung des TKG – auch im Sinne von „Best
Practices“ – führen und stellt für die Beurteilung des Begriffs der Erforderlichkeit einen Prüfungsmaßstab dar.
Den Leitfaden habe ich in meinem Internetangebot unter
Informationsmaterial | Arbeitshilfen veröffentlicht, von
der BNetzA erfolgte eine Veröffentlichung in deren
Amtsblatt.
De facto sieben Tage
Ein Punkt, der sich fast schon als roter Faden durch den
Leitfaden zieht, ist eine de-facto-Sieben-Tage-Regelung
für die Speicherung nicht abrechnungsrelevanter Verkehrsdaten. Diese hat sich im Laufe der Jahre als praktikabler Weg herausgestellt, um einerseits den datenschutzrechtlichen Überlegungen zu genügen, andererseits aber
den betrieblichen Anforderungen der Netzbetreiber zu
entsprechen.
Damit können zumindest zeitnah gemeldete Störungen
überprüft oder Vergleiche über mehrere Tage gemacht
werden. In einer BGH-Entscheidung (vom 13. Januar
2011, III ZR 146/10) wurde diese Sieben-Tage-Frist für
den Fall der Speicherung von dynamischen IP-Adressen
gestützt. Soweit die Daten allerdings bereits vor Ablauf der
sieben Tage nicht mehr zur Störungserkennung und -beseitigung gebraucht werden, müssen sie vom Unternehmen
gelöscht werden. Insofern handelt es sich um eine
Höchstfrist, von der jeweils im Lichte der konkreten Umstände nach unten abgewichen werden kann.
Ähnlich liegt die Problematik bei der Missbrauchserkennung. Hier dürfen, als Ausnahme von der Zweckbindung,
Daten verwendet werden, die für andere Zwecke gespeichert sind. Für bestimmte Szenarien kann es auch angemessen sein, weitere Verkehrsdaten für begrenzte Zeit zu
speichern. Die entsprechende Formulierung im TKG hat
jedoch zu vielen Diskussionen geführt, aus § 100 Absatz 3
TKG kann jedenfalls keine unumstrittene Handlungsanweisung gewonnen werden. Hier wäre eine Konkretisierung wünschenswert. Einen dritten Anwendungsfall
für die Sieben-Tage-Frist bildet die Speicherung von
Rohdaten. Die Verpflichtung in § 97 Absatz 3 TKG, „unverzüglich“ die für die Berechnung des Entgelts erforderlichen Daten zu ermitteln, kann man zunächst als „sofort“
verstehen. Dabei ist der Tatsache Rechnung zu tragen,
dass die Daten in der Praxis im Regelfall in mehreren
Verarbeitungsstufen in komplexen, oft historisch gewachsenen Datenverarbeitungssystemen verarbeitet werden,
die mit vielen unterschiedlichen Tarifen zurecht kommen