Konsultation Customer Consent Management

Beschreibung

Die DSGVO regelt in
Artikel 7, dass für die Verarbeitung und Freigabe von Daten ausdrücklich vorher
eine erteilte Zustimmung durch den Kunden erfolgen muss. Darüber hinaus muss
über den Zweck der Datenverarbeitung informiert werden und dem Kunden jederzeit
die Möglichkeit angeboten werden, seine Zustimmung zu widerrufen.

Ziel ist mittels des
Customer Consent Management transparent, digital und effizient und unter
minimalem Abwicklungsaufwand bei den Verteilernetzbetreibern Prozesse zu
etablieren, die genau die gesetzten Forderungen standardisiert implementieren. Die
automatisierten Customer Consent Management Prozesse adressieren die
erforderliche Einwilligung von Endkunden und die Integration in die
Bestandsprozesse.

Basis für den
Nachrichtenaustausch zwischen den Marktteilnehmern soll hierbei die im Einsatz
befindliche EDA Infrastruktur sein. Ein niedrigschwelliger Zugang soll dabei
für den Kunden einerseits, als auch für Dienstleister andererseits geschaffen
werden. Initiativen zur Standardisierung auf europäischer Ebene und Aktivitäten
zu dem Customer Consent Management in anderen Ländern werden mit aktuellem
Stand berücksichtigt werden.




 
Fristen
Konsultation Beginn18.06.2019 
Stellungsnahmen bis26.07.2019 
Vorauss. Veröffentlichung04.10.2019 
Testphase ab01.04.2020 
Produktivsetzung01.10.2020 
Abschluss
Entscheidung
Konsultation abgeschlossen
 

  
DokumenteKeine Dokumente zugewiesen 

Allgemeine Anmerkungen zu der Konsultation


  
  

Betroffene Prozesse

  
  
  

CM_REQ_ONL (00.99) Consent Management - Online Datenfreigabe

  
ProzessCM_REQ_ONL 
Version00.99 
BezeichnungConsent Management - Online Datenfreigabe 
Gültig von01.05.2019 

Stellungnahmen

AT001002 Wien Energie A****k

Timer für Rückantwort = 72 h bei Dienstleister
Wird hier Arbeitstag (z.B.: 9:00-17:00) bzw. Wochenenden und Feiertage berücksichtigt?

Es sollte einheitlich geregelt sein.

 

Kommentar


 
- Der Schritt BP01.BP13.BP24 (Timer für das Warten auf Rückantwort starten) wird gestrichen und durch eine positive Rückantwort (CMNotification mit neuem ResponseCode) nach Schritt BP01.BP14.BP11 (Datenfreigabeantrag speichern) beim Netzbetreiber ersetzt
- Die Regelung für Fristen sind analog der Wechselverordnung vorgesehen und wird im Konzept beschrieben.

Salzburg AG N****r

BP01.BP13.BP24 & BP01.BP14.BP43

Timer für Rückantwort = 72 h bei Dienstleister

Timer für Endkundenentscheidung = 10 AT bei VNB  => Inwiefern kompatibel?


BP01.BP15.BP11:

Unklar ist, um welche Daten es konkret geht und ob einzelne wählbar sind.

RequestedDatatypes = Auswahlmöglichkeiten einzelner DataTypes oder nur Einwilligung für ein definiertes Set an Daten? Für Dienstleistungen nach § 16a wird es immer ein vom DL definiertes Set an Daten benötigen. Dies sollte auch so ermöglicht werden.

„Versand von DataTyp nicht möglich“ -> ABLEHNUNGSGRUND 174. Wird dieser auch zurückgemeldet, wenn nur ein DataTyp von mehreren nicht lieferbar ist?


BP01.BP14.BP27

Fehlerhandling im VNB-Portal? Kundenfreundliche Lösung gewünscht. Interpretierbarer Ablehnungsgrund sollte angezeigt und (ergänzend) an den DL übermittelt werden.

 

Kommentar


 
- Der Schritt BP01.BP13.BP24 (Timer für das Warten auf Rückantwort starten) wird gestrichen und durch eine positive Rückantwort (CMNotification mit neuem ResponseCode) nach Schritt BP01.BP14.BP11 (Datenfreigabeantrag speichern) beim Netzbetreiber ersetzt
- Eine genaue Beschreibung der RequestedDataTypes wird noch nachgeliefert. Mit einen DataType ist ein Set an Daten gemeint. Z.B. bei GEA alle notwendigen ¼ Profile
- Die Implementierung im Portal obliegt den Netzbetreiber.
- Die Ablehnungsgründe sind definiert, der entsprechende Grund wird im Falle einer Ablehnung mitgeteilt über eine ConsentNotification.

AT004000 A****i

Prozesslogik

-       Timer des Dienstleisters (72h) für die Rückantwort unterschiedlich zu dem Timer für die Endkundenentscheidung (10 Arbeitstage) =>in der Beschreibung erläutern

o   72 Stunden dienen zur Bestätigung oder Ablehnung der Datenfreigabe-Anfrage des Dienstleisters an den Netzbetreiber, bei positiver Antwort ist die Anfrage 10 Arbeitstage gültig für die Antwort des Endkunden an den Netzbetreiber, ab dem nächsten Arbeitstag

-       BP01.BP13.BP26 ist immer notwendig, wenn kein Zählpunkts-ID genutzt wird, Text anpassen, statt „Alternativ“ - Bei der Datenfreigabe-Anforderung ohne Zählpunkt wird eine…

-       Grund für Ablehnung bei bereits übermittelten Daten – ABLEHNUNG_CMQM – „Daten werden bereits übermittelt“

 Fehlende Prozessschritte im Prozessdiagramm

-       Schritt „BP01.BP13.BP26 „Endkunde die Consent-Request-ID mitteilen“ – nach dem Prozessschritt ist eine Nachricht vom Dienstleister an den Endkunden zu senden – auf der Seite Endkunde „Consen t-Request-ID vom Dienstleister empfangen“ in der Darstellung zu ergänzen

-       Schritt „BP01.BP14.BP11 „Datenfreigabeantrag speichern“ – nach dem Prozessschritt ist eine pos. Nachricht an den Dienstleister sinnvoll, da der VNB den rechtmäßigen Empfang bestätigt, ev. mit Gültigkeit, da der Timer dann vom VNB bekanntgeben werden könnte – ev. würde der Dienstleister erst danach die Information an den Endkunden übermitteln, da im Fehlerfall der Kunde keine ID’s mehrfach vom Dienstleister bekommt

-       Ergänzung des zyklischen Datenversands vom VNB an den Dienstleister als Prozessschritt sinnvoll, da dieser Prozess nach der Datenfreigabe gestartet wird (CR_MSG bzw. allgemeiner für zukünftige Datenanforderungen?)

 Voraussetzungen

-       „aktiver Anmeldeprozess“ ist keine gültige Voraussetzung, Anmeldeprozess für den Zählpunkt muss abgeschlossen sein, d.h. der Kunde einen aktiven Vertrag beim Netzbetreiber

 Fristen

-       Die Fristen im Sekundenbereich sollten gelockert werden, da abhängig von T...

...Weiterlesen

 

Kommentar


 
- Der Schritt BP01.BP13.BP24 (Timer für das Warten auf Rückantwort starten) wird gestrichen und durch eine positive Rückantwort (CMNotification mit neuem ResponseCode) nach Schritt BP01.BP14.BP11 (Datenfreigabeantrag speichern) beim Netzbetreiber ersetzt
- Beschreibung und Darstellung für Schritt BP01.BP13.BP26 wird angepasst
- Der Prozess triggert keine Folgeprozesse, daher auch keine Aufnahme in das Prozessdiagramm
- Neuer Ablehnungsgrund „Consent existiert bereits“ anlegen und im Prozess beschreiben
- Voraussetzung für den Prozess ist ein aktiver Netzkunde (ANM muss abgeschlossen sein)
- Die Definition der Fristen wird noch einmal überarbeitet und genau definiert, grundsätzlich sind diese Rückmeldezeiten als Idealfall anzusehen

AT112731 M****r

Die Anfrage vom Dienstleister soll innerhalb von 72 Stunden beantwortet werden, sonst soll der Prozess abgebrochen werden. Der VNB hat aber einen Timer von 10 AT, wo er auf die Rückmeldung des Endkunden wartet. Ist das korrekt? Wenn ja, dann bitte die Beschreibung klarer formulieren, denn hier scheint es doch so zu sein, dass nur 3 Tage gewartet werden muss. Bitte ggf. im Prozessbild die Fristen hinterlegen.

 

Kommentar


 
Der Schritt BP01.BP13.BP24 (Timer für das Warten auf Rückantwort starten) wird gestrichen und durch eine positive Rückantwort (CMNotification mit neuem ResponseCode) nach Schritt BP01.BP14.BP11 (Datenfreigabeantrag speichern) beim Netzbetreiber ersetzt

  
  

CM_REQ_OFF (00.99) Consent Management - Offline Datenfreigabe

  
ProzessCM_REQ_OFF 
Version00.99 
BezeichnungConsent Management - Offline Datenfreigabe 
Gültig von01.10.2020 

Stellungnahmen

Salzburg AG N****r

BP01.BP13.BP02

Schritt 1 fehlt: Angebot & Erbringung der Dienstleistung analog zu Online Datenfreigabe    

 

Kommentar


 
Der fehlende Schritt wird im Prozessdiagramm ergänzt

AT004000 A****i

Fehlende Prozessschritte im Prozessdiagramm

-       Schritt „BP01.BP11.BP40 „Hinweis auf ConsentRequest über hinterlegten Kommunikationskanal senden“ – nach dem Prozessschritt ist eine pos. Nachricht vom VNB an den Dienstleister sinnvoll, da der VNB den rechtmäßigen Empfang bestätigt, ev. mit Gültigkeit, da der Timer dann vom VNB bekanntgeben werden könnte

Voraussetzungen

-       „aktiver Anmeldeprozess“ ist keine gültige Voraussetzung, Anmeldeprozess für den Zählpunkt muss abgeschlossen sein, d.h. der Kunde einen aktiven Vertrag beim Netzbetreiber


Aleksandar Stefanoski
 

Kommentar


 
- Voraussetzung für den Prozess ist ein aktiver Netzkunde (ANM muss abgeschlossen sein)
- Nach Schritt BP01.BP11.BP40 wird eine neue CMNotification mit neuem Responsecode an den Dienstleister versendet

  
  

CM_REV_CUS (00.99) Consent Management - Aufhebung Datenfreigabe durch Endkunden

  
ProzessCM_REV_CUS 
Version00.99 
BezeichnungConsent Management - Aufhebung Datenfreigabe durch Endkunden 
Gültig von01.10.2020 

Stellungnahmen

AT001002 Wien Energie A****k

Zu BP62.BP03.BP01:

Hier sollte eine Einschränkung auf einzelne ZP erwähnt werden. Andernfalls ist es problematisch wenn die Nachricht für alle betroffenen ZP innerhalb kürzester Zeit versendet werden muss.

Zudem sollte eine Mindestfrist bis zum Ende der Datenfreigabe erwähnt werden.


 

Kommentar


 
- Die Prozesse sind immer zählpunktscharf. Beschreibung wird ergänzt und Schemata angepasst
- Versand der RevokeNachricht durch VNB an Dienstleister hat zeitnah zu erfolgen

Salzburg AG N****r

BP62.BP02.BP05: ohne Deadline? BP62.BP02.BP05 bei Datenfreigabe DL hat 24 h

BP62.BP01.BP06: Datenfreigabe-Aufhebung empfangen

„Durch die EDA Infrastruktur wird die Zustellung der Nachrichten auf Kommunikationsebene dokumentiert und eine fachliche Bestätigung des Erhalts der Datenfreigabe-Aufhebung durch den Dienstleister entfällt.“ Widerspricht dies nicht der weiter unten angeführten Beschreibung: „3: Der VNB kann aufgrund der signierten Empfangsbestätigung des Dienstleisters nachweisen, dass die Datenfreigabe-Aufhebung weitergegeben wurde“


 

Kommentar


 
- Versand der RevokeNachricht durch VNB an Dienstleister hat zeitnah zu erfolgen
- Durch die Übertragung mittels EDA Infrastruktur ist eine Zustellung der Nachricht gewährleistet

  
  

CM_REV_SP (00.99) Consent Management - Aufhebung durch Dienstleister

  
ProzessCM_REV_SP 
Version00.99 
BezeichnungConsent Management - Aufhebung durch Dienstleister 
Gültig von01.05.2019 

Stellungnahmen

Salzburg AG N****r

BP62.BP02.BP42 VNB Nutzer über Fehlersituation informieren: Information sollte auch an den DL gehen, der die Kundenbeziehung hat (bzw. der Auslöser zur Datenfreigabe-Aufhebung war)


 

Kommentar


 
Die Information wird mittels Prozessschritt BP62.04 an Dienstleister übermittelt

AT004000 A****i

Fehlende Prozessschritte im Prozessdiagramm

-       Schritt BP62.BP02.BP42 „VNB Nutzer über Fehlersituation informieren“ – nach dem Prozessschritt ist eine Nachricht vom VNB an den Endkunden in der Darstellung sinnvoll, „Endkunde von Fehlersituation informiert“

-       Schritt BP62.BP02.BP45 „Fehlersituation an Dienstleister per Datenfreigabe-Aufhebung mitteilen“ – es fehlt ein zusätzlicher Responsecode für den Feherfall bei ANTWORT_CMS



Aleksandar Stefanoski
 

Kommentar


 
- Die Prozessdarstellung für Schritt BP62.BP02.BP42 wird ergänzt
- Der fehlende Responsecode wird ergänzt

AT112731 M****r

Es gibt keine Fehler-Nachricht und auch keinen passenden ResponseCode. Wie soll hier die Nachricht hier erfolgen? Definition fehlt bzw  wir haben sie nicht gefunden.

 

Kommentar


 
Der fehlende Responsecode wird ergänzt

  
  

CM_REV_IMP (00.99) Consent Management - Implizite Datenfreigabe-Aufhebung durch energiewirtschaftliche Prozesse

  
ProzessCM_REV_IMP 
Version00.99 
BezeichnungConsent Management - Implizite Datenfreigabe-Aufhebung durch energiewirtschaftliche Prozesse 
Gültig von01.05.2019 

Stellungnahmen

AT001002 Wien Energie A****k

Wenn Kunde beim Netzbetreiber optiert, welche Auswirkungen hat das auf diesen Prozess?
Es sollte eindeutig definiert werden.
 

Kommentar


 
Die Information wird mittels Prozessschritt BP62.04 an Dienstleister übermittelt

Salzburg AG N****r

BP62.BP08.BP30 Lieferant meldet Endkunden am Zählpunkt ab (Erweiterung ABM Prozess des VNB):

Bei einem alleinigen Lieferantenwechsel (aber keinen Auszug) muss die Datenfreigabe für den DL unberührt bleiben (vgl. § 16 -> freie Lieferantenwahl bei aufrechtem Vertrag DL <-> Kunde).


 

Kommentar


 
Die Beschreibung wird dahingehend geändert, dass der WIES Prozess nicht mehr erwähnt wird

AT004000 A****i

Prozessauslösend

-       Zu Pkt. 4 Deaktivierung  mind. eines Zählpunkts einer Gemeinschaftserzeugungsanlage verursacht keine Änderung der Kundenbeziehung zw. Netzbetreiber und Endkunden (aktiver Vertrag)

-       Zu Pkt. 5 WIES-Prozess verursacht keine Änderung der Kundenbeziehung zw. Netzbetreiber, Dienstleister und Endkunden (aktiver Vertrag), die Datenfreigabe bleibt unverändert. Falls die Datenfreigabe als Lieferant (Dienstleister) erfolgt ist, beendet ein WIES die Datenfreigabe sinngemäß.

-       Nach Änderung des Messintervalls (Customer Prozess CP_REQ_CMI - Anforderung auf Änderung des Mess-/Übertragungsintervalls) müsste die Datenfreigabe entweder aufgehoben werden oder definierte Änderungen zugelassen sein, da diese der Datenfreigabe entsprechen


Aleksandar Stefanoski
 

Kommentar


 
- Die Beschreibung wird dahingehend geändert, dass der WIES Prozess nicht mehr erwähnt wird
- Prozess CMI hat keine Auswirkungen auf CCM Prozess

AT112731 M****r

Was passiert bei einer Rückabwicklung der ABM (RAABM)? Wird der ursprüngliche Status wieder hergestellt? Aus Sicht des RAABM Prozesses müsste dies so sein.

Bitte hier eine klare Handlungsanweisung formulieren.

 

Kommentar


 
Bilaterale Klärung zwischen den beiden Marktpartnern betrifft auch die Prozesse RAANM und RTANM