DSAG Arbeitskreis Revision DSAG Arbeitsgruppe Datenschutz Leitfaden Datenschutz SAP ERP Stand 31. Dezember 2013 http://www.sap.de/revis SAP® AG Dietmar-Hopp-Allee 16 D-69190 Walldorf Änderungen und Ergänzungen vorbehalten
DSAG Arbeitskreis Revision
DSAG Arbeitsgruppe Datenschutz
Leitfaden Datenschutz
SAP ERP
Stand 31. Dezember 2013
http://www.sap.de/revis
SAP® AG Dietmar-Hopp-Allee 16 D-69190 Walldorf
Änderungen und Ergänzungen vorbehalten
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 2
IN MEMORIAM
THOMAS BARTHEL
(1950 – 2007)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 3
Einleitung
Der vorliegende Leitfaden Datenschutz SAP ERP soll Datenschutzbeauftragten der SAP-
Anwender Anhaltspunkte für die Vorgehensweise bei der Umsetzung der Anforderungen der
Datenschutzvorschriften bei Einsatz der SAP-Software geben.
Der Leitfaden ist als "Empfehlung" gedacht, nicht aber als "Verbindliche Richtlinie" oder
"Norm". Jegliche Verantwortung für Art, Umfang und Ergebnis der Umsetzung der Daten-
schutzvorschriften verbleibt somit bei der Leitung der verantwortlichen Stelle (Unterneh-
men/Behörde).
Für das Studium dieses Leitfadens werden Grundkenntnisse der SAP-Systeme sowie Kennt-
nisse der handels- und steuerrechtlichen Grundlagen1 und des Bundesdatenschutzgesetzes
(BDSG) vorausgesetzt. Der Leitfaden Datenschutz behandelt Fragestellungen, die bereits in
den SAP Sicherheitsleitfäden oder in anderen Prüfleitfäden des DSAG AK-Revision enthalten
sind, insbesondere aus datenschutzrechtlicher Sicht. In dieser Version wird z.T. auch auf mo-
dulspezifische Besonderheiten, z.B. HCM eingegangen.
Mit SAP ERP wird die klassische ABAP-Welt (ABAP Stack) um die JAVA-Welt (JAVA
Stack) ergänzt. Dieser Leitfaden bezieht sich auf den ABAP-Stack, eine Behandlung der
technisch organisatorischen Maßnahmen und Kontrollen für den JAVA-Stack ist nicht Ge-
genstand dieses Leitfadens.
SAP ERP ist als international eingesetzte Standardsoftware konzipiert. Der Leitfaden berück-
sichtigt die EU Richtlinie 95/46/EG und die deutsche Datenschutzgesetzgebung.
Die Autoren sind Mitglieder der Arbeitsgruppe DATENSCHUTZ im DSAG Arbeitskreis Re-
vision und stellen hiermit ihre Erfahrungen zur Verfügung.
© Copyright 2013 der Autoren:
Herr I. Carlberg FORBIT GmbH., Hamburg
Herr G. Hübner SAP AG, Walldorf
Herr V. Lehnert SAP AG, Walldorf
Frau A. Lichter SAP AG, Walldorf
Herr T. Müthlein GDD e.V. Bonn / DMC Datenschutz Management & Consulting
GmbH & CoKG, Frechen
Frau A. Otto SAP Deutschland AG & CoKG
Herr S. Pieper Kivala-HR Deutschland GmbH
Herr C. Radick K+S IT Services GmbH
Herr K. Redling SAP Deutschland AG & CoKG
Herr A. Reschke Rechtsanwaltskanzlei Reschke, Wiesbaden
Herr T. Rosinsky Robert Bosch GmbH, Stuttgart
Herr P. Schiefer Bayer AG, Leverkusen
Herr H.-J. Schwab SAP AG, Walldorf
1 Z.B. HGB, AO, GDPdU, GoB/GoBS
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 4
Herr G. Siebert Forba Partnerschaft, Berlin
Herr G. Voogd FORBIT GmbH/CArO GmbH, Hamburg
Frau Wellner RWE Service GmbH, Dortmund
Herr Dr. M. Wulf SAP AG, Walldorf
An der 1. bzw. 2. Auflage wirkten außerdem mit:
Herr V. Ahrend Bosch Telecom GmbH, Frankfurt
Herr R. Anhorn Robert Bosch GmbH, Stuttgart
Herr T. Barthel FORBIT GmbH/CArO GmbH, Hamburg
Frau C. Bonni Lausitzer Braunkohle AG, Senftenberg
Herr W. Kilian RWE Energie Aktiengesellschaft, Essen
Herr A. Lenz Rheinbraun AG, Köln
Herr S. Dierschke BASF AG-Zok, Ludwigshafen
Herr W. Geesmann KPMG Deutsche Treuhand-Gesellschaft, Düsseldorf
Herr R. Glagow PWC Deutsche Revision AG, Düsseldorf
Herr F. Glaß PWC Deutsche Revision AG, Düsseldorf
Herr T. Glauch KPMG Deutsche Treuhand-Gesellschaft, Düsseldorf
Herr J. Heck Brau und Brunnen AG, Dortmund
Herr G. Hohnhorst KPMG Deutsche Treuhand-Gesellschaft, Düsseldorf
Herr W. Hornberger SAP AG, Walldorf
Herr A. Kirk Ruhrgas AG, Essen
Herr K. Lorenz Deutsche Bausparkasse Badenia AG, Karlsruhe
Herr H. Miller Geberit Deutschland GmbH, Pfullendorf
Herr Dr. Pötschat BASF AG; Ludwigshafen
Herr E. Schmidt Philip Morris GmbH, München
Herr A. von der Stein RWE Systems AG, Dortmund
Herr U. Ueberschar Mannesmann Arcor AG & Co., Eschborn / Köln
Frau G. Zibulski SAP AG, Walldorf
Die Verantwortung für den Inhalt tragen die Autoren. Die redaktionelle Bearbeitung und das
Layout liegen bei der SAP AG und der DSAG.
Hinweis: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen
Grenzen des Urheberrechts ist ohne Zustimmung der Urheber unzulässig und strafbar. Das gilt insbesondere für Vervielfälti-
gungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Autoren des Leitfadens Datenschutz sind für Kritik, Änderungs- und Ergänzungswünsche dankbar. Dies gilt sowohl
für Vorschläge zur Vertiefung der einzelnen Kapitel als auch für die Nennung von Beispielen aus konkreten Prüfungserfah-
rungen.
Um dem Leser das Antworten zu erleichtern, ist auf der folgenden Seite ein Formular einge-
fügt.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 5
An die Autoren der
Arbeitsgruppe Datenschutz FAX: +49 / 6227 / 358 0 959
DSAG Geschäftsstelle
Altrottstr. 34a
69190 Walldorf
Email: [email protected]
Absender: Name: ...........................................................................................
Funktion: ...........................................................................................
Abteilung: ...........................................................................................
Firma: ...........................................................................................
Anschrift: ...........................................................................................
...........................................................................................
Telefon: ................................... Fax: ............................................
Betr.: Ergänzende Information(en) zum Leitfaden Datenschutz SAP ERP
Ich möchte der Arbeitsgruppe zu folgendem Themenkreis Informationen geben (bitte ankreu-
zen):
( ) Kritische Tabellen/Customizing-Einstellungen
( ) Kritische Objekte
( ) Kritische SAP-Fakten
( ) Beispiele für konkrete Umsetzungsmaßnahmen und Prüfungshandlungen
Ich beziehe mich auf
Leitfaden Datenschutz SAP ERP, Kapitel: ................................................
SAP ERP, Release: ....................................................
Meine Information lautet:
....................................................................................................................................
....................................................................................................................................
....................................................................................................................................
....................................................................................................................................
....................................................................................................................................
....................................................................................................................................
....................................................................................................................................
....................................................................................................................................
.............................................................................................................................
Zur weiteren Erläuterung sind Anlagen beigefügt (bitte ankreuzen):
( ) Ja ( ) Nein
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 6
Inhaltsangabe
1 Einführungsprozess ............................................................................................. 10
1.1 Anforderungen des BDSG an SAP ERP ................................................................ 10
1.1.1 Erhebung, Verarbeitung, Nutzung und Löschung oder Sperrung von personenbezogenen Daten..................................................................................... 10
1.1.2 Übermittlung von personenbezogenen Daten ....................................................... 12
1.1.3 Abrufverfahren ...................................................................................................... 12
1.1.4 Besondere Zweckbindung ..................................................................................... 13
1.1.5 Auftragsverarbeitung ............................................................................................. 13
1.1.6 Unterrichtung des Betroffenen .............................................................................. 13
1.1.7 Rechte des Betroffenen ......................................................................................... 14
1.1.8 Auskunft an jedermann (externes Verfahrensverzeichnis) ................................... 14
1.1.9 Meldepflicht .......................................................................................................... 14
1.1.10 Informationspflicht bei Datenverlusten ................................................................. 15
1.1.11 Verpflichtung der Mitarbeiter auf das Datengeheimnis ........................................ 15
1.1.12 Schulung ................................................................................................................ 15
1.1.13 Maßnahmen zur Datensicherheit ........................................................................... 16
1.1.14 BDSG-Übersichten (Verzeichnis der Verarbeitung / internes Verfahrensverzeichnis) ......................................................................................... 16
1.1.15 Vorabkontrolle ...................................................................................................... 16
1.1.16 SAP Solution Manager als unterstützendes Tool im Einführungsprozess ............ 17
1.2 Mitwirken des Datenschutzbeauftragten bei der Einführung von SAP ERP ......... 17
1.2.1 Datenschutzbeauftragter - Mitglied des SAP-Projektteams .................................. 18
1.2.2 Information des Datenschutzbeauftragten zu den „Meilensteinen“ ...................... 18
1.2.3 Informationsmöglichkeiten für den Datenschutzbeauftragten .............................. 19
1.3 SAP-Fakten ............................................................................................................ 20
1.3.1 Customizing und ASAP-Vorgehensmodell .......................................................... 20
1.3.2 Berechtigungskonzept ........................................................................................... 21
1.3.3 Change Transport System/Change Transport Organizer (CTS/CTO) .................. 22
1.3.4 Schnittstellenverarbeitung ..................................................................................... 23
1.3.5 Job-Auftrags-Verfahren - und Dokumentation ..................................................... 24
1.4 Risiken ................................................................................................................... 25
1.4.1 Nichteinschaltung des Datenschutzbeauftragten bzw. der Arbeitnehmervertreter 25
1.4.2 Nichtbeachtung der SAP-Empfehlungen .............................................................. 25
1.4.3 Nichtberücksichtigung bzw. verspätete Erstellung des Berechtigungskonzeptes . 25
1.4.4 Nicht ordnungsgemäße Anwendung eines Datenverarbeitungsprogramms ......... 26
1.5 Prüfungshandlungen im Rahmen der Einführung / Checkliste ............................. 26
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 7
2 Aufgaben des Datenschutzbeauftragten ............................................................ 29
2.1 Überwachung der ordnungsgemäßen Programmanwendung (§ 4g Abs. 1
BDSG) .................................................................................................................... 31
2.1.1 Einbeziehung des DSB vor und während der Programmentwicklung und -anpassung .............................................................................................................. 31
2.1.2 Prüfung der Datenerhebung und Datennutzung auf Rechtmäßigkeit .................... 31
2.1.3 Auswertung der Protokollierung ........................................................................... 32
2.1.4 Prüfung der Verfahrensdokumentation ................................................................. 32
2.1.5 Mitwirkung bei der Festlegung und Überprüfung des Berechtigungskonzeptes .. 33
2.1.6 Mitwirkung bei der Festlegung des Betriebskonzeptes und der Betreiberorganisation ............................................................................................ 35
2.1.7 Abfassung einer Datenschutzerklärung ................................................................. 36
2.1.8 Überwachung des Korrektur- und Transportwesens unter SAP ERP ................... 36
2.1.9 Kontrollen im laufenden Betrieb ........................................................................... 37
2.2 Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g
und 5 BDSG) .......................................................................................................... 37
2.2.1 Personenkreis, der geschult und verpflichtet werden muss ................................... 37
2.2.2 Inhalt der Anwenderschulungen ............................................................................ 38
2.2.3 Abbildung der Anwenderschulung im SAP .......................................................... 38
2.3 Führen von Übersichten (§ 4g Abs. 2 / § 18 Abs. 2 BDSG) .................................. 39
2.3.1 Verantwortlichkeiten ............................................................................................. 40
2.3.2 Form der Dokumentation ...................................................................................... 41
2.3.3 Das öffentliche Melderegister ............................................................................... 42
2.3.4 Das betriebsinterne Verfahrensverzeichnis ........................................................... 42
2.3.5 Beispiel Melderegister ........................................................................................... 58
2.4 Systemunterstützung .............................................................................................. 60
2.4.1 Auswertungen zur Tabellen- und Feldanalyse ...................................................... 61
2.4.2 Techniken zum Auffinden personenbezogener Daten .......................................... 63
2.4.3 Prüfung der Zugriffsberechtigungen ..................................................................... 65
3 Rechte der Betroffenen und von jedermann ..................................................... 68
3.1 Benachrichtigung und Auskunft ............................................................................. 69
3.1.1 Rechtliche Anforderungen .................................................................................... 69
3.1.2 SAP-Fakten ........................................................................................................... 69
3.1.3 Anforderungen an die Organisation des Datenschutzes ........................................ 70
3.2 Berichtigung, Löschung und Sperrung .................................................................. 72
3.2.1 Rechtliche Anforderungen .................................................................................... 72
3.2.2 SAP-Fakten ........................................................................................................... 73
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 8
3.2.3 Anforderungen an die Organisation des Datenschutzes ........................................ 74
4 Umsetzung der Anforderungen aus § 9 BDSG und Anlage: Technisch-organisatorische Maßnahmen ............................................................................ 76
4.1 Anforderungen ....................................................................................................... 76
4.1.1 Gesetzliche Anforderungen aus § 9 BDSG ........................................................... 76
4.1.2 SAP-Funktionalität zur Abdeckung der gesetzlichen Anforderungen .................. 77
4.2 SAP-Fakten, Risiken und Maßnahmen .................................................................. 82
4.2.1 ABAP-Fakten, Risiken und Maßnahmen .............................................................. 83
4.3 Zusammenfassung der Prüfungshandlungen ....................................................... 115
4.3.1 Anforderungen an die Prüfbarkeit ....................................................................... 116
4.3.2 Prüfung spezieller Regelungen aus vorrangigen Rechtsvorschriften (z.B. aus geltenden Betriebsvereinbarungen zu organisatorisch-technischen Maßnahmen) ............................................................................................................................. 125
4.3.3 Prüfung der Datenschutzmaßnahmen gemäß § 9 BDSG und der Anlage ........... 125
5 Auftragsdatenverarbeitung und konzerninterner Datenaustausch .............. 136
5.1 Abgrenzungen beim Thema Outsourcing und Datenschutz ................................. 136
5.2 Vertragsgestaltung zwischen Auftragnehmer und Auftraggeber ......................... 138
5.2.1 Pflichten des Auftraggebers und Auftragnehmers .............................................. 139
5.2.2 Umfang der Datenverarbeitung / Weisungen ...................................................... 139
5.2.3 Wer erteilt die Weisungen von Seiten des Auftraggebers und an wen sind die Weisungen beim Dienstleister zu richten, in welcher Form erfolgen die Technische und organisatorische Maßnahmen ................................................... 141
5.2.4 Wahrung der Rechte der Betroffenen .................................................................. 142
5.2.5 Pflichten des Auftragnehmers nach § 11 Abs. 4 BDSG, insbesondere die von ihm vorzunehmenden Kontrollen ............................................................................... 142
5.2.6 Kontrollen durch den Auftraggeber .................................................................... 143
5.2.7 Unterauftragnehmer ............................................................................................ 144
5.2.8 Mitzuteilende Verstöße des Auftragnehmers ...................................................... 145
5.2.9 Rückgabe überlassener Datenträger .................................................................... 145
5.2.10 Verarbeitung im Ausland .................................................................................... 146
5.2.11 Wartung und Pflege ............................................................................................. 148
5.3 SAP-Fakten .......................................................................................................... 149
5.3.1 Ausgangssituation ............................................................................................... 149
5.3.2 SAP-Administration ............................................................................................ 150
5.3.3 SAP-spezifische Maßnahmen ............................................................................. 150
5.4 Risiken ................................................................................................................. 153
6 Besondere Themen ............................................................................................ 155
6.1 Datenschutzkonformes Löschen mit dem SAP NetWeaver Information
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 9
Lifecycle Management (ILM) .............................................................................. 155
6.1.1 Datenschutzkonformes Löschen in der Personalwirtschaft (SAP HCM) ........... 155
6.2 Read Access Logging ........................................................................................... 158
6.3 Auditwerkzeuge: Audit Information System und Benutzerinformationssystem ... 159
6.3.1 Audit Information System (AIS) ......................................................................... 159
6.3.2 Benutzerinformationssystem (SUIM) ................................................................. 161
6.4 SOS-Report ( Security Optimization Service ) ..................................................... 162
6.5 SAP GRC (Governance, Risk and Compliance) .................................................. 162
6.5.1 SAP GRC Access Control ................................................................................... 163
6.5.2 SAP GRC Process Control .................................................................................. 165
6.6 SAP TDMS (Test Data Migration Server) ........................................................... 166
7 Glossar ................................................................................................................ 168
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 10
1 Einführungsprozess
Die Voraussetzung für die Anwendung des Bundesdatenschutzgesetzes (BDSG) ist beim Ein-
satz von SAP ERP2 erfüllt, da in allen Modulen personenbezogene Daten automatisiert verar-
beitet werden (vgl. § 1 BDSG in Verbindung mit §§ 12 oder 27 BDSG). Deshalb sind das
Bundesdatenschutzgesetz und andere Rechtsvorschriften zum Datenschutz, z.B. in einer Lan-
desverwaltung das jeweilige Landesdatenschutzgesetz zu beachten. Dieser Leitfaden gilt für
den öffentlichen und den nicht-öffentlichen Bereich. Auf die Besonderheiten der Landesda-
tenschutzgesetze wird in diesem Leitfaden nicht eingegangen.
Da SAP ERP als international eingesetzte Standardsoftware unter betriebswirtschaftlichen
Aspekten konzipiert ist, kann ein anwendendes Unternehmen nicht ohne weiteres davon aus-
gehen, dass für alle angebotenen Datenfelder die Rechtsgrundlagen im Sinne der deutschen
Datenschutzvorschriften gegeben sind.
Es ergibt sich damit die Notwendigkeit für die verantwortliche Stelle (anwendendes Unter-
nehmen) zu überprüfen, ob SAP ERP in der bei ihr vorgesehenen Ausprägung den Anforde-
rungen des Bundesdatenschutzgesetzes und ggf. anderer Vorschriften über den Datenschutz
genügt.
Der Datenschutzbeauftragte (DSB) in seiner Hinwirkungfunktion als auch gegebenenfalls in
seiner Vorabkontrollfunktion sowie Betriebsrat/Personalrat sind daher in die Projektarbeit
einzubeziehen, wobei die Projektverantwortung für die ordnungsgemäße Einführung von SAP
ERP der Projektleitung obliegt.
Auch wenn das BDSG den Anforderungen des harmonisierten Datenschutzrechts in der EU
entspricht, sind die lokalen Besonderheiten der einzelnen EU-Mitgliedsstaaten in Rahmen der
Länder-Rollouts im Rahmen der Projektarbeit in Verantwortung der Projektleitung zu prüfen
und zu beachten.
1.1 Anforderungen des BDSG an SAP ERP
Das BDSG spricht ein grundsätzliches Verbot der Erhebung, Verarbeitung und Nutzung per-
sonenbezogener Daten aus und erlaubt die Datenverarbeitung nur, wenn die im BDSG defi-
nierten Voraussetzungen erfüllt sind. Dieser Grundsatz führt dazu, dass mit der Einführung
des SAP ERP überprüft werden muss, ob die Anforderungen des BDSG und anderer Rechts-
vorschriften angemessen berücksichtigt wurden. Entsprechendes gilt auch für Änderungen im
laufenden Betrieb.
1.1.1 Erhebung, Verarbeitung, Nutzung und Löschung oder Sperrung
von personenbezogenen Daten
Grundsätzlich ist die Erhebung, Verarbeitung oder Nutzung von personenbezogenen Daten
gemäß § 4 BDSG verboten (Erlaubnisvorbehaltsprinzip), es sei denn,
das BDSG erlaubt bzw. verlangt die Verarbeitung oder
2 Im Folgenden umfasst der Begriff SAP ERP im Sinne dieses Leitfadens auch die ABAP-
Komponenten von SAP NetWeaver
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 11
eine andere vorrangige Rechtsvorschrift erlaubt bzw. verlangt die Verarbeitung oder
es liegt eine schriftliche Einwilligung des Betroffenen vor (basierend auf der freien Ent-
scheidung des Betroffenen § 4a BDSG)3.
Die Zulässigkeitskriterien für die Erhebung, Verarbeitung oder Nutzung ergeben sich aus § 4
BDSG in Verbindung mit
§§ 13 und 14 BDSG für die öffentlichen Stellen
§§ 28 bis 32 BDSG für nicht-öffentliche Stellen.
Die Beweislast für die Zulässigkeit trägt die verantwortliche Stelle (das/ die einführende(n)
Unternehmen).4
Der Grundsatz der Datenvermeidung und Datensparsamkeit gem. § 3a BDSG mit dem Ziel,
keine oder so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu
nutzen, ist zu beachten.
Die Rechtsgrundlagen für die Erhebung, Verarbeitung und Nutzung sind im BDSG dif-
ferenziert gestaltet und müssen geprüft bzw. geschaffen werden (z.B. gesetzliche Grund-
lage, Vertrag (etwa Arbeitsvertrag, Betriebsvereinbarung, ...), freiwillige, schriftliche
Einwilligung oder Interessensabwägung).
Die organisatorischen und technischen Maßnahmen zur Nutzung von SAP ERP sind so zu
gestalten, dass nur die erforderlichen personenbezogenen Daten gespeichert und verar-
beitet werden. Dabei ist zu beachten, dass im Auslieferungszustand der Software techni-
sche Maßnahmen nur im geringen Umfang ausgeprägt sind und die organisatorischen
Maßnahmen definiert werden müssen und umzusetzen sind.
Abhängig vom Zweck der Verarbeitung ist mit den Möglichkeiten des Berechtigungskon-
zeptes und anderer Sicherungsmaßnahmen sicherzustellen, dass die Daten nur im Rah-
men der zulässigen Zwecke verarbeitet werden können. Besonderes Augenmerk ist dabei
auch auf das Berechtigungskonzept zu legen, da auch Anzeige-, Download- oder Export-
rechte eine Zweckänderung bedingen können. Für unterschiedliche Zwecke erhobene Da-
ten müssen durch technisch-organisatorische Maßnahmen getrennt verarbeitet werden
können.
Es dürfen nur die Daten vorgehalten werden, die zur Erfüllung der Aufgabenstellung er-
forderlich sind (Verbot der Vorratsdatenspeicherung).
Abhängig vom Zweck der Datenspeicherung (z.B. Abwicklung eines Vertrages) sind die
benötigten Datenfelder festzulegen und im Customizing einzustellen.
Zusätzlich ist die Dauer der Datenspeicherung auf die dem Nutzungszweck entspre-
chende Zeit zu begrenzen, entsprechend festzulegen und für die Löschung der Daten (sie-
he unten 6.1), oder die Sperrung gem. § 35 BDSG zu sorgen (z.B. von Bewerberdaten
oder Festlegung der Speicherungsdauer nach dem Vertragsende und anschließende Lö-
schung). Dabei ist zwischen dem operativen Zweck und weiteren Zwecken (wie gesetzli-
chen Aufbewahrungsfristen, Produkthaftung) zu unterscheiden. Sollten verschiedene
3 Einwilligung im Rahmen des Beschäftigungsverhältnisses sind kritisch zu prüfen, da die
Rechtskommentare die Anwendbarkeit grundsätzlich verneinen
4 Das BDSG kennt kein „Konzernprivileg“, jede beteiligte Rechtseinheit hat die Beweislast für die
Zulässigkeit zu tragen
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 12
Speicherdauern für operative und weitere Zwecke vorliegen sind die Daten nach Entfall
des operativen Zwecks zu sperren. Dies kann über eine Archivierung mit Beschränkung
der Zugriffsrechte geschehen. Eine Aufgliederung der Löschfristen je Personengruppe und
Datenkategorie ist anzustreben, genauso wie prozessuale Vorgaben zur routinemäßigen
Löschung (entsprechend Löschfrist) und adhoc Löschung (wie etwa bei Widerruf der
Einwilligung). Das Löschkonzept besteht dann aus der Übersicht der Löschfristen je Per-
sonengruppe und Datenkategorie, prozessualen Vorgaben zur Durchführung der Löschung
und Verantwortlichen für die Umsetzung und Durchführung der Löschung.5
1.1.2 Übermittlung von personenbezogenen Daten
Grundsätzlich ist die Übermittlung von personenbezogenen Daten verboten. Die Zulässig-
keitskriterien für Übermittlungen ergeben sich aus § 4 b BDSG in Verbindung mit den §§ 15,
16 BDSG für öffentliche Stellen, §§ 28, 28a, 29, 30, 32 BDSG für nicht-öffentliche Stellen.
Es ist sicherzustellen, dass die Zweckbindung der übermittelten Daten auch vom Empfänger
eingehalten wird. Hierzu ist der Empfänger auf die Zweckbindung hinzuweisen. Im Sinn des
BDSG ist auch eine Einsichtnahme/ das Lesen durch eine Person eine Übermittlung. (Auch
die technischen Funktionen zum Markieren, Ausschneiden und Einfügen, zur Bildschirmko-
pie, zum Download und zum Remote-Access (z.B. per TeamViewer oder über MS Lync) sind
unter dem Aspekt der Übermittlung zu betrachten, genauso der Wartungszugriff durch Dienst-
leister mit Sitz in Staaten, die nicht Mitgliedstaaten der Europäischen Union und nicht andere
Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum sind. Gleiches gilt
für den sogenannten pdf-Drucker, da er einen eigenständigen Datenträger darstellt.
Das empfangende System muss den gleichen Datenschutzanforderungen genügen und eben-
falls den für den Datenschutz geltenden Vorgehensweisen und Meldeverfahren unterworfen
werden. Ob sich bei der Übermittlung eine Benachrichtigungspflicht des Betroffenen ergibt,
ist zu prüfen.
Daraus ergibt sich die Notwendigkeit, alle regelmäßigen oder anlassbezogenen Übermittlun-
gen auf ihre Rechtmäßigkeit zu prüfen. Insbesondere bei der Übermittlung von Daten der be-
sonderen Art an Staaten, die nicht Mitgliedstaaten der Europäischen Union und nicht andere
Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum sind, spricht das
BDSG für übliche Zwecke im Firmenkontext ein Verbot aus.
1.1.3 Abrufverfahren
Ein Abrufverfahren darf nur eingerichtet werden, wenn die Voraussetzungen des § 10 BDSG
erfüllt sind.
Sollen personenbezogene Daten von Dritten abgerufen werden können, sind zusätzliche
Maßnahmen zur Sicherstellung der Rechtmäßigkeit des Abrufes und der Datensicher-
heit bei den beteiligten Stellen erforderlich.
5 DIN Deutsches Institut für Normung e.V. "Leitlinie zur Entwicklung eines Löschkonzepts mit
Ableitung von Löschfristen für personenbezogene Daten"
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Extern/Leitlinie_z
ur_Entwicklung_eines_Loeschkonzepts.html
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 13
Insbesondere muss die verantwortliche Stelle gewährleisten, dass mittels geeigneter
Stichproben die Rechtmäßigkeit der Übermittlung personenbezogener Daten festgestellt
werden kann.
1.1.4 Besondere Zweckbindung
Werden zu Zwecken des Datenschutzes, der Datensicherung oder zur Sicherstellung eines
ordnungsgemäßen Betriebes personenbezogene Daten gespeichert (z.B. über UI-
Protokollierung (User-Interface Protokollierung), Logfiles wie System Log oder Security Au-
dit Log oder Accounting-Informationen), sieht das BDSG in § 31 eine besondere Zweckbin-
dung für diese Kontrollinformationen vor.
Es ist zu klären, welche Aufzeichnungen im SAP ERP hierzu gehören und welche Funkti-
onen / Stellen diese Informationen benötigen und die Kontrollfunktionen ausüben.
1.1.5 Auftragsverarbeitung
Werden personenbezogene Daten im Auftrag durch andere Stellen erhoben, verarbeitet oder
genutzt, ist der Auftraggeber für die Einhaltung des BDSG und anderer Vorschriften über den
Datenschutz gemäß § 11 BDSG verantwortlich und muss sicherstellen, dass vor Aufnahme
der Verarbeitung ein schriftlicher Vertrag mit den angemessenes Schutzmaßnahmen beim
Auftragnehmer vorliegt. Der Auftraggeber muss sich von der Einhaltung dieser vertraglich
vereinbarten technisch organisatorischen Maßnahmen beim Auftraggeber vor Beginn der
Überarbeitung sowie danach periodisch überzeugen. Als Hilfestellung kann der Datenschutz-
beauftragte den Auftraggeber auffordern eine Prozessbeschreibung für diesen regelmäßigen
Kontrollprozess inklusive Prüfhandlungen organisatorisch zu verankern.6
Die Einzelheiten und diesbezüglichen Besonderheiten finden sich im Kapitel 5.
Unter dem Aspekt des Cloud Computing oder auch Software as a Service (SaaS) ist beson-
derer Wert auf die Interoperabilitätsvorgaben im Rahmen des vertraglichen Vereinbarungen
und der Prüfbarkeit der Löschung zu legen.
1.1.6 Unterrichtung des Betroffenen
Der Betroffene ist über den Umgang mit seinen personenbezogenen Daten zu unterrichten,
bei der Verwendung der Adressdaten zur Scorewertberechnung ist gemäß § 28b BDSG die
Unterrichtung zu dokumentieren. Auf die Unterrichtung kann nur dann verzichtet werden,
wenn ihm die gesetzlich genannten Umstände bereits bekannt sind.
Grundsätzlich soll die Information bei der Datenerhebung beim Betroffenen erfolgen, z. B. im
Rahmen des Vertragsabschlusses.
Erfolgt die Datenerhebung nicht beim Betroffenen sondern bei einem Dritten, z. B. Übermitt-
lung durch ein Konzernunternehmen, ist er unter den Voraussetzungen des § 33 BDSG zu be-
nachrichtigen, wenn
6 Speicherfristen und Löschkonzept müssen auch mit eventuellen Auftragnehmern vor Auftragsbeginn
kommuniziert und umgesetzt sein
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 14
erstmalig personenbezogene Daten über ihn gespeichert bzw. übermittelt werden oder
von ihm bei öffentlichen Stellen Daten ohne seine Kenntnis gemäß § 19a BDSG erhoben
werden oder
bei nicht-öffentlichen Stellen gemäß § 33 BDSG erstmalig Daten über ihn gespeichert
bzw. übermittelt werden.
Falls demnach eine Benachrichtigung erforderlich wird, muss das Verfahren entsprechend
festgelegt werden.
1.1.7 Rechte des Betroffenen
Es dürfen nur zulässige und inhaltlich korrekte personenbezogene Daten gespeichert werden.
Entscheidungen, die für den Betroffenen eine rechtliche Folge nach sich ziehen oder ihn er-
heblich beeinträchtigen, dürfen nicht ausschließlich auf der Basis einer automatisierten Ver-
arbeitung getroffen werden.
Die Datenspeicherung soll für den Betroffenen transparent sein. Deshalb hat der Betroffene
ein Recht auf Auskunft sowie auf Berichtigung, Löschung, Sperrung und Widerspruch.
Die Anforderungen des § 6 BDSG in Verbindung mit §§ 19, 20, 28b, 34, 35 BDSG sind zu
beachten.
Die verantwortliche Stelle muss in der Lage sein, zur Auskunftserteilung alle personenbe-
zogenen Daten des Betroffenen zuverlässig zu ermitteln! Diese Anforderung korrespon-
diert mit der Anforderung zur Führung einer Übersicht gemäß § 4g Abs. 2 BDSG (Ver-
fahrensverzeichnis).
Eine automatisierte Einzelfallentscheidung, die für den Betroffenen eine rechtliche Folge
nach sich ziehen oder den Betroffenen erheblich beeinträchtigen, ist gem. § 6a BDSG nur
in bestimmten Ausnahmefällen zulässig. Werden diese Ausnahmefälle in Anspruch ge-
nommen, sind sie entsprechend zu dokumentieren.
Die Voraussetzungen, unter denen Sperrungen erforderlich werden, sind zu definieren. Die
Verwendung gesperrter Daten ist zu regeln.
Der Betroffene kann eine Zustimmung zur Verarbeitung seiner personenbezogenen Daten je-
derzeit widerrufen. Da die Zulässigkeit der Verarbeitung auf einer Zustimmung des Betroffe-
nen beruht und diese mit Widerruf entfallen ist, sind die Daten zu löschen (oder zu sperren).
1.1.8 Auskunft an jedermann (externes Verfahrensverzeichnis)
Gemäß § 4g Abs. 2 S. 2 BDSG hat der Datenschutzbeauftragte jedermann auf Antrag Einsicht
in das (externe) Verfahrensverzeichnis zu gewähren. Ist kein Datenschutzbeauftragter bestellt,
dann hat die Geschäftsleitung dies sicher zu stellen.
1.1.9 Meldepflicht
Unter den Voraussetzungen des § 4d BDSG sind automatisierte Verarbeitungen vor ihrer In-
betriebnahme der zuständigen Aufsichtsbehörde zu melden.
Die Meldepflicht entfällt gemäß § 4d Abs. 2 BDSG, wenn die verantwortliche Stelle einen
Beauftragten für den Datenschutz bestellt hat. Stattdessen sind diese Informationen dem
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 15
Datenschutzbeauftragten zur Führung des Verfahrensverzeichnisses zur Verfügung zu
stellen.
Sie entfällt auch gemäß § 4 d Abs. 3 BDSG, wenn personenbezogene Daten für eigene
Zwecke erhoben, verarbeitet oder genutzt werden, hierbei höchstens neun Personen mit
der Erhebung, Verarbeitung oder Nutzung der personenbezogenen Daten beschäftigt UND
entweder eine Einwilligung der Betroffenen vorliegt oder die Erhebung, Verarbeitung o-
der Nutzung der Zweckbestimmung eines Vertragsverhältnisses oder vertragsähnlichen
Vertrauensverhältnisses mit dem Betroffenen dient.
1.1.10 Informationspflicht bei Datenverlusten
Unter den Voraussetzungen des § 42a BDSG ergeben sich bei unrechtmäßiger Kenntniserlan-
gung bestimmter Kategorien personenbezogener Daten unterschiedliche Informationspflich-
ten gegenüber Aufsichtsbehörden und Betroffenen. Dies umfasst nicht nur die im SAP Sys-
tem gespeicherten Daten, sondern alle aus diesen Systemen extrahierten und auf andere Art
und Weise verarbeiteten Daten (z.B. Listen, Office-Dokumente, Mail Attachments). Zusätz-
lich zu den in § 3 Abs. 9 BDSG definierten besonderen Arten personenbezogener Daten –
beispielsweise Schwerbehinderung oder Religionszugehörigkeit – zählen dazu auch Angaben
zu Bank- und Kreditkartenkonten.
1.1.11 Verpflichtung der Mitarbeiter auf das Datengeheimnis
Das BDSG fordert, dass alle Personen, die mit personenbezogenen Daten umgehen7, auf das
Datengeheimnis gemäß § 5 BDSG zu verpflichten sind.
Die Verpflichtung auf das Datengeheimnis ist pro Mitarbeiter zu dokumentieren.
Es ist sicherzustellen, dass beauftragte Firmen, die bei der Einführung von SAP ERP hin-
zugezogen werden, ihre Mitarbeiter auf das Datengeheimnis verpflichtet haben.
1.1.12 Schulung
Der Datenschutzbeauftragte hat die Mitarbeiter gemäß § 4g Abs. 1 Nr. 2 BDSG mit dem
BDSG sowie anderen Vorschriften über den Datenschutz und über innerbetrieblichen Rege-
lungen, die sich aus dem Gesetz ergeben, vertraut zu machen.
Der Datenschutzbeauftragte hat die Projektmitglieder und Anwender, die an der Einfüh-
rung von SAP ERP beteiligt sind, mit den Anforderungen des BDSG vertraut zu machen.
Wesentliche Inhalte der Schulung sind neben der datenschutzkonformen Anwendung des
Verfahrens in SAP ERP auch die Sensibilisierung der Anwender auf Vertraulichkeit bei
der Verarbeitung von personenbezogenen Daten
o am Arbeitsplatz (Einsicht durch am Verfahren Unbeteiligte ist durch geeignete
Gestaltung des Arbeitsplatz, wie Platzierung des Monitors, zu verhindern)
7 Üblicherweise sind die zu verpflichtenden Personengruppen „Personal“, „Vertrieb“, „Marketing“,
„IT“, „Vorgesetzte“, „Sekretariat“
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 16
o auf mobilen Endgeräten (Einsicht durch am Verfahren Unbeteiligte ist durch ge-
eignete Auswahl des Arbeitsorts, der Schutz vor Einsicht bietet sicherzustellen)
o mittels Apps (Einsicht und Mitlesen durch am Verfahren Unbeteiligte ist durch
geeignete Auswahl des Arbeitsorts und des Übertragungswegs, der Schutz vor
Einsicht und Mithören bietet sicherzustellen).
Die durchgeführten Schulungen sind zu dokumentieren.
1.1.13 Maßnahmen zur Datensicherheit
Personenbezogene Daten dürfen nur erhoben, verarbeitet oder genutzt werden, wenn ange-
messene technische und organisatorische Maßnahmen zur Datensicherheit getroffen wurden.
Die Anforderungen der einzelnen Zielsetzungen ergeben sich aus § 9 BDSG und Anlage.
Es sind angemessene Maßnahmen zur Datensicherheit (wie Aktivierung der verschlüssel-
ten Übertragung – SNC Secure Network Communication) zu treffen und mit dem Daten-
schutzbeauftragten abzustimmen.
Gegebenenfalls kann zur Verbesserung des Datenschutzes und der Datensicherheit das in-
stallierte System einem IT-Sicherheitsaudit unterworfen werden.
1.1.14 BDSG-Übersichten (Verzeichnis der Verarbeitung / internes
Verfahrensverzeichnis)
Die öffentlichen Stellen entsprechend zweitem Abschnitt BDSG führen gemäß § 18 Abs. 2
BDSG ein Verzeichnis der eingesetzten Datenverarbeitungsanlagen und haben die Angaben
gemäß § 4e BDSG sowie die Rechtsgrundlagen der Verarbeitung schriftlich festzulegen. Die
verantwortlichen nicht-öffentlichen Stellen entsprechend drittem Abschnitt BDSG haben
dem Datenschutzbeauftragten gemäß § 4g Abs. 2 BDSG eine Übersicht über die in § 4e
BDSG genannten Angaben sowie die zugriffsberechtigten Personen zur Verfügung zu stellen.
Die Wege und Möglichkeiten, mit denen die erforderlichen Übersichten erstellt werden
können, sind festzulegen.
1.1.15 Vorabkontrolle
Unabhängig von der Verpflichtung der verantwortlichen Stelle, den Datenschutzbeauftragten
bei der Verfahrenseinführung /-änderung zu beteiligen, sind Verfahren automatisierter Verar-
beitung mit besonderen Risiken für die Rechte und Freiheiten der Betroffenen, insbesondere
die Verarbeitung besonderer Arten personenbezogener Daten gem. § 3 Abs. 9 BDSG
und/oder Daten zur Leistungs- und Verhaltenskontrolle, gemäß § 4d Abs. 5 BDSG unter den
dort genannten Voraussetzungen vor Beginn der Verarbeitung einer datenschutzrechtlichen
Prüfung zu unterwerfen. Zuständig für die Vorabkontrolle ist der Datenschutzbeauftragte. Ei-
ne schriftliche Dokumentation zur Vorabkontrolle ist zu empfehlen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 17
1.1.16 SAP Solution Manager als unterstützendes Tool im
Einführungsprozess
Der SAP Solution Manager ist die Service- und Supportplattform der SAP, die bei der Ein-
führung und Implementierung von SAP Projekten eine durchgängige Unterstützung bietet.
Sofern der Solution Manager genutzt wird, sollte der Datenschutzverantwortliche auf die da-
rin befindlichen Dokumente zur Beurteilung des Systems zurückgreifen8.
1.2 Mitwirken des Datenschutzbeauftragten bei der Einführung von SAP ERP
Das BDSG verlangt in § 4g Abs. 1 S. 4 Nr. 1 BDSG die rechtzeitige Einschaltung des Daten-
schutzbeauftragten bei Vorhaben der automatisierten Verarbeitung personenbezogener Daten.
Hierzu gehören auch die Einführung, Erweiterung um zusätzliche Module/ Funktionen und
der Releasewechsel von SAP ERP.
Wird SAP ERP in einem Unternehmen eingeführt, ist der Datenschutzbeauftragte frühzei-
tig zu beteiligen, damit er die unter 1.1 aufgeführten Punkte mit beraten kann (wie rechtli-
che Grundlagen in den Verträgen oder Datenlöschkonzept).
8 M. Schäfer, M. Melich: SAP Solution Manager . Galileo Press, Bonn 2006
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 18
Der Datenschutzbeauftragte hat dabei darauf hinzuwirken, dass das Customizing und die
Implementierung des SAP ERP den Anforderungen des BDSG genügt und gegebenenfalls
eine Vorabkontrolle durchzuführen.
Insbesondere dem Grundsatz der Datenvermeidung und Datensparsamkeit gemäß § 3a
BDSG kommt im Rahmen einer SAP ERP-Einführung große Bedeutung zu. Hier kann der
Datenschutzbeauftragte ggf. direkten Einfluss auf die Gestaltung des Systems nehmen.
Über Review des Schulungskonzepts kann der Datenschutzbeauftragte Einfluss auf die
Datenschutz-Sensibilisierung der Anwender nehmen.
Durch Einfordern des Verfahrensverzeichnisses ist die verfahrensverantwortliche Stelle
die das SAP ERP einführt in der Verantwortung zu den relevanten Fragestellungen des
DBSG unter Berücksichtigung des konkreten Verfahrens eine Dokumentation vorzuneh-
men, s. oben 1.1.14.
Bei einem Releasewechsel oder einer funktionalen Erweiterungen hat sich der Daten-
schutzbeauftragte auch von der datenschutzkonformen Durchführung zu überzeugen.
1.2.1 Datenschutzbeauftragter - Mitglied des SAP-Projektteams
Die sachgerechte Beratung der Projektleitung und -mitarbeiter und die Überprüfung der ord-
nungsgemäßen Anwendung (Customizing) durch den Datenschutzbeauftragten, die im § 4g
Abs. 1 S. 4 Nr. 1 BDSG vorgesehen ist, können effektiv erreicht werden, wenn er in der Pro-
jektorganisation in einer beratenden, weisungsfreien Funktion aufgeführt ist.
Wird SAP ERP in einem Unternehmen eingeführt, ist der Datenschutzbeauftragte daher vom
Projektbeginn an zu beteiligen.
1.2.2 Information des Datenschutzbeauftragten zu den „Meilensteinen“
Es liegt in der Verantwortung des Datenschutzbeauftragten zu entscheiden, wann und wie er
die ordnungsgemäße Anwendung von SAP ERP überprüft und welche Unterlagen er hierfür
benötigt. Die Abstimmung, welche Unterlagen er benötigt und wann die Fragestellungen aus
dem BDSG zu beantworten sind, lässt sich nur angemessen unter Berücksichtigung der Ziel-
setzungen und Projektentwicklung festlegen.
Der Datenschutzbeauftragte sollte zu den „Meilensteinen“ die erforderlichen Absprachen mit
dem Projektteam zu den einzelnen Modulen treffen bzw. überprüfen, ob die getroffenen Fest-
legungen den Anforderungen des BDSG genügen.
Die datenschutzrelevanten Projektschritte sind im ASAP-Vorgehensmodell definiert.
Ein Beispiel: ASAP-Vorgehensmodell
2.6 Geschäftsprozessdefinition
2.6.3.1 Anforderungen zu Geschäftsprozessen bestimmen...
2.6.3.3. Anforderungen zum Berichtswesen bestimmen und mit Datenschutzbeauftragten
abstimmen
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 19
1.2.3 Informationsmöglichkeiten für den Datenschutzbeauftragten
Der Datenschutzbeauftragte sollte über Zugriff auf Ressourcen mit folgenden Kenntnissen
verfügen oder sich einen angemessenen Kenntnisstand über folgende Elemente des SAP ERP-
Systems aneignen:
Das Berechtigungskonzept und den Profilgenerator
Die Tabellenverwaltung
Die SAP Programmiersprache ABAP und ABAP Query
ABAP - Advanced Business Application Programming, JAVA
Das SAP ABAP Dictionary
Im ABAP Dictionary sind alle Datenfelder des SAP-Referenzmodells dokumentiert. Eine
Übersicht über die Verwendung eines einzelnen Feldes in der SAP-Datenwelt erhalten Sie
über die Funktion Verwendungsnachweis.
Verfahrensweise bei Extraktion und Auswertung von Daten aus SAP ERP mit Stan-
dardtools wie z.B. Microsoft Excel.
Hilfsmittel zur Gestaltung von Bildschirmmasken (Screen & Menue Painter)
Zur sachgerechten Beratung und Prüfung der ordnungsgemäßen Anwendung von SAP ERP
benötigt der Datenschutzbeauftragte darüber hinaus Unterlagen und Informationen.
Folgende Unterlagen sollten dem Datenschutzbeauftragten generell zur Verfügung stehen:
Komplette SAP ERP-Dokumentation (Doku-CD, Begleitbriefe, Release-Informationen
mit Transaktion SO99, http://help.sap.com)
Der SAP-Einführungsleitfaden und das ASAP-Vorgehensmodell
Der DSAG Prüfleitfaden des AK Revision/AG Audit Roadmap SAP ERP 6.0,(Stand März
2009): http://www.dsag.de
Die SAP Sicherheitsleitfäden werden von SAP zur Verfügung gestellt. Bitte beachten Sie
den SAP-Hinweis 39267 ‚Verfügbarkeit des SAP Sicherheitsleitfadens’
Die SAP-Hilfe (Dokumentations-CD) (http://www.sap.com/germany/aboutSAP/shop/)
Die SAP Dokumentation im Internet (http://help.sap.com)
Zugriff auf den SAP Service Marketplace für die Hinweise und zusätzliche Informationen
(http://service.sap.com) . Der Datenschutzbeauftragte sollte sich alle Dokumente unter den
Stichworten „Datenschutz“, „Datensicherheit und „Sicherheit“ ansehen.
IDES Schulungssystem (IDES - Internet Demo and Evaluation System)
Audit Information System. Das Audit Information System (AIS) ist als Arbeitsmittel für
den Auditor und den Datenschutzbeauftragten gedacht und wird im Kapitel 6.1 „Audit In-
formation System“ beschrieben.
Bitte beachten Sie den SAP-Hinweis 77503 ‚Audit Information System (AIS)’.
SAP-Hinweis 23611 ‚Sicherheit in SAP-Produkten’
SAP-Hinweis 30724 ‚Datenschutz und Sicherheit in SAP Systemen’
SAP Press „Datenschutz in SAP-Systemen“, Galileo Verlag, ISBN 978-3-8362-1421-6
Leitfaden Datenschutz Autor Seite
für SAP-ERP AG Datenschutz 20
1.3 SAP-Fakten
1.3.1 Customizing und ASAP-Vorgehensmodell
Das Customizing wurde in eine Transaktion für die Projektverwaltung (SPRO_ADMIN) und
in eine Transaktion für die Projektbearbeitung (SPRO) aufgeteilt.
Das Customizing dient der unternehmensspezifischen Einstellung des SAP-Systems. Auf-
grund der komplexen Tabellenstrukturen von SAP ERP stellt SAP systemseitig ein Vorge-
hensmodell und Einführungsleitfäden (Grundstrukturen zur Einführung) zur Verfügung. Die-
se sind auch Bestandteil der SAP-Online-Dokumentation.
Das ASAP-Vorgehensmodell bildet zum einen den methodischen Rahmen für den Einfüh-
rungs- und Releasewechselprozess, zum anderen ist es ein operatives Werkzeug zur Un-
terstützung in jeder Phase der Einführung.
Die Projektleitfäden für das SAP ERP-Customizing als unternehmensspezifische Unter-
menge des Vorgehensmodells listen alle Aktivitäten für die Einführung des SAP-Systems
auf und unterstützen die Steuerung und Dokumentation der Einführung.
Die ordnungsmäßige SAP-Einführung hängt wesentlich von der sachgerechten Nutzung der
SAP-Einführungsleitfäden (Implementation Guide - IMG) ab.
Das ASAP-Vorgehensmodell beinhaltet für den Datenschutzbeauftragten wesentliche Punkte,
bei denen er projektspezifisch festlegen sollte, wie er in die Projektentwicklung einzubeziehen
ist.
Beispiele für die Einbeziehung des Datenschutzbeauftragten sind:
Datenschutzrelevante Geschäftsprozesse ermitteln und festlegen
Lifecycle der personenbezogenen Daten ermitteln und Lösch- / Sperrkonzept festlegen
Stammdaten festlegen
Berichtswesen festlegen
Informationsfluss personenbezogener Daten bei Anwendungsschnittstellen, insbesondere
zu anderen Programmen, untersuchen
Informationsfluss der vorgesehenen Berichte und Auswertungen auf Datenschutzgesichts-
punkte hin untersuchen
Datenschutzspezifische Freigabe zu Projektphasen (Meilensteinen) festlegen
Berechtigungskonzept unter Datenschutz- und Datensicherheitsgesichtspunkten beurteilen
Archivierungskonzept, insbesondere im Hinblick auf die Löschungsfristen, beurteilen
(siehe Kapitel 2.3.5 Regelfristen für Löschung)
Testkonzept beurteilen
Datenschutzspezifische Schulungsinhalte und -zeitpunkte festlegen
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 21
Dokumentationsinhalte hinsichtlich datenschutzrelevanter Fragen festlegen
Migration und Altdatenübernahme definieren
Programmanpassungen ermitteln und genehmigen
Das SAP-Standard-Vorgehensmodell und allgemeine Hinweise hierzu finden Sie auf der Do-
kumentations-CD oder dem SAP Marketplace; service.sap.com.
Die einzelnen Themen sollten bei der Planung einer Beteiligung des Datenschutzbeauftragten
durchgegangen und für die Festlegung des eigenen Vorgehens verwendet werden.
Der SAP ERP Customizing Einführungsleitfaden (Implementation Guide (IMG)) ist im Sys-
tem über den Menüpfad zu finden:
Werkzeuge Customizing IMG Projektbearbeitung (SPRO); Schaltfläche
‚SAP-Referenz-IMG’
Die Zuordnung der Customizing-Aktivitäten der modulbezogenen Einführungsleitfäden zum
Vorgehensmodell ermitteln Sie durch die Zuschaltung der Anzeige. Gehen Sie folgenderma-
ßen vor:
1. Rufen Sie die angelegten Projektleitfäden auf:
Menüpfad:
Werkzeuge Customizing IMG Projektbearbeitung
durch Doppelklick auf das jeweilige Projekt und anschließendes Klicken auf die Schalt-
fläche ‚Projekt-IMG’ erhalten Sie den zugehörigen Projektleitfaden angezeigt.
2. Öffnen Sie die jeweiligen Customizing-Aktivitäten bis auf die Ebene der ausführbaren
Funktionen.
Suchen Sie sich die einschlägigen Aktivitäten aus den Leitfäden heraus, die Sie unter Da-
tenschutzgesichtspunkten bearbeiten müssen und identifizieren Sie die modulspezifischen
Einstellungen.
3. Nehmen Sie Kontakt mit den modulbezogenen Projektgruppen auf und sprechen Sie Ihre
Aktivitäten mit ihnen ab.
1.3.2 Berechtigungskonzept
Ein Zugriffsschutzsystem und die Möglichkeit zur Vergabe individueller Berechtigungen
dient unter Datenschutzaspekten im Wesentlichen folgenden Zielen:
dem Schutz vertraulicher Daten vor unberechtigter Erhebung, Speicherung, Kenntnisnah-
me, Übermittlung und Nutzung, dem Schutz der Daten vor unberechtigter, auch verse-
hentlicher Änderung oder Löschung
der Gewährleistung des zweckgebundenen Gebrauchs der Daten
der Nachvollziehbarkeit und Zweckgebundenheit des Zugriffs auf personenbezogene Da-
ten
SAP liefert einen Set von Standardrollen aus, die der Kunde als Vorlage benutzen und hin-
sichtlich der Zuständigkeiten und organisatorischen Ausprägungen an seine individuellen Be-
dürfnisse anpassen kann. Der Umfang dieser Rollen ist aus Funktionssicht definiert, die Rol-
len sind zwingend auf die Sicherheitsbedürfnisse (Funktionstrennung, kritische Berechtigun-
gen) der Organisation anzupassen. Mit jeder Vorlage erhält man ein individuelles Benutzer-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 22
menü. Die Rollenvorlagen sind integrativer Bestandteil der anwendungsübergreifenden
Workplace und Enterprise Portal/Portal-Rollen.
Dem Administrator steht eine erweiterte Funktionsauswahl in der Einstiegstransaktion SAP
Easy Access zur Verfügung. Mit dieser erweiterten Funktionsauswahl ist es ihm möglich, ein-
fach eine der vielen Benutzerrollen einem Benutzer zuzuweisen. Dieser Benutzer erhält bei
der Anmeldung am System automatisch das für seine tägliche Arbeit typische Benutzermenü
sowie die Berechtigungen, die er für diese Arbeit benötigt.
Die hohe Flexibilität des SAP-Berechtigungs- und Benutzerverwaltungskonzepts kann daher
bei unsachgemäßer Anwendung bereits im Rahmen der Einführungsphase zu erheblichen
Verletzungen des Datenschutzes führen. Statt des weit gefassten Standards bei ausgelieferten
Rollen und Profilen etc. muss daher unbedingt unternehmensspezifisch nach dem Prinzip der
minimalen Berechtigung eingegrenzt und angepasst werden.
Da die Ordnungsmäßigkeit des SAP ERP-Systems unmittelbar durch das Verfahren zur
Vergabe von Berechtigungen beeinflusst wird, ist auch das Vergabeverfahren selbst als we-
sentlicher Bestandteil des Zugriffsschutzes anzusehen. Es muss daher organisatorisch defi-
niert revisionsfähig gestaltet sowie ausreichend getestet und spätestens zum Produktionsbe-
ginn verfügbar sein.
Schließlich muss darauf geachtet werden, dass Rollen und ggf. auch Aktivitätsgruppen, Be-
rechtigungen und Profile im Testsystem neu angelegt, geändert oder gelöscht werden und an-
schließend mittels CTS/CTO (Change Transport System/Change Transport Organizer) über
das Qualitätssicherungssystem in die Produktionsumgebung übernommen werden.
1.3.3 Change Transport System/Change Transport Organizer (CTS/CTO)
SAP empfiehlt, in einem produktiven System grundsätzlich keine Änderungen vorzunehmen
bzw. zuzulassen. Alle Änderungen sind daher aus der Test- oder Qualitätssicherungsumge-
bung mit dem sog. Korrektur- und Transportwesen9 in das produktive System zu übernehmen.
Das gesicherte Korrektur- und Transportwesen ist somit wesentlicher Bestandteil eines siche-
ren und ordnungsgemäßen SAP ERP-Systems.
Unter Datenschutzaspekten stehen dabei folgende Zielsetzungen im Vordergrund:
die Registrierung und Dokumentation einschließlich der geordneten Übergabe der Syste-
mentwicklungsumgebungsobjekte (EUO) zwischen den unterschiedlichen SAP ERP-
Systemen oder unterschiedlichen Mandanten innerhalb eines SAP ERP-Systems
die Sicherstellung, dass ausschließlich genehmigte Systemänderungen vorgenommen und
entsprechend nachvollziehbar dokumentiert werden
Aus den vorgenannten Zielen und aus der Tatsache, dass EUO in der Regel systemweite Gül-
tigkeit besitzen, ist zwingend erforderlich, dass mindestens zwei physisch getrennte SAP
ERP-Systeme implementiert werden müssen (Test- und Produktivsystem), wenn personenbe-
zogene Daten aus der Produktivumgebung (z.B. für Massentests) in der Testumgebung ver-
wendet werden, sind diese dort nach Möglichkeit entweder zu anonymisieren oder zu pseudo-
nymisieren. Hierzu kann man sich ggf. geeignete Anonymisierungs-Tools von Drittanbietern
beschaffen. Sollte dies nicht möglich sein, sind auch für das Testsystem und die Testumge-
5 M. Schäfer, M. Melich: SAP Solution Manager . Galileo Press, Bonn 2006
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 23
bung angemessene Maßnahmen zur Datensicherheit zu ergreifen (z.B. zeitliche Begrenzung
der Berechtigungen im Testsystem). Das Berechtigungskonzept ist auf alle Systeme, auch
Entwicklungs- und Testsysteme anzuwenden, insbesondere wenn sie personenbezogene Da-
ten enthalten.
1.3.4 Schnittstellenverarbeitung
Durch die zunehmende Vernetzung von SAP ERP mit anderen Systemen und Plattformen be-
kommt die Schnittstellenverarbeitung eine erweiterte Bedeutung. Neben der technischen Di-
mension ist auch die Überprüfung des Zwecks der Verarbeitung zu hinterfragen. Die Mög-
lichkeiten der Integration von sozialen Plattformen (wie Facebook, Xing, Twitter, …) über
Schnittstellen erfordert eine erneute Prüfung des Zwecks, da die sozialen Plattformen übli-
cherweise nicht für den Betroffenen erkennbar die Daten für die Verarbeitung in SAP ERP
erheben und somit eine Zweckänderung anzunehmen ist, deren Zulässigkeit zu prüfen ist.
1.3.4.1 Datenübernahme
Im Sinne der Datensparsamkeit ist zu entscheiden, welche Daten zu übernehmen sind. Für
diese Daten bietet SAP die LSMW (Legacy System Migration Workbench) als Datenüber-
nahmeverfahren. Dieses Tool ist speziell für die Altdatenübernahme konzipiert worden und
bedient sich der BAPI- oder Batch-Input-Schnittstelle (siehe auch Transaktion LSMW).
Da die Konvertierung aus dem Alt- bzw. Vorsystem mit Programmen außerhalb des SAP
ERP-Umfeldes erfolgt, ist die ordnungsgemäße Umsetzung der Daten (d. h. die Datenkonsis-
tenz) durch geeignete organisatorische Maßnahmen sicherzustellen, um möglichen Manipula-
tionen vorzubeugen.
Für die Datenübernahme wird im SAP ERP auch das Batch-Input-Verfahren10 herangezogen.
Hierbei wird durch ein Schnittstellenprogramm eine sog. Batch-Input-Mappe erzeugt, die da-
bei die Online-Eingabe von Transaktionscodes und Daten simuliert und beim Abspielen die
entsprechenden Berechtigungs- und Plausibilitätsprüfungen durchläuft.
Neben dem Batch-Input-Verfahren bestehen weitere Möglichkeiten der Datenübernahme, z.B.
Remote Function Call (RFC), Internet-Schnittstellen oder PC-Upload und Download11. Diese
werden i.d.R. für Datenübernahmen im lfd. Betrieb (aus vor- oder nachgelagerten Systemen)
eingesetzt.
Alle Schnittstellen sind im Falle der Übermittlung/Weitergabe entsprechend dem § 4e BDSG
zu dokumentieren.
1.3.4.2 PC-Verarbeitung
Up-/Download in der Anwendung (vgl. hierzu u.a. Kapitel 4.2.1.8)
SAP-GUI Scripting ermöglicht es dem Anwender große Datenmengen schnell zu bearbeiten
(einzugeben, ändern) in Form von makro-ähnlich ablaufenden Skripten auf dem PC, damit
vergleichbar zu Job-Auftrag-Verfahren durch Anwender (vgl. hierzu u.a. Kapitel 1.3.5)
10 siehe hierzu ergänzende Hinweise in Kapitel 6 Prüfleitfaden Revision
11 siehe hierzu ergänzende Hinweise in den SAP-Sicherheitsleitfäden
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 24
1.3.4.3 Kommunikationsschnittstellen
Die datenorientierte Schnittstelle Remote Function Call (RFC) ermöglicht SAP- und Nicht-
SAP-Anwendungen, SAP Funktionsbausteine über Rechnergrenzen aufzurufen.
Die Schnittstelle trusted Remote Function Call (tRFC) ermöglicht logische SAP-
Anwendungen über Grenzen von Mandaten und Systemen aufzubauen.
Business Application Programming Interfaces (BAPIs) sind von externen Programmen auf-
rufbare und direkt ausführbare Methodenaufrufe von Business-Objekten.
Diese geschäftsprozessorientierten Standardschnittstellen sind auf eine Dialogkommunikation
ausgerichtet. Sie ermöglichen die Ergänzung des SAP ERP-Kernsystems um Anwendungen,
die speziell im Internet und Intranet entwickelt werden.
BAPIs werden SAP ERP-intern als Funktionsbausteine realisiert, die über RFC aufrufbar
sind.
Application Link Enabling (ALE) ermöglicht die Verteilung von Daten des SAP ERP-
Systems. Über Musterlösungen wird beschrieben, wie ein Unternehmen seine geographische
Datenverarbeitung organisieren und durchführen kann.
Mit ALE/Web lassen sich verteilte Geschäftsprozesse über das Netz quasi zum Geschäfts-
partner verlagern.
Im Rahmen von ALE werden BAPIs für die Integration verteilter Geschäftsprozesse einge-
setzt.
1.3.4.4 SAP-Automation
Mit dieser Schnittstelle lassen sich alternative Oberflächen statt dem SAP GUI einsetzen.
Neben der Kommunikationssicherheit ist zu prüfen, ob über diese Schnittstellen personenbe-
zogene Daten ausgetauscht bzw. übermittelt werden und wer die regelmäßigen Empfänger
sind.
1.3.5 Job-Auftrags-Verfahren - und Dokumentation
Beim Job-Auftragsverfahren steht unter Datenschutzaspekten der Schutz und die Integrität der
Unternehmensdaten und der personenbezogenen Daten im Vordergrund.
Jobs, die ein Operating benötigen und deshalb nicht ausschließlich im Aktionsbereich der
Fachabteilung durchgeführt werden, müssen besonders beachtet werden. Insbesondere bei
diesen Jobs darf keine Ausführung ohne schriftlichen Auftrag erfolgen. Auftraggeber ist i.d.R.
die Fachabteilung.
Bei Jobs, die vom SAP-System generiert werden, wird die Dokumentation automatisch mit
generiert. Beim von Anwendern selbst generierten Jobs (z.B. Batch-Input-Mappen) muss
auch die Dokumentation durch den Anwender selbst erfolgen. Diese Dokumentation sollte
nach einem einheitlichen Schema erfolgen.
Jobs werden nicht über das Korrektur- und Transportwesen vom Test- ins Produktivsystem
übergeben. Sie werden im Produktivsystem neu erstellt.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 25
1.4 Risiken
Bei der Einführung von SAP ERP-Systemen bzw. -Projekten bestehen aufgrund der oben ge-
schilderten SAP-Fakten auch unter Datenschutzaspekten besondere Risiken.
Neben dem Risiko der unsachgemäßen SAP-Einführung durch Fehler beim Customizing und
der Benutzung bzw. Handhabung des Korrektur- und Transportwesens ergeben sich auch aus
Fehlern bei der Erstellung eines Zugriffsberechtigungskonzepts, eines fehlenden Löschkon-
zepts oder einer unvollständigen Datenschutzschulung der Benutzer negative Folgewirkungen
für die vorzusehenden technischen und organisatorischen Maßnahmen oder den Ruf des Un-
ternehmens.
1.4.1 Nichteinschaltung des Datenschutzbeauftragten bzw. der
Arbeitnehmervertreter
Werden der Datenschutzbeauftragte und - soweit vorhanden - die Mitbestimmungsorgane
(Arbeitnehmervertretung) nicht rechtzeitig sowohl bei der Einführung als auch bei allen nach-
folgenden Änderungen eingeschaltet, besteht das Risiko, dass datenschutzrechtliche Anforde-
rungen (u.a. Vorabkontrolle, unzulässige Datenspeicherung und -übermittlung) und Mitbe-
stimmungsrechte bei der Projektarbeit nicht hinreichend beachtet werden.
1.4.2 Nichtbeachtung der SAP-Empfehlungen
Die Nichtbeachtung der SAP-Empfehlungen, insbesondere der SAP ERP-Sicherheitsleitfäden
und die SAP NetWeaver Security Guides (s. http://help.sap.com) kann eine unsachgemäße
und nicht ordnungsgemäße Systemeinführung zur Folge haben.
Hier bestehen insbesondere folgende Risiken:
Zugriffsmöglichkeiten auf Betriebssystem-, Datenbank- und Netzwerkebene
unsachgemäßes Abweichen beim Customizing vom Vorgehensmodell bzw. den Imple-
mentation Guides (IMGs)
unzureichende Dokumentation und Erläuterungen der Customizing-Einstellungen
unzureichende Schnittstellendokumentation (Batch-Input, PC-Download, ggf. Systemer-
weiterungen, Archivierungssysteme)
1.4.3 Nichtberücksichtigung bzw. verspätete Erstellung des
Berechtigungskonzeptes
Während der Einführungsphase des SAP ERP sowie neuer Komponenten ist ein betriebswirt-
schaftliches Berechtigungskonzept zu erstellen. Dies dient als Grundlage u.a. für den Aufbau
von Rollen, mit denen manuell oder mittels des Profilgenerators dann die benutzerspezifi-
schen Berechtigungsprofile erstellt werden.
Das Berechtigungskonzept muss konsequent und konsistent eingesetzt werden. Der jeweils
aktuelle Stand der zugelassenen Benutzer und deren Zugriffsrechte sind zu dokumentieren.
Beim Customizing müssen u.a. SAP-Vorgaben (z.B. Rechte, Startparameter etc.) einschrän-
kend geändert werden. Beim Zugriff auf Tabellen mit dem Data Browser müssen u.a. der Zu-
griff durch die Fachabteilung vermieden werden. Bei einem unzureichenden bzw. zu spät ein-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 26
gesetztem Berechtigungskonzept besteht die Gefahr, dass den Benutzern zu weit reichende
Berechtigungen vergeben werden.
1.4.4 Nicht ordnungsgemäße Anwendung eines
Datenverarbeitungsprogramms
Die Voraussetzung für den ordnungsgemäßen Einsatz von SAP ERP ist u.a. die Beachtung
der Auflagen des BDSG. Konkret sind bei der Einführung eines SAP ERP-Systems unter Da-
tenschutzaspekten folgende Risiken möglich:
Unberechtigtes Mitlesen von Daten auf dem Übertragungsweg
Unberechtigtes Einsehen von Daten auf Grund unzureichender Schutzmaßnahmen am Ar-
beitsplatz oder beim mobilen Arbeiten (RAS) oder Arbeiten über Apps
Unzureichende Datenmodellierung aufgrund unterlassener Vorabkontrolle bei Verwen-
dung von Daten besonderer Art nach § 3 Abs. 9 BDSG
Unzulässige bzw. leichtfertige Handhabung von personenbezogenen Originaldaten im
Testsystem
Fehlende Verpflichtung auf das Datengeheimnis bzw. unzureichende Sensibilisie-
rung/Schulung der Projektmitglieder/Anwender
Unzureichende Dokumentation der personenbezogenen Daten, um den Rechten der Be-
troffenen (Auskunft, Berichtigung, Sperrung und Löschung) und der Verpflichtung zur
Benachrichtigung nachzukommen
Nichtbeachtung des 4-Augen-Prinzips im Rahmen des CTS (Change and Transport Sys-
tem). Unzureichende Festlegung der Transportschichten (Integrations-, Konsolidierungs-
bzw. Belieferungssysteme) in den Tabellen TCENTRAL und TCEDELI innerhalb des
CTS
Unzureichende Absicherung des Transportprogramms (tp, bzw. R3trans) sowie unzu-
reichende Aufbewahrung des Transportprotokolls
Ggf. fehlende Historienführung bei der Übertragung von Programmen bzw. Tabellen in
die Produktivumgebung
Wird das CTS nicht oder falsch eingesetzt, können nicht autorisierte Programme/Objekte
zur unzulässigen Nutzung oder Verarbeitung personenbezogener Daten führen
Unrechtmäßige Kenntniserlangung bei bestimmten Kategorien von personenbezogenen
Daten führt zu unterschiedliche Informationspflichten gegenüber den Betroffenen und der
Aufsichtsbehörde
Die Einschränkung der vorgenannten Risiken dient auch dazu, das Risiko der Unternehmens-
leitung (Straftaten, Ordnungswidrigkeiten und Schadenersatz im Sinne des BDSG §§ 7, 8,
42a, 43, 44) zu reduzieren.
1.5 Prüfungshandlungen im Rahmen der Einführung / Checkliste
Zur Hilfestellung für den Datenschutzbeauftragten und die Projektmitarbeiter ist die nachfol-
gende Checkliste (ohne Anspruch auf Vollständigkeit!) erstellt worden. Wesentliche Frage-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 27
stellungen sind aufgenommen worden. Es wird jedoch empfohlen, diese Checkliste projektbe-
zogen zu überarbeiten und zu ergänzen. (Weitere Details zu Prüfungshandlungen s. Kap. 4)
Folgende Fragen sind pro SAP ERP-Komponente von der Projektleitung zu beantworten:
1. Welche Aufgabenstellungen soll die SAP ERP-Komponente abdecken?
2. Über welche Personengruppen (z.B. Bewerber, Mitarbeiter, Angehörige von Mitarbeitern,
Debitoren, Kreditoren, Fremdfirmenmitarbeiter etc.) sollen Daten gespeichert werden?
3. Welche Geschäftsprozesse sind betroffen?
4. Werden durch die Ausgestaltung der Projektorganisation datenschutzrechtliche Aspekte
des SAP-Projektes rechtzeitig berücksichtigt?
5. Sind dem Datenschutzbeauftragten rechtzeitig ausreichende Unterlagen, insbesondere für
die Vorabkontrolle zur Verfügung gestellt worden?
6. Ist der Datenschutzbeauftragte in die Projektarbeit angemessen eingebunden?
7. Welche personenbezogenen Daten sollen gespeichert werden?
8. Welche personenbezogenen Daten sollen an externe Empfänger aus welchem Grund (re-
gelmäßig, anlassbezogen) übermittelt werden? Liegt bei Empfängern außerhalb der EU
ein angemessenes Datenschutzniveau vor?
9. Liegen die Rechtsgrundlagen zur Erhebung, Verarbeitung und Nutzung personenbezoge-
ner Daten (z.B. gesetzliche Grundlage, Vertrag (etwa Arbeitsvertrag, Betriebsvereinba-
rung, ...), freiwillige, schriftliche Einwilligung oder Interessensabwägung ) vor?
10. Werden Externe mit der Verarbeitung von personenbezogenen Daten beauftragt, bis wann
liefert die verfahrensverantwortliche Stelle dem Datenschutzbeauftragten den Vertrags-
entwurf mit dem Externen, der die technischen und organisatorischen Maßnahmen zur
Einhaltung des Datenschutz beinhaltet?
11. Soll die Möglichkeit eines automatisierten Abrufes von personenbezogenen Daten reali-
siert werden?
- Wenn ja: Wie sollen die Anforderungen zur Sicherstellung des rechtmäßigen Abrufes
und der Datensicherheit realisiert werden?
12. Werden automatisierte Einzelfallentscheidungen vorgenommen?
- Wenn ja: Sind die Voraussetzungen des § 6a Abs. 2 BDSG gegeben?
13. Welche Schnittstellen bestehen zu anderen DV-Anwendungen?
14. Welche Logfiles sind vorgesehen, und wie sollen sie verwendet werden? (z.B. Report-
Protokolldatei in SAP ERP HCM, Tabelle V_T599R und Erstellung des Security Audit
Logs).
15. Wie soll die Zweckbindung gemäß § 31 BDSG eingehalten werden?
16. Welche Dauer der Datenspeicherung ist für die einzelnen Datengruppen unter Berücksich-
tigung der jeweiligen Rechtsgrundlage vorgesehen?
17. Welches Löschungskonzept soll realisiert werden?
18. Wie wird sichergestellt, dass aufbewahrungspflichtige Daten (z.B. 10-Jahresfrist aus steu-
erlichen Gründen) nur zweckgebunden zur Verfügung stehen?
19. Besteht die Notwendigkeit, Personen zu benachrichtigen?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 28
- Wenn ja: Wie und mit welchen Formulierungen soll der Betroffene benachrichtigt
werden?
20. Wie ist das Sicherheitskonzept gestaltet?
21. Sind die Berechtigungen nach dem Prinzip der geringsten Berechtigung vergeben?
22. Sind die SAP-Sicherheitsleitfäden abgearbeitet worden?
23. Werden personenbezogene Daten verschlüsselt übertragen (dies ist für die SAPGUI- und
die SAPLPD-Verbindung mit SNC möglich; RFC-Verbindungen können gesichert wer-
den) und ggf. verschlüsselt gespeichert (dies ist eine Funktion der Datenbank, nicht des
SAP ERP)?
24. Auf welcher Hardware und an welchen Standorten soll SAP ERP installiert werden?
25. Welches DV-Netz soll genutzt werden?
26. Werden beim Einsatz von Internet/Intranet-Techniken entspr. Firewall-Systeme einge-
setzt?
27. Werden alle eingesetzten DV-Systeme zum Betrieb des SAP ERP Systems dokumentiert?
28. Wenn ja: Welche organisatorischen Lösungen sind vorgesehen, um dem Datenschutzbe-
auftragten eine Übersicht zur Verfügung zu stellen?
29. Wann ist dem Datenschutzbeauftragten von der verfahrensverantwortlichen Fachabteilung
eine Verfahrensübersicht zur Verfügung zu stellen?
30. Welche organisatorischen Lösungen zum Datenschutz sind vorgesehen?
31. Sind alle neu hinzugefügten Tabellen, Domänen, Datenfelder und Reports entsprechend
dokumentiert und ausreichend geschützt?
32. Sind alle Personen, die Zugriff auf personenbezogene Daten erlangen können, auf das Da-
tengeheimnis verpflichtet?
33. Wird der Datenschutzbeauftragte bei Systemerweiterungen, System-Upgrades bzw. Re-
leasewechseln zeitnah eingeschaltet?
34. Gibt es in Referenztabellen oder Suchhilfen Auswahlfelder mit ggf. kritischen Inhalten
(z.B. Angaben zur Konfession im Infotyp 0002, Angaben zum Familienstand oder Kin-
dern)?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 29
2 Aufgaben des Datenschutzbeauftragten
Da der DSB in der Regel kein SAP-Spezialist ist, wird er mit unterschiedlichen Mitarbeitern
des Unternehmens zusammenarbeiten. Er wird sich im Rahmen seiner Tätigkeit sowohl mit
Anwendern der Fachabteilungen als auch mit DV-Mitarbeitern austauschen. Ebenso ist eine
Kooperation mit anderen Organisationseinheiten des Unternehmens (z.B. interne Revision,
Compliance oder IT-Sicherheit ) zur Bearbeitung einzelner Themenfelder denkbar.
Um die Vorabkontrolle, die Begleitung des Customizing und die erforderlichen Prüfungs-
handlungen möglichst umfassend durchführen zu können, ist eine ausreichende Ausbildung
des Datenschutzbeauftragten in der Nutzung der relevanten SAP ERP-Funktionen notwendig.
Dies gilt im besonderen Maße für die Programmüberwachung.
Im SAP ERP wird eine Vielzahl von Auditor-Rollen ausgeliefert, die insbesondere den ver-
schiedenen Funktionsbereichen des Audit Information Systems (AIS) zugeordnet sind. Diese
Standardrollen sind nur als Vorlage für die unternehmensspezifischen Rollen des jeweiligen
Anwenderbetriebes gedacht und müssen noch an die betrieblichen Strukturen angepasst bzw.
ausgeprägt werden. Die ausgelieferten AIS-Standardrollen sind unterteilt in Transaktionsrol-
len (definieren ‚nur’ das Benutzermenü) und Berechtigungsrollen (beinhalten die Berechti-
gungen)12.
In der folgenden Tabelle wird eine Auswahl der von SAP angebotenen Standardrollen darge-
stellt die für den Datenschutzbeauftragten relevant sind:
Das Audit Information „Cockpit“ steht kurz vor der Auslieferung; siehe Hinweis 1860243:
AIS_Pilotauslieferung
Rolle Beschreibung Funktionsumfang
SAP_AUDITOR_A AIS - Zentrale
Berechtigungen
Die Berechtigungen der Rolle sind zentral
für das kaufmännische Audit und das Da-
tenschutzaudit
SAP_AUDITOR_ADMIN AIS-
Administration
Diese Rolle beinhaltet Funktionalitäten für
die Administration des AIS
SAP_AUDITOR_DS AIS-Datenschutz Das Menü der Rolle enthält das Dateiregis-
ter zu personenbezogenen Daten
SAP_AUDITOR_DS_A AIS-Datenschutz
(Berechtigungen)
Die Rolle beinhaltet Berechtigungen für das
Datenschutzaudit
SAP_AUDITOR_BA_HR AIS-Human
Ressources
Das Menü der Rolle bietet Funktionalitäten
zum kaufmännischen Audit (Einzelab-
schluss) und zur Personalwirtschaft
(HR/HCM)
SAP_AUDITOR_SA AIS-System Das Menü der Rolle enthält Funktionen zum
System Audit, insbesondere Systemkonfigu-
12 Siehe hierzu auch die SAP Hinweise 754273 und 451960
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 30
Rolle Beschreibung Funktionsumfang
Audit ration, Transportverbund, Entwicklung und
Customizing
SAP_CA_AUDITOR_SY
STEM_DISPLAY
AIS-
Berechtigungen
für System Audit
(Anzeige)
Die Berechtigungen der Rolle ermöglichen
einen Zugang zum System Audit
(Vorsicht: entgegen der SAP Dokumentati-
on keine reinen Leserechte)
SAP_AUDITOR_SA_CC
M _USR
AIS-System
Audit-Benutzer
und
Berechtigungen
Das Menü der Rolle bietet Funktionen zur
Benutzerverwaltung: Benutzer, Berechti-
gungen, Profile und Rollen
Die Rollen sind wie folgt zu finden:
Menüpfad:
Werkzeuge -> Administration -> Benutzerpflege -> Rollenverwaltung (PFCG)
Die SAP-Auditor-Rollen sind sehr spezifisch auf einzelne AIS-Funktionen hin definiert. Die
von SAP ausgelieferten Rollen sind daher im Unternehmen sorgfältig zu analysieren und ggf.
entsprechend anzupassen.
Die explizite „Datenschutzrolle SAP_AUDITOR_DS beinhaltet als Menü zunächst nur die
AIS-Funktionen zum ‚Dateiregister’ des AIS. Eine Kombination mit weiteren Rollen (z.B.
SAP_AUDITOR_DS_A, SAP_AUDITOR_A, SAP_AUDITOR_HR oder
SAP_CA_AUDITOR_SYSTEM_DISPLAY) ist daher mindestens notwendig, um die Tätig-
keit eines Datenschutzbeauftragten im Rahmen der SAP-Prüfung zu unterstützen.
Die Rolle SAP_CA_AUDITOR_SYSTEM_ DISPLAY enthält lt. Beschreibung von 2009
keine Zugriff mehr auf kritische Berechtigungen, die über eine reine Anzeige hinausgehen.
Bei Bedarf ist der zuständige Administrator um Unterstützung zu bitten.
Es wird empfohlen, die SAP-Auditor-Rollen unternehmensspezifisch anzupassen.
Der Datenschutzbeauftragte hat über die für eine Datenschutzsystemprüfung erforderlichen
umfassenden Leserechte im Audit Information System (vgl. Kapitel 6) sowie den direkten
Aufruf der entsprechenden Transaktionen und Reports zu verfügen, allerdings ohne Zugriff
auf Mitarbeiterdaten.
Darüber hinaus kann dem Datenschutzbeauftragten für Echtdatenprüfungen eine zweite auf
die individuellen Zuständigkeiten geschaffene Rolle zugeteilt werden. Letztere ist ggf. zeitlich
befristet zu erteilen.
Eine Bewertung der von SAP ausgelieferten Rollen, eine Neukonzeption von Datenschutzrol-
len (z.B. eine Rolle mit reinen Leserechten) sowie Hinweise zur Ausprägung liefert die Dip-
lomarbeit ‘Entwicklung von Datenschutzrollen für das Audit Information System im SAP
ERP’ 13
13 Otto, Anna: Entwicklung von Datenschutzrollen für das AIS im SAP ERP, VDM Verlag, Saarbrücken
2008 Download der Datenschutzrollen unter: http://www.forbit.de/allgemein/arbeitspapiere.html
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 31
2.1 Überwachung der ordnungsgemäßen Programmanwendung (§ 4g Abs. 1 BDSG)
Der Beauftragte für den Datenschutz wirkt auf die Einhaltung des BDSG und anderer Vor-
schriften über den Datenschutz hin. ... Er hat insbesondere die ordnungsgemäße Anwendung
der Datenverarbeitungsprogramme, mit deren Hilfe personenbezogene Daten verarbeitet
werden sollen, zu überwachen; ....
Dabei sind speziell folgende Punkte von Relevanz:
Zulässigkeit der Datenverarbeitung unter Beachtung des Grundsatzes der Datenvermei-
dung und Datensparsamkeit (§ 3a BDSG). Der ausgelieferte SAP-Standard umfasst auch
Felder und Feldwerte, die je nach Unternehmen, Branche und Anforderung auf ihre Erfor-
derlichkeit zu prüfen sind.
Sicherstellung der Rechte der Betroffenen (§ 6 BDSG in Verbindung mit §§ 19 ff bzw.
§§ 34 ff BDSG)
Verpflichtung auf das Datengeheimnis (§ 5 BDSG)
besondere technisch-organisatorische Vorkehrungen zur Gewährleistung des Datenschut-
zes. Für den Fall, dass besondere Risiken für die Rechte der Betroffenen bestehen, ist eine
Vorabkontrolle zwingend erforderlich (§ 4d Abs. 5 BDSG)
Arbeitnehmerdatenschutz (§ 32 BDSG)
Aus diesem gesetzlichen Auftrag sind die folgenden Verpflichtungen für den DSB bei Einsatz
des SAP ERP-Systems abzuleiten.
2.1.1 Einbeziehung des DSB vor und während der
Programmentwicklung und -anpassung
Die Aufgaben des DSB beziehen sich neben dem Schutz personenbezogener Daten auch auf
die Sicherheit des Gesamtsystems. Hierzu ist es erforderlich, dass der DSB von Beginn an sei-
tens der Projektleitung in die Projekte eingebunden wird. Außerdem sind dem DSB Pro-
grammmodifikationen und Programmschnittstellen offen zu legen. Testverfahren sind ge-
meinsam abzustimmen.
Bereits beim Fachkonzept kann dann die Prüfung auf datenschutzrelevante Aspekte und ent-
sprechende Festlegung der verwendeten Objekte erfolgen.
Das dem Fachkonzept folgende DV-Konzept sollte einen Abschnitt über personenbezogene
Daten enthalten.
Weitere Informationen zu Tabellen, Feldnamen und Datenelementen sowie deren Verwen-
dung in Programmen liefert das ABAP Dictionary (Transaktion SE12) bzw. das Repository
Infosystem (Object Navigator, Transaktion SE84); zu weiterer Systemunterstützung vgl.
Kapitel 2.4.
2.1.2 Prüfung der Datenerhebung und Datennutzung auf Rechtmäßigkeit
Die Überwachungstätigkeit des DSB beschränkt sich nicht nur auf die Verarbeitung (§ 3 Abs.
4 BDSG). Sie umfasst auch das Erheben (§ 3 Abs. 3 BDSG) und das Nutzen (§ 3 Abs. 5
BDSG) personenbezogener Daten. In diesem Sinne ist zunächst die Zulässigkeit der konkre-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 32
ten Datenverarbeitung zu prüfen. Für abhängig Beschäftigte beispielsweise, ob die Erhebung
und Nutzung der Daten für die verschiedenen Phasen eines Arbeitsverhältnisses erforderlich
sind (§ 32 BDSG).
2.1.3 Auswertung der Protokollierung
In SAP ERP stehen eine Vielzahl von Protokollen zu unterschiedlichen Zwecken zur Verfü-
gung (ausführliche Beschreibungen finden sich in den SAP-Sicherheitsleitfäden).
Im Folgenden sind die wesentlichen Protokolle, die dem DSB zur Kontrolle und zur Sicher-
stellung eines ordnungsgemäßen Betriebes zur Verfügung stehen sollten, aufgelistet (Hinweis:
Ein Nachvollzug wesentlicher Protokolleinträge ist mit dem Audit Information System (Sys-
tem Audit, Systemprotokolle und Statusanzeigen möglich). Details sind in Kapitel 4.2.1.9 be-
schrieben:
das Security Audit Log, Transaktion SM20N (Filtereinstellungen SM19)
das Read Access Log (siehe Kapitel 6.2)
Systemprotokoll Syslog, SM21
den Workloadmonitor des CCMS mit Transaktion STAD und ST03N
im Anwendungslog (Transaktionen SLG0 und SLG1)
Business Workflow (Transaktionen SWI2_* und SWI5).
Änderungen betriebswirtschaftlicher Objekte (Transaktion SCDO).
Customizing-Objekte und Tabellenaufzeichnungen (Transaktion SCU3; Reports RST-
BHIST und RSVTPROT)
SQL-Audit (vgl. SAP-Hinweis 115224).
SAP Query-Protokollierung (siehe Abschnitt 4.2.1.9.6)
Protokoll der Reportstarts HCM, Report RPUPROTD
Änderungsbelege HCM-Infotypen, Report RPUAUD00
Eingabeprotokoll Kundendaten (z.B. Batch-Input-Protokolle, Job-Protokolle)
2.1.4 Prüfung der Verfahrensdokumentation
Zur Überwachung der Programmanwendung durch den DSB ist eine aussagefähige Verfah-
rensdokumentation erforderlich, die insbesondere über folgende Punkte Auskunft geben soll:
Aufgabenstellung der Anwendung (i.S. der Zweckbindung), insbesondere mit Hinweisen
auf datenschutzrelevante Elemente
Organisatorische Struktur des Unternehmens mit verantwortlicher Stelle sowie eine even-
tuellen Auftragsdatenverarbeitung bzw. Funktionsübertragung
Technisch-organisatorische Maßnahmen gemäß Anlage zu § 9 S. 1 BDSG
Zugriffsberechtigungen nach Art und Umfang auf personenbezogene Objekte (z.B. Daten,
Programme, Berichte)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 33
Verwendungsnachweis der personenbezogenen Objekte in Programmen, insbesondere für
Daten der besonderen Art § 3 Abs. 9 BDSG
Berechtigte interne und externe Empfänger der von den Anwendungsprogrammen erzeug-
ten Daten nach Art und Umfang und unter dem Aspekt der Datentrennung.
Darstellung der Programmabläufe. Sicherung der Datenbestände und der verwendeten
Programme. Aufstellung der aktivierten BAdI-Erweiterungen.
Lösch- und Sperrkonzept sowie die Archivierung (Abgrenzung von operativer Nutzung
und ‚Aufbewahrungs-Nutzung’)
Seitens SAP werden Hilfestellungen zur Verfahrensdokumentation bereitgestellt. Mit dem
Report RSCRDOMA können im Audit Information System z.B. die ‚Dateiregister-
Funktionalitäten’ zur Analyse der verwendeten personenbezogenen Domänen genutzt werden.
Ausführliche Hinweise zu weiteren Systemfunktionen finden sich insbesondere in den Ab-
schnitten 2.3.3 ff und 2.4.
2.1.5 Mitwirkung bei der Festlegung und Überprüfung des
Berechtigungskonzeptes
Der DSB ist an der Erarbeitung eines organisatorischen Rahmens zur Ausgestaltung des Be-
rechtigungskonzeptes beratend zu beteiligen. Diese Beteiligung kann dazu beitragen, den spä-
ter notwendigen Aufwand bei einer Vorabkontrolle zu reduzieren.
Das Berechtigungsrahmenkonzept hat verbindliche Aussagen zu enthalten über
den Geltungsbereich (verantwortliche Stelle/n)
ein System- und Mandantenkonzept für den genutzten SAP-Verbund
die Rahmenbedingungen; u.a. Verantwortungen für die Wartung und Pflege des SAP-
Systems einschließlich Festlegung der Customizing-Aufgaben und der hierfür benötigten
Berechtigungen XE "Berechtigungen" ; Regelungen zur Änderung von Systemobjekten,
wie insbesondere Repositoryobjekte (Änderungs-, Test- und Freigabeverfahren ein-
schließlich der Übernahme in die Produktion)
die fachlich-organisatorische Ausgestaltung des rollenspezifischen Konzepts
- möglichst arbeitsplatzbezogene und nur in begründeten Ausnahmefällen individu-
elle Ausgestaltung
- funktionaler Aufbau
- Prinzip der minimalen bzw. adäquaten Berechtigungsvergabe
- Kontrollierbarkeit im Sinne des BDSG und einer Revisionsfähigkeit
- Umsetzung der Anforderungen an die Zweckbindung (§ 31 BDSG) und Vertrau-
lichkeit für die besondere Art von Daten (§ 3 Abs. 9 BDSG) und der Datensiche-
rung im Sinne des § 9 BDSG und seiner Anlage
- Regelung für die Kommunikation über RFC-Bausteine und die ALE-Funktion
- Umsetzung der Vertraulichkeit im Druckerkonzept sowie Nutzung der Download-
Funktion und des Druckens in .pdf-Dokumente mit Versand per email.
die systemtechnische Ausgestaltung
- Grundsätze zur Nutzung der zentralen Benutzerverwaltung
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 34
- Regelungen für das Deaktivieren der Berechtigungsprüfung, für die Pflege der
HR-Berechtigungsobjekte, für die Nutzung von Funktionsbausteinen, die die Be-
rechtigungsprüfung deaktivieren und für Zugriffe auf die Datentabellen an den Be-
rechtigungsprüfungen in den „logischen Datenbanken“ vorbei. Regelung für die
Nutzung des Berechtigungsobjektes P_ABAP, das für Programme die HR-
Berechtigungen reduziert bzw. ausschaltet.
- Umgang mit (Standard-) Rollen und Standardprofilen (Hinweis: keine Verwen-
dung von Standardprofilen (=Auslieferungsprofile)
- Festlegung von Restriktionen einzelner Berechtigungen bezüglich der SOD (Seg-
regation of Duties und der Datentrennung (Hinweis: Berücksichtigung aller rele-
vanter Systeme und Mandanten)
- Realisierung des dazugehörigen organisatorischen Konzepts
- Trennung von kritischen und unkritischen Transaktionen
die Anforderungen an eine dem Zweckbindungsprinzip angemessene Abbildung der Un-
ternehmensorganisation(en) auf die SAP-Struktur/Organisationsebene von Systemen,
Mandanten, Buchungskreisen, Werken, Personalbereiche etc. Die Nutzung eines Mandan-
ten für mehrere Unternehmen ist eine Auftragsdatenverarbeitung und erfordert zusätzliche
Aufwendungen in den datenschutzkonformen Betrieb und in die Datentrennung.
ein Verfahren zur Klassifikation und Pflege von Berechtigungsgruppen von ABAP-
Reports und Tabellen und von Query-Benutzergruppen
die Namenskonventionen; Konventionen zur Benennung von Benutzerstammsätzen (keine
Namen ohne Personenbezug), Benutzergruppen, Rollen sowie anderer relevanter SAP-
Objekte (einschließlich Beschreibung begründeter Ausnahmen); Namensregeln für unter-
schiedliche Rollen wie Lese-Rollen, Rollen mit Zugriff auf bestimmte Organisationsein-
heiten, Transaktionsrollen etc..
Die Pflege der strukturellen Berechtigungen und der Zuordnung der Benutzerkennung zur
Personalnummer ( ITY 0105 und STY 001)
die Einrichtung von Notfall-Usern
die Festlegung der Berechtigungen für Externe und deren Kontrolle
der Umgang mit Sonder-Usern wie SAP*, DDIC, SAPCPIC, EarlyWatch, TMSADM,
SAPSUPPORT, WF-BATCH.
den Aufbau der Dokumentation; u.a. eindeutige Verantwortlichkeiten für die Veränderung
des Konzeptes bei notwendig werdenden organisatorisch-funktionalen Anpassungen
Konventionen für Nicht-Produktivsysteme, die Testdaten mit echten Daten oder wichtige
nachweispflichtige Dokumentationsbestandteile enthalten
Regelung für die Vergabe von Profilen (ohne Profilgenerator)
Regelungen für Berechtigungsprüfung bei der Nutzung von BAdI’s; insbesondere auch
für die BAdI’s, die die Wirkung der HR-Berechtigungsobjekte ändern.
Es lassen sich folgende Grundsätze ableiten:
Die Fachabteilungen/-bereiche sind für die Sicherheit ihrer Daten und daher auch für den
wirksamen Zugriffsschutz verantwortlich. Es sind regelmäßige Kontrollen der Angemes-
senheit der vergebenen Berechtigungen durch die Datenverantwortlichen vorzusehen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 35
Die Benutzerverwaltung ist möglichst nahe beim Benutzer wahrzunehmen.
Die Administration des Berechtigungsverfahrens sollte auf mehrere Stellen, Organisati-
onseinheiten oder Mitarbeiter verteilt und entsprechend dokumentiert werden (Funktions-
trennung zwischen Erstellen, Zuordnen und Kontrollieren/Prüfen).
Die Vergabe von Nutzerkennungen hat nachvollziehbar zu erfolgen (Vergabe von Berech-
tigungen im System ausschließlich nach Freigabe durch die Verantwortlichen), und es
müssen zeitnahe Kontrollen bzgl. der Gültigkeit von Benutzerkennungen vorgenommen
werden.
Benutzer dürfen auf Basis des fachlichen Rollenkonzeptes nur die Berechtigungen erhal-
ten, die sie für ihre Aufgaben zwingend benötigen.
Die Berechtigungen privilegierter Benutzer sollten fachlich und zeitlich eingegrenzt wer-
den (s. Kap. 4.2). Notfall-User sind nur in Notsituationen zu aktivieren, deren Gebrauch
ist mit dem Security Audit Log (SM20) oder anderen entsprechenden Tools zu protokol-
lieren.
Für Betriebsfremde und befristet Beschäftigte wie auch für den Remote Support sind die
Rechte und der Gültigkeitszeitraum angemessen zu begrenzen (vgl. SAP NetWeaver Si-
cherheitsleitfaden).
Anwendungsbezogene Berechtigungen für Entwickler sind grundsätzlich auf die Entwick-
lungssysteme zu beschränken.
Um bestehende Berechtigungskonzepte zu überprüfen und insbesondere Regeln für die
Vergabe von kritischen Berechtigungen zu definieren, können SAP Lösungen wie das Audit
Information System oder GRC Access Control verwendet werden (Details siehe Kapitel 6).
2.1.6 Mitwirkung bei der Festlegung des Betriebskonzeptes und der
Betreiberorganisation
Der DSB sollte rechtzeitig an der Erarbeitung eines organisatorischen Rahmens zur Ausge-
staltung des Betriebskonzeptes beteiligt werden. Unter einem Betriebskonzept wird hier die
grundlegende Einrichtung des SAP-Systems auf einem oder mehreren Servern und unter Ein-
beziehung der Kommunikationseinrichtungen, der Netzwerke, des Betriebssystems und des
Datenbankmanagements verstanden.
Dazu sollte der DSB frühzeitig Empfehlungen abgeben, die den Sicherheitsstandard auf den
verschiedenen Ebenen festlegen, der notwendig ist, Manipulationen und ungerechtfertigte
Zugriffe auf personenbezogene Daten zu verhindern.
Hierzu könnten Empfehlungen zu ausgewählten System- und Profilparametern ebenso gehö-
ren wie die Mitwirkung des DSB bei der Festlegung des Sicherheitsmanagements, z.B. bei
Prozessdefinitionen für Sicherheits- und Datenschutzanforderungen.
Eine ausführliche Beschreibung der hierbei relevanten Themen findet sich in den SAP-
Sicherheitsleitfäden. Hierbei wird z.B. folgendes Thema beschrieben:
Alleiniger Nutzer der Datenbank ist das SAP-System
Es ist darauf zu achten, dass auf die Datenbank nicht von unter dem SAP-System liegen-
den Schichten (wie etwa der Datenbank selbst oder dem Betriebssystem) zugegriffen
wird. Ansonsten könnte der SAP Berechtigungsschutz umgangen werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 36
Es darf nur ein sehr eng begrenzter Kreis von Administratoren Zugriff auf Datenbankta-
bellen und SAP-Daten auf Betriebssystemebene erhalten.
Für den Betrieb eines SAP ERP-Systems wird im Regelfall eine Betreiberorganisation (BO,
verantwortlich für die spezifische Administration des SAP ERP-Systems) notwendig werden,
die insbesondere an Gewicht gewinnt, wenn mehrere Unternehmen/Behörden über ein System
abgewickelt werden sollen.
Die Betreiberorganisation kann dabei zentral oder dezentral oder durch eine Kombination von
beiden Alternativen organisiert werden.
Den Vorteilen einer dezentralen Betreiberorganisation wie die Nähe zum Anwender und
die flexible organisatorische Zuordnung der BO in den Unternehmen/Behörden oder die
Gewährleistung der Harmonisierung der Arbeitsabläufe stehen die Nachteile einer höhe-
ren Abstimmung der gesellschaftsübergreifenden Aktivitäten und operativen übergreifen-
den Fragestellungen sowie ein tendenziell höherer Personalbedarf als in einem rein zentra-
len Ansatz gegenüber.
Bei einem zentralen Ansatz ist eine eindeutige Kompetenzregelung mit klarer Organisati-
onsstruktur und schneller Entscheidung bei Konfliktfällen möglich. Allerdings kann die
Flexibilität der über das SAP-System abgewickelten Unternehmen/Behörden einge-
schränkt bzw. die Durchsetzung von gesellschaftsindividuellen Anforderungen bei über-
greifenden Einstellungen schwierig sein. Auch können Interessenkonflikte bei der Leitung
der BO nicht ausgeschlossen werden.
Der DSB hat insbesondere darauf zu achten, dass durch die Betreiberorganisation die Belange
des Datenschutzes hinsichtlich Vertraulichkeit und Sicherheit von personenbezogenen Daten
gewährleistet bleiben und bei einem zentralen Ansatz vertragliche Regelungen zwischen der
BO und den Unternehmen/Behörden den Datenschutzanforderungen genügt – bspw. die in §
11 BDSG verlangten Vertragsinhalte und Nachweise für die Auftragsdatenverarbeitung.
2.1.7 Abfassung einer Datenschutzerklärung
Sofern Dritten ein Internet-Zugang auf das SAP-System gewährt wird, ist der DSB an der Er-
stellung einer Datenschutzerklärung zu den anfallenden Geschäftsprozessen zu beteiligen.
Die Nutzer sind zu Beginn des Nutzungsvorgangs über Art, Umfang und Zwecke der Erhe-
bung sowie die Verwendung personenbezogener Daten und deren Verarbeitung zu unterrich-
ten, sofern eine solche Unterrichtung nicht bereits erfolgt ist (§ 13 Abs. 1 S. 1 TMG).
Diese Erklärung ist als vertrauensbildende Maßnahme zu verstehen und soll den Geschäfts-
partner in verständlicher Form über getroffene Standardmaßnahmen zum Schutz seiner Pri-
vatsphäre (Vertraulichkeit, Integrität, Authentizität) informieren. Eine Hilfestellung bietet der
OECD Privacy Statement Generator unter folgender URL:
http://www.oecd.org/sti/privacygenerator
2.1.8 Überwachung des Korrektur- und Transportwesens unter SAP
ERP
Um Integrität und Verfügbarkeit des Produktivsystems zu schützen, ist eine Trennung in ver-
schiedene Systeme notwendig, wobei unter Sicherheitsaspekten mindestens eine Dreiteilung
in Entwicklungs-, Integrations- und Produktivsystem zu empfehlen ist. Die drei Systeme sind
über das Korrektur und Transportsystem (Change & Transport System) miteinander verbun-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 37
den. Eine Beschreibung der hierbei zu ergreifenden Schutzmaßnahmen findet sich in den SAP
Sicherheitsleitfäden.
Beispielsweise wird darauf hingewiesen, dass - zur Vermeidung von unbefugtem Einschleu-
sen von Programmen oder Daten über das SAP ERP-Transportsystem in das Produktivsystem
- eine Abschottung gegenüber Test- und Entwicklungssystemen erforderlich ist. Es wird emp-
fohlen, den produktiven Applikations- und Datenbankrechner ausschließlich der SAP ERP-
Anwendung zuzuordnen und aus Sicht des Netzwerkes über ein eigenes Transportsystem zu
verfügen.
Der DSB hat darauf zu achten, ob/wie Kopien von personenbezogenen Daten in Nicht-
Produktivsysteme transportiert werden bzw. Benutzer- und Berechtigungswerte aus vorgela-
gerten Systemen in das Produktivsystem gelangen, ohne inhaltlich abgestimmt zu sein.
Hinweis: Hierbei ist ein Datenschutz gerechtes Entsorgungskonzept für Test- bzw. nicht mehr
benötigten Produktiv-Output (z.B. Papier, Datenträger) festzulegen (z.B. DIN 66399).
2.1.9 Kontrollen im laufenden Betrieb
Zur Überwachungsaufgabe des DSB gehören sowohl regelmäßige als auch unangemeldete
Kontrollen und Stichproben im Hinblick auf die Organisation des Betriebsablaufes, die not-
wendigen Funktionstrennungen und die Handhabung des Zugriffsberechtigungskonzeptes als
auch die Auswertung der Logfiles. Vergleiche hierzu auch die Bemerkungen zu den Zugriffs-
rechten des DSB zum Security Audit Log (Kapitel 4.2.1.9.1) und zum Audit Information Sys-
tem in Kapitel 6.Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g
und 5 BDSG).
2.2 Schulung der Anwender mit Verpflichtung auf das Datengeheimnis (§§ 4g und 5 BDSG)
2.2.1 Personenkreis, der geschult und verpflichtet werden muss
Bei Aufnahme der Tätigkeit sind die bei der Erhebung, Verarbeitung und Nutzung personen-
bezogener Daten tätigen Personen zu schulen (§ 4g Abs. 1 S. 4 Nr. 2 BDSG) und auf das Da-
tengeheimnis zu verpflichten (§ 5 BDSG). Dabei handelt es sich im Wesentlichen um folgen-
den Personenkreis:
Mitarbeiter in Rechenzentren / IT-Mitarbeiter
Mitarbeiter in Fachabteilungen mit personenbezogenen Daten, z.B.
- Personalabteilung, Lohn- und Gehaltsabrechnung, Zeitwirtschaft
- Verkauf, Marketing, Werbung
- Einkauf
- Controlling
- Compliance
- Boten
- Projektmitglieder
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 38
Zu verpflichten sind auch Teilzeitkräfte und Auszubildende / Praktikanten. Betriebsratsmit-
glieder fallen ebenfalls unter das Datengeheimnis des § 5 BDSG.
Mitarbeiter von Fremdfirmen, z.B. externe Berater, die Zugriff zu personenbezogenen Daten
haben, müssen auf das Datengeheimnis verpflichtet sein. Der Datenschutzbeauftragte kann
die Verpflichtung dieser Mitarbeiter nicht selbst vornehmen, er sollte sich aber die Verpflich-
tung vertraglich zusichern lassen und deren Einhaltung kontrollieren.
2.2.2 Inhalt der Anwenderschulungen
Der Anwender soll durch die Schulung mit den Vorschriften des BDSG und allen für die
Fachaufgabe einschlägigen Datenschutzvorschriften vertraut gemacht werden. Die Anwen-
derschulung soll allgemeine Informationen zum Datenschutzrecht und auf den jeweiligen Tä-
tigkeitsbereich abgestimmte Hinweise geben, insbesondere zu Datensicherheit und Ord-
nungsmäßigkeit der Datenverarbeitung. Ziel der Schulung ist es, den einzelnen für daten-
schutzgerechtes Verhalten am Arbeitsplatz zu befähigen.
Neben oder als Ergänzung zu Präsenz-Schulungen können auch PC-gestützte oder Web-
basierte Anwenderschulungen verwendet werden, , beispielsweise als Basis-Schulung oder
auch zur Vertiefung des Wissens.
Nach erfolgter Schulung sind die Teilnehmer auf das Datengeheimnis schriftlich zu verpflich-
ten. Diese Verpflichtungserklärung (Anlage 8.1) sollte Bestandteil der Personalakte werden.
Empfehlenswert ist es, jedem Schulungsteilnehmer die entsprechenden Auszüge aus dem
BDSG sowie ein Merkblatt zum Umgang mit personenbezogenen Daten (Anlage 8.2) auszu-
händigen.
Als Beispiel kann der SAP-Hinweis 35493, Verpflichtung Datenschutz und Geheimhaltung,
dienen.
2.2.3 Abbildung der Anwenderschulung im SAP
2.2.3.1 Anwenderschulung über Infotypen “Belehrungen” oder
“Qualifizierungen”
Für HCM-Anwender besteht die Möglichkeit, die Anwenderschulung mit Verpflichtung auf
das Datengeheimnis im SAP ERP-System im Personalstammsatz zu hinterlegen.
Vom Datenschutzbeauftragten bzw. von der Personalabteilung kann die Schulung zum Daten-
schutz folgendermaßen eingetragen werden:
Menüpfad:
Personal -> Personalmanagement -> Administration -> Personalstamm -> Pflegen
(PA30).
Verwendet werden kann der Infotyp 0035 (Belehrungen) oder die Qualifikation im Profil ei-
ner Person in der Personalentwicklung (durch Aufruf Infotyp 0024; Achtung: hierzu muss im
Customizing der Schalter PLOGI APPRA in der Tabelle T77S0 auf 1 stehen).
Der Infotyp “Qualifikationen” greift auf den Qualifikationskatalog zurück. Darin muss dann
im Rahmen des Customizing die Anwenderschulung aufgenommen werden.
Menüpfad:
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 39
Personal -> Personalmanagement -> Personalentwicklung -> Einstellungen -> lau-
fende Einstellungen -> Qualifikationskatalog bearbeiten (OOQA)
Der Qualifikationskatalog hat eine Baumstruktur. Die Datenschutzschulung kann z.B. unter
dem Zweig “rechtliche Grundlagen” angelegt werden.
Mit dem Report RHSTRU00 erfolgt die Strukturauswertung des Qualifikationskataloges.
Über den Report RHXQALIF (Qualifikation eines/mehrerer Teilnehmer) lässt sich leicht
auswerten, wer bereits auf die Einhaltung des Datenschutzes verpflichtet ist und an welchen
Schulungen er teilgenommen hat. Der Report bietet auch die Möglichkeit, nach Organisati-
onseinheiten auszuwerten. Ein Vergleich zwischen Mitarbeitern einer Abteilung (z.B. Perso-
nal-Abt., EDV-Abt. usw.) mit den verpflichteten Personen zeigt die Differenzen auf. Ein be-
sonderes Augenmerk ist auf Neueinstellungen bzw. Umsetzungen von Mitarbeitern zu rich-
ten.
Empfehlung: Unternehmen, die nicht das HCM-Organisationsmanagement und die HCM-
Personalentwicklung einsetzen, sollten den Infotyp 0035 (Belehrungen) benutzen. Alle ande-
ren können auch den oben beschriebenen Weg über die Qualifizierungen im Profil einer Per-
son verwenden.
2.2.3.2 Anwenderschulung über das Veranstaltungsmanagement
Für Anwender, die das Veranstaltungsmanagement nutzen, empfiehlt es sich, mit diesem In-
strument die gesamte Organisation der Anwenderschulungen abzuwickeln.
Über das Veranstaltungsmanagement kann die Planung, Durchführung und Verwaltung von
Veranstaltungen organisiert werden. So können z.B. die Teilnehmer der Schulung, Ort und
Zeit, Referenten usw. geplant und abgerechnet werden.
2.3 Führen von Übersichten (§ 4g Abs. 2 / § 18 Abs. 2 BDSG)
In der Phase des Customizings wird festgelegt, welche Daten erfasst und gespeichert werden
sollen. In diesem Falle wirkt der DSB aktiv an der Umsetzung datenschutzrechtlicher Anfor-
derungen mit.
Für die effektive Wahrnehmung seiner Aufgaben benötigt der DSB nach den §§ 4e und 4g
Abs. 2 BDSG folgende Unterlagen:
§ 4g Aufgaben des Beauftragten für den Datenschutz
(2) Dem Beauftragten für den Datenschutz ist von der verantwortlichen Stelle eine
Übersicht über die in § 4e S. 1 genannten Angaben sowie über zugriffsberechtigte
Personen zur Verfügung zu stellen. Der Beauftragte für den Datenschutz macht die
Angaben nach § 4e S. 1 Nr. 1 bis 8 BDSG auf Antrag jedermann in geeigneter Weise
verfügbar.
§ 4e Inhalt der Meldepflicht
Sofern Verfahren automatisierter Verarbeitungen meldepflichtig sind, sind folgende
Angaben zu machen:
1. Name oder Firma der verantwortlichen Stelle
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 40
2. Inhaber, Vorstände, Geschäftsführer oder sonstige gesetzliche oder nach der Ver-
fassung des Unternehmens berufene Leiter und die mit der Leitung der Datenver-
arbeitung beauftragten Personen
3. Anschrift der verantwortlichen Stelle
4. Zweckbestimmungen der Datenerhebung, -verarbeitung oder -nutzung
5. eine Beschreibung der betroffenen Personengruppen und der diesbezüglichen Da-
ten oder Datenkategorien
6. Empfänger oder Kategorien von Empfängern, denen die Daten mitgeteilt werden
können
7. Regelfristen für die Löschung der Daten
8. eine geplante Datenübermittlung in Drittstaaten
9. eine allgemeine Beschreibung, die es ermöglicht, vorläufig zu beurteilen, ob die
Maßnahmen nach § 9 zur Gewährleistung der Sicherheit der Verarbeitung ange-
messen sind
Die öffentlichen Stellen haben nach § 18 Abs. 2 BDSG inhaltlich weitgehend ähnliche Anga-
ben zu machen, sind aber per Gesetzestext auf die schriftliche Dokumentation verpflichtet.
§ 18 Durchführung des Datenschutzes in der Bundesverwaltung
(2) Die öffentlichen Stellen führen ein Verzeichnis der eingesetzten Datenverarbei-
tungsanlagen. Für ihre automatisierten Verarbeitungen haben sie die Angaben nach
§ 4e sowie die Rechtsgrundlage der Verarbeitung schriftlich festzulegen. Bei allge-
meinen Verwaltungszwecken dienenden automatisierten Verarbeitungen, bei welchen
das Auskunftsrecht des Betroffenen nicht nach § 19 Abs. 3 oder 4 eingeschränkt wird,
kann hiervon abgesehen werden. Für automatisierte Verarbeitungen, die in gleicher
oder ähnlicher Weise mehrfach geführt werden, können die Festlegungen zusammen-
gefasst werden.
Wegen der weitgehend identischen Anforderungen im öffentlichen Bereich des Bundes und
nicht-öffentlichen Bereich orientieren sich die folgenden Ausführungen an den Aufgaben des
DSB nach § 4g BDSG.
In diesem Zusammenhang sei auch auf die EU-Richtlinie 95/46/EG (Abschnitt IX, Artikel 18
ff) verwiesen, in der fast wortgleiche Anforderungen gestellt werden.
Wenn der DSB im o.a. Zusammenhang auch die Ressourcen der IT-Sicherheit in Anspruch
nehmen will, kann er ggf. auf die Prüfung des IT-Sicherheitsmanagements im Rahmen der
ISO/IEC 27001 im Unternehmen zurückgreifen. Dort wird u.a. eine Erhebung der IT-Systeme
und eine Liste der IT-Anwendungen (Software, Anwendungsprogramme, Geschäftsprozesse)
sowie weitere Angaben (zuständige Administratoren; personenbezogene Daten) gefordert.
Dies bietet die Grundlage für das betriebsinterne Verfahrensverzeichnis.
2.3.1 Verantwortlichkeiten
Im Rahmen der Novellierung des BDSG im Jahre 2001 wurde die Aufgabenteilung zwischen
der DV-Abteilung und dem DSB der Realität angepasst: Die speichernde Stelle wurde in ver-
antwortliche Stelle umbenannt. Des Weiteren hat der DSB nunmehr auf die Einhaltung der
Befolgung der Gesetze und Vorschriften zum Datenschutz hinzuwirken (§ 4g Abs. 1 S. 1
BDSG). Für jeden Mitarbeiter, insbesondere aber für die Verantwortlichen der DV-Systeme
gilt:
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 41
Die Betreiber der Systeme (Anwendungs- und Systemverantwortliche) sind für die Einhaltung
der Gesetze und Vorschriften zum Datenschutz und zur Datensicherung verantwortlich. Die
verantwortliche Stelle hat u.a. Maßnahmen zu treffen, dass die Daten
- nur rechtsmäßig und zweckgebunden verarbeitet werden
- sachlich richtig und aktuell sind
- nicht länger als für den Zweck erforderlich aufbewahrt werden
- vor unerlaubtem Zugriff und Manipulationen geschützt werden
- nicht ohne ihre vorherige Zustimmung an Dritte weitergeleitet werden
Des Weiteren ist jeder Einzelne dafür verantwortlich, dass die ihm anvertrauten personenbe-
zogenen Daten nur im Rahmen seiner Aufgabenstellung verarbeitet und genutzt werden.
Jeder Missbrauch, jede unzulässige Weitergabe dieser Daten ist verboten und kann sowohl
arbeitsrechtliche Konsequenzen nach sich ziehen als auch bei Vorliegen der Vorrausetzungen
als Ordnungswidrigkeit oder Straftatbestand verfolgt werden.
Es bietet sich an, diese Klarstellung den Verantwortlichen mit der Aufforderung zur Erstel-
lung der Übersichten zukommen zu lassen.
2.3.2 Form der Dokumentation
Während der Inhalt der Übersichten in den §§ 4e und 4g BDSG detailliert beschrieben ist,
wird zur Form der Dokumentation im Gesetzestext keine Aussage getroffen. Für das SAP
ERP-System ist eine Kombination von schriftlichen Übersichten (z.B. Aktenvermerken) und
Verweisen auf die elektronische Dokumentation (z.B. ABAP Dictionary, AIS) sinnvoll. Hier-
für bietet sich an, die Dynamik des SAP-Systems zu nutzen und sich einzelne Details dann zu
besorgen, wenn sie benötigt werden. Die vom Gesetzgeber vorgeschriebenen Mindestinhalte
müssen allerdings stets in aktueller Form vorliegen.
Im Zentrum der Dokumentation stehen die Meldedaten nach § 4e BDSG, ergänzt um die zu-
griffsberechtigten Personen.
Es muss zu folgenden Zwecken dem DSB von der verantwortlichen Stelle zur Verfügung ge-
stellt werden:
Angaben zum Inhalt der Meldepflicht nach § 4e BDSG
Auf Antrag muss der DSB die Angaben 1 bis 8 nach § 4g Abs. 2 BDSG Jedermann
verfügbar machen.
Die Vorabkontrolle ist bei besonderen Risiken nach Empfang der Übersichten vorzu-
nehmen.
Der DSB benötigt die Übersichten, um die ordnungsgemäße Verarbeitung personen-
bezogener Daten nach § 4g Abs. 1 S. 4 Nr. 1 BDSG zu überwachen.
Benachrichtigung des Betroffenen nach den §§ 19a, 28b und 33 BDSG
Unterrichtung der Betroffenen bei Erhebung nach § 4 Abs. 3 BDSG
Auskunft an Betroffene nach den §§ 19 und 34 BDSG
Auskünfte gegenüber der Aufsichtsbehörde gemäß § 38 Abs. 3 S. 1 BDSG
Der Inhalt der Übersichten muss sich nach dem Verwendungszweck richten. Aus diesem
Grund ist es sinnvoll, die Übersichten in ein öffentliches Melderegister auf der Basis von § 4g
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 42
Abs. 2 BDSG in Verbindung mit § 4e S. 1 Nr. 1-8 BDSG und ein betriebsinternes Verfah-
rensverzeichnis - indem darüber hinaus die Angaben gemäß § 4e S. 1 Nr. 9 und § 4g Abs. 2
BDSG enthalten sind - zu unterteilen, die verschiedene Funktionen erfüllen. Eine gesetzliche
Verpflichtung betreffend eine Aufspaltung in ein öffentliches Melderegister und ein betriebs-
internes Verfahrensverzeichnis besteht jedoch nicht.
2.3.3 Das öffentliche Melderegister
Das öffentliche Melderegister ist die Grundlage für die Auskunft an Jedermann und, soweit
notwendig, die Meldung an die Aufsichtsbehörde.. Das öffentliche Melderegister soll allge-
meine gesellschaftliche Transparenz gewährleisten, um im Vorfeld von Auskunftsansprüchen
Orientierungswissen darüber zu geben, wer welche Daten speichert.
Meldungen sollten kurz und verständlich sein, wie die Darstellung des unabhängigen Landes-
zentrums für Datenschutz Schleswig-Holstein beispielhaft zeigt (vgl. 2.3.5).
Detaillierungsgrad
Die Informationen sind dem DSB als Übersichten von der verantwortlichen Stelle zur Verfü-
gung zu stellen. Auch die Begriffe Personengruppen, Datenkategorien und Kategorien von
Empfängern lassen darauf schließen, dass detaillierte Beschreibungen in diesen Übersichten
nicht notwendig sind. Da das öffentliche Melderegister auch jedermann in geeigneter Weise
verfügbar gemacht werden muss, ist eine genaue Beschreibung von Einzeldaten, Personen
oder Empfängern für die Außendarstellung nicht angebracht. Schließlich zeigt der Ausschluss
der ergriffenen Sicherungsmaßnahmen in § 4g Abs. 2 BDSG, dass die Offenbarung der Daten
nicht zu einem Risiko für das verarbeitende Unternehmen werden darf.
2.3.4 Das betriebsinterne Verfahrensverzeichnis
Das betriebsinterne Verfahrensverzeichnis dagegen dient dem Datenschutzbeauftragten dar-
über hinaus zur internen Prüfung, der Vorabkontrolle, der Identifizierung der zugriffsberech-
tigten Personen gemäß § 4g Abs. 2 S. 1 BDSG sowie der Prüfung der Angemessenheit der
Maßnahmen nach § 9 S. 2 BDSG und ist Grundlage zu speziellen Auskunftsanforderungen
von betroffenen Personen. Speziell bei sensiblen Daten nach § 3 Abs. 9 BDSG wie Angaben
über Gesundheit ist eine detailliertere Übersicht erforderlich.
In vielen Fällen muss dabei Detailwissen zur Person zur Verfügung gestellt werden, wobei die
einschlägigen SAP-Funktionalitäten (z.B. ABAP Dictionary, AIS) zur Unterstützung heran-
gezogen werden können.
Die Übersichten müssen auf der anderen Seite für den DSB ein geeigneter Ansatz sein, um für
verschiedene Zwecke eine Detailanalyse vornehmen zu können:
Bei der Vorabkontrolle benötigt der DSB in vielen Fällen neben der Tabellen-/Info-
/Subtypbeschreibung auch Einblick in die Beschreibung der Datenfelder z.B. bei Speiche-
rung von Gesundheits- oder Leistungsdaten.
Bei Überwachung der datenschutzgerechten Verarbeitung muss der DSB mit Unterstüt-
zung der Verantwortlichen und/oder auf Grundlage der Dokumentation im Einzelfall bis
auf Feldebene vordringen können.
Die Benachrichtigung umfasst die Identität des Verarbeiters, die Zweckbestimmung, Ka-
tegorien von Empfängern und die Art der Daten.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 43
Die Betroffenen sind bei Erhebung über die Identität der verantwortlichen Stelle, die
Zweckbestimmung der Erhebung und die Kategorien von Empfängern zu unterrichten,
wenn sie nicht bereits auf andere Weise Kenntnis erlangt haben.
Die Auskunft verlangt exakte Informationen über die zu einer Person gespeicherten Daten
und deren Herkunft, die Empfänger und den Zweck der Speicherung
Zur Beurteilung der § 9 BDSG-Maßnahmen zur Gewährleistung der Sicherheit der Verar-
beitung sind detaillierte Angaben über die gespeicherten Daten und deren Verarbeitungs-
zwecke erforderlich.
Aus dieser Zusammenstellung ist ersichtlich, dass auch Auskunft und Benachrichtigung sich
auf Punkte der Übersichten beziehen.
Zur Tabellen- oder Feldanalyse kann im SAP ERP das ABAP Dictionary genutzt werden. Der
Umgang mit Domänen, Tabellen, Reports und Verwendungsnachweisen erfordert vom DSB
handwerkliches Geschick. Wegen der Vorabkontrolle muss man gegebenenfalls bis auf das
sensitive Datum selbst herunterbrechen, z.B. Felder im Infotyp 0002 (Daten zur Person; Da-
tenfeld Familie, Anzahl der Kinder Konfession), Infotyp 0004 (Behinderung), Infotyp 0028
(Werksärztlicher Dienst), oder Infotyp 0077 (zusätzliche Daten zur Person, mit ethnischer
Herkunft, Konfessionsschlüssel oder Veteran Status). In Abschnitt 2.4 wird dargestellt, wie
man zum Inhalt und zur Dokumentation von Feldern und Prüftabellen kommt.
Es ist zu beachten, dass nicht alle erforderlichen Angaben elektronisch im SAP ERP-System
vorhanden sind. Der pauschale Verweis auf das ABAP Dictionary bzw. das AIS-
‚Dateiregister’ etwa greift zu kurz, wenn nicht ergänzende schriftliche Unterlagen vorhanden
sind. So gibt es z.B. keine Kennzeichnung für Tabellen bzw. Datenfelder mit personenbezo-
genen Daten. Zweckbestimmung, Empfänger oder zugriffsberechtigte Personen werden in der
Regel auch nicht im Zusammenhang mit der Beschreibung von Daten oder Datenkategorien
im SAP ERP dokumentiert.
2.3.4.1 Informationen zur verantwortlichen Stelle
Hier werden die Punkte eins bis drei des öffentlichen Melderegisters zusammengefasst. Die
Informationen über den Firmennamen, die Anschrift und die Geschäftsleitung eignen sich am
besten zu einer Internet-Darstellung in einer Art Impressum.
2.3.4.2 Zweckbestimmungen der Datenerhebung, -verarbeitung oder -
nutzung
Anforderung:
§ 4e BDSG verlangt eine Angabe zu den Zweckbestimmungen der Datenerhebung, -
verarbeitung oder -nutzung.
Auslegung der gesetzlichen Anforderung in Bezug auf SAP ERP:
Auch wenn das BDSG davon ausgeht, dass die Rechtsgrundlage der Verarbeitung für alle Da-
ten - d.h. für jedes einzelne Datenfeld - gegeben sein und auch insofern vor der Verarbeitung
geprüft werden muss, so kann daraus nicht gefolgert werden, dass auch die Dokumentation
feldbezogen zu erfolgen hat.
Die Frage, ob zusätzlich die Rechtsgrundlage direkt mit in die Übersicht aufzunehmen ist,
wird sehr unterschiedlich beantwortet.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 44
Vom Hersteller des SAP ERP-Systems darf der Anwenderbetrieb keine allgemeingültigen
Angaben zu den Rechtsgrundlagen erwarten, da im Einzelfall verschiedene bereichsspezifi-
sche Gesetze, Tarifverträge, Betriebsvereinbarungen, Einwilligungen oder im Falle des § 28
Abs. 1 S. 1 Nr. 1 BDSG die verschiedensten Vertragsverhältnisse in Frage kommen.
Die Angabe der Geschäftszwecke muss im Unternehmen aus Sicht der Fachabteilung defi-
niert werden, z.B. Finanzbuchhaltung, Personalabrechnung, Bewerberverwaltung, Reisekos-
tenabrechnung.
2.3.4.3 Beschreibung der betroffenen Personengruppen und der
diesbezüglichen Daten oder Datenkategorien
Anforderung:
Alle betroffenen Personengruppen und deren Daten oder Datenkategorien sind aufzuführen.
Dabei ist von dem datenschutzrechtlichen Begriff der automatisierten Verarbeitung auszuge-
hen und nicht vom EDV-technischen Dateibegriff. Die Beziehung zu den Bezeichnungen auf
Datenbank- oder Betriebssystemebene sollte nachvollziehbar sein, muss aber nicht zwingend
in die Übersicht mit aufgenommen werden. Benutzerdaten sind auch aufzunehmen (siehe un-
ten).
SAP-Fakten:
SAP ERP baut bei der Datenhaltung auf den Diensten relationaler Datenbanksysteme auf.
Über relationale Verknüpfungen von Tabellen können Daten auf unterschiedlichen Ebenen
aggregiert und zu neuen Aussagen verknüpft werden.
Im Audit Information System findet sich eine Dokumentationsmöglichkeit für Daten bzw.
Tabellen des ABAP Dictionary bestimmter Personengruppen. Dort wird nach folgenden Per-
sonengruppen differenziert:
Mitarbeiterdaten (HCM-Daten)
Bewerberdaten (HCM -Daten)
Lieferantendaten
Kundendaten
Partnerdaten
Sachbearbeiterdaten
Verkäufergruppendaten
Patientendaten
SAP-Benutzer (Stammdaten der Benutzerverwaltung)
Diese Personengruppen sind in verschiedenen Report-Varianten in der Mappe ‚Dateiregister
zu personenbezogenen Daten’ (Report RSCRDOMA) zusammengefasst. Die für diese Perso-
nengruppen verwendeten Tabellen können direkt im AIS angezeigt werden.
Allerdings basiert das AIS noch auf der Sprachregelung des ‚alten BDSG’, verwendet Be-
grifflichkeiten wie ‚Dateiregister’ und bietet bisher keinerlei Informationen über die perso-
nenbezogenen Daten in der Java-Welt. Die bekannten Domänen mit Personenbezug sind im
AIS nicht vollständig abgebildet.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 45
Außerdem bietet das SAP ERP-System weitere Funktionen für die Dokumentati-
on/Beschreibung von Daten (z.B. im ABAP Dictionary), die im Abschnitt 2.4 detaillierter
dargestellt werden.
Auslegung der gesetzlichen Anforderung in Bezug auf SAP ERP:
§ 4g BDSG in Verbindung mit § 4e S. 1 Nr. 5 BDSG verlangt von der verantwortlichen Stel-
le, dem Datenschutzbeauftragten u.a. eine Beschreibung der betroffenen Personengruppen
und der diesbezüglichen Daten oder Datenkategorien zur Verfügung zu stellen.
Es stellt sich die Frage, wie genau die Personengruppen und die diesbezüglichen Daten do-
kumentiert werden müssen. Das BDSG überlässt es der verantwortlichen Stelle, so dass so-
wohl die Bildung von Datenkategorien als auch die Auflistung einzelner Datenfelder möglich
ist. Was nötig ist, muss im Einzelfall entschieden werden und sollte davon abhängig gemacht
werden, zu welchem (Dokumentations-/Auskunfts-) Zweck die Angaben verwendet werden
sollen.
Allerdings erfordert § 4e S. 1 Nr. 9 BDSG eine Beschreibung, auf deren Grundlage eine Beur-
teilung von Sicherheitsmaßnahmen ermöglicht werden soll. Diese Beurteilung macht z.B. im
HCM eine Betrachtung der Daten bis auf die Ebene des einzelnen Infotyps (bzw. der Data
Dictionary-Tabelle) erforderlich.
Personenbezogene Daten werden in unterschiedlichen Zusammenhängen im SAP ERP-
System gespeichert. Im Rahmen der Personalwirtschaft (HCM) finden sich die Mitarbeiterda-
ten. Sachbearbeiter- bzw. Benutzerdaten werden in vielfachen Anwendungszusammenhängen
verwendet und auch Kunden-/Lieferanten-Daten werden hinterlegt.
Im SAP ERP-System können Daten über eine Person im Zusammenhang mit deren verschie-
denen „Rollen“ auftauchen, z.B. im Rahmen der Gehaltsabrechnung oder als Buchhaltungs-
sachbearbeiter. Die im Audit Information System getroffene Unterscheidung verschiedener
Personengruppen bzw. „Rollen“ ist durchaus geeignet, die entsprechenden Anforderungen des
BDSG zu erfüllen.
Die zu einer Personengruppe gehörigen Daten können im AIS unter der jeweiligen Rubrik
abgefragt werden, wobei auf Wunsch eine Liste nicht leerer Tabellen mit Kennzeichnung der
abgefragten Domäne angezeigt wird. Eine Liste nicht leerer Tabellen ist gleichzusetzen mit
tatsächlich verwendeten Tabellen eines konkreten Systems. Im Zusammenhang mit den Mit-
arbeiterdaten sind dies die entsprechenden Infotypen.
Die Personalstammdaten (Tabellen PA0*) unterscheiden sich i.d.R. hinsichtlich Zweckbe-
stimmung, Zugriffsberechtigung und regelmäßigen Empfängern oder lassen sich zumindest in
Gruppen aufteilen. Die Infotypen im HCM-Modul sind zudem bereits überwiegend nach per-
sonalwirtschaftlich-fachlichen Kriterien (z.B. Anschriften, Darlehen, DEÜV) strukturiert.
Daher spricht einiges dafür, die Tabellen des SAP ERP-Systems weiterhin als Grundlage der
Dokumentation zu wählen. Diese Vorgehensweise hat Vorteile, denn die Prüfung, welche Ta-
bellen sinnvollerweise zusammengefasst werden sollten, entfällt, und die zusätzlichen Anga-
ben der Übersichten nach § 4 BDSG können den im System definierten Tabellen direkt zuge-
ordnet werden. Auch aus Praktikabilitätsgründen bietet sich diese einheitliche und systemna-
he Dokumentation an, denn dabei kann auf einfache Weise auf die im System hinterlegten In-
formationen zurückgegriffen werden.
Im SAP ERP-Einführungsprojekt ist zu Beginn der Customizing-Phase unter Einbeziehung
des Datenschutzbeauftragten festzulegen, welche personenbezogenen Daten zulässig sind.
Hierbei sind insbesondere auch die Beteiligungsrechte von Betriebs- und Personalräten zu be-
achten. In der Customizing-Phase bietet es sich an, eine erste Version der Übersichten zu er-
stellen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 46
Auch Benutzerdaten sind personenbezogene Daten und daher in die Übersichten mit aufzu-
nehmen. Dazu zählen
Sachbearbeiterkennzeichen, z.B. im Rahmen des Moduls FI
Protokolldaten, z.B. in der Workload Analysis (STAD)
Verwaltungsdaten, z.B. der anlegende, ändernde SAP-Benutzer
Daten von Dritten, z.B. bestellender Sachbearbeiter eines Kunden
Personenbezogene Daten, die ausschließlich Zwecken der Datenschutzkontrolle, der Datensi-
cherung oder der Sicherstellung eines ordnungsgemäßen Betriebs einer Datenverarbeitungs-
anlage dienen, unterliegen nach § 31 BDSG einer besonderen Zweckbindung, was insbeson-
dere der Verstärkung des Schutzes der Betroffenen dienen soll.
Bei Verwendung von Sachbearbeiterkennzeichen ist nur die Tatsache der Verarbeitung,
nicht der Inhalt des verarbeiteten Datensatzes ein personenbezogenes Datum. Wenn z.B. ein
Sachbearbeiter die Adresse eines Kunden eingibt und dabei sein Sachbearbeiterkennzeichen
(z.B. ein Namenskürzel) gespeichert wird, so ist das personenbezogene Datum “Mitarbeiter A
hat am 3. Februar den Datensatz X ergänzt“. Die Adresse des Kunden ist kein personenbezo-
genes Datum des Sachbearbeiters. Da nur die Tatsache der Verarbeitung (und nicht der Inhalt
der Datensätze) entscheidend ist, muss auch nur dies in den Übersichten dokumentiert wer-
den. Es sollte daher für das SAP ERP-System ausreichen, alle Tabellen, die Sachbearbeiter-
kennzeichen enthalten, aufzulisten und gemeinsam zu dokumentieren.
Auch Protokolldateien (siehe hierzu auch Abschnitt 2.3.4.5) sind in die Übersichten aufzu-
nehmen. Da es sich im Allgemeinen um Mitarbeiterdaten handelt, unterliegt die Verarbeitung
dieser Daten der Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG bzw. § 75 Abs. 3 Nr. 17
BPersVG.
2.3.4.4 Empfänger oder Kategorien von Empfängern
Grundsätzlich sind von der verantwortlichen Stelle im Verfahrensverzeichnis die Empfänger
oder Kategorien von Empfängern im SAP ERP-System zu nennen. Empfänger ergeben sich
aus Verträgen mit Mitarbeitern, Lieferanten und Kunden (Bankverbindung) sowie aus gesetz-
lichen Grundlagen (Sozialversicherung, Finanzamt, DEÜV usw.).
Informationen über theoretisch zu erreichende Empfänger im SAP ERP sind an vielen Stellen
verteilt. Bankverbindungen sind z.B. im Bankenstamm (Tabelle BNKA) hinterlegt (siehe
auch SAP-Prüfleitfaden R/3 FI, Kapitel Rechnungsprüfung und Zahlungslauf). Weiterhin fin-
det man sie im Lieferantenstamm (LFBK) oder im Modul HCM im Infotyp 0009 (Bankver-
bindung, Tabelle PA0009).
Im Einführungsprojekt sind die erlaubten Schnittstellen mit dem DSB abzusprechen und in
der Projektdokumentation festzuhalten. Ob und wie diese Empfänger erreicht werden, ist or-
ganisatorisch in einem Datenflussplan festzuhalten.
Übermittlungen im Sinne des BDSG können SAP-technisch auf sehr unterschiedliche Weise
realisiert werden.
In einer Ein-Mandanten-Installation für einen Konzern kann die Übermittlung bereits durch
die Erteilung von Buchungskreis bzw. Personalbereich übergreifenden Zugriffsrechten erfol-
gen, da Regelungen zur Datentrennung nicht wirksam werden können.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 47
Eine Übermittlung kann aber auch durch die Übersendung von Daten von einem System zu
einem anderen System erfolgen, beispielsweise wenn beide Systeme zu unterschiedlichen
verantwortlichen Stellen gehören.
Abhängig von der jeweiligen technischen Realisierung gibt es unterschiedliche Wege, die
technische Realisierung nachzuvollziehen. Diese sind im Folgenden beispielhaft aufgeführt.
Welche Hilfen bietet SAP an, um die regelmäßigen Empfänger zu ermitteln?
Technische Verbindungen
Transaktion SM59 (RFC-Destination), Transaktion BD64 (Verteilungsmodellpflege), Ba-
sis-Services (BC-SRV) und SM54 (CPIC-Destination); weitere Verbindungen (SAP
NetWeaver Exchange Infrastructure, SAP XI (Nachfolger: SAP NetWeaver Process In-
tegration, PI)) überprüfen
Welchen Überblick bietet SAP ERP über Systeme und Komponenten an?
Verzeichnis der verfügbaren SAP-Systeme mit den entsprechenden Transportschichten
(SE17, Tabelle TSYST oder AIS/Transport Management System)
Tabelle Logische Systeme (Mandanten; Tabelle TBDLS)
Übersicht zu Mandanten und Benutzern eines SAP-Systems
Programm: RFAUDI06: Anzahl Benutzer je Mandant
Übersicht Mandanten
Tabelle T000 (SCC4)
Kostenrechnungskreise
Tabelle TKA01
Übersicht Buchungskreise
Tabelle T001
Personalbereiche
Tabelle T500P
Komponentenhierarchie (SB01 bzw. HIER)
Systemlastmonitor Transaktion ST03N (Genutzte Komponenten - Monatssicht in Trans-
aktion ST03N; ein mittelbarer Rückschluss über die Verwendung ist möglich)
Genutzte Datentabellen
Transaktion ST10
Object Navigator (SE84)
Menüpfad:
Werkzeuge -> ABAP Workbench -> Übersicht -> Infosystem -> ABAP Dictionary -> Da-
tenbanktabelle bzw. Programmbibliothek -> Programme /Teilobjekte zu Programmen ->
Dynpros
Data Browser (SE17)
Menüpfad:
Werkzeuge -> ABAP Workbench-> Übersicht -> Data Browser -> Tabellenname
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 48
Object Navigator (SE80)
Menüpfad:
Werkzeuge -> ABAP Workbench -> Übersicht -> Object Navigator
Über das Dictionary und die dort aufrufbaren Verwendungsnachweise kann die Verwendung
von personenbezogenen Daten bis auf Programmebene nachvollzogen werden.
2.3.4.5 Regelfristen für Löschung14
Einleitend ist zunächst zu bemerken, dass die nachfolgend angesprochenen Fristen - betref-
fend die Löschung von personenbezogenen Daten - sich explizit an den hierzu einschlägigen
gesetzlichen Regelungen der Bundesrepublik Deutschland und an denen von der Rechtspre-
chung hierzu ergangenen Vorgaben orientieren. Technische Hinweise und Anmerkungen gel-
ten dagegen grundsätzlich übergreifend, d.h. auch über das Staatsgebiet der Bundesrepublik
Deutschland hinaus. Gleichwohl bedürfen diese einer spezifischen Umsetzung in Form eines
länder- bzw. projektspezifischen Customizings unter Berücksichtigung lokaler Bestimmun-
gen.
Gemäß § 3a BDSG haben sich die Erhebung, Verarbeitung und Nutzung personenbezogener
Daten und die Gestaltung und Auswahl von Datenverarbeitungssystemen an dem Ziel auszu-
richten, keine oder so wenig personenbezogene Daten wie möglich zu erheben, zu verarbeiten
oder zu nutzen. Dieser Grundsatz der Datenvermeidung und Datensparsamkeit ist einer der
elementaren Bestandteile des Datenschutzrechts. Deshalb ist insbesondere von den Möglich-
keiten der Anonymisierung und der Pseudonymisierung Gebrauch zu machen.
Unter Anonymisierung wird verstanden
„… das Verändern personenbezogener Daten derart, dass die Einzelangaben über
persönliche oder sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnis-
mäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder be-
stimmbaren natürlichen Person zugeordnet werden können.“ (§ 3 Abs. 6 BDSG)
Ein solcher Aufwand muss demnach im Verhältnis zum angestrebten Zweck stehen. Eine
Abwägung hat somit explizit im Zuge einer Verhältnismäßigkeitsprüfung zu erfolgen.
„Pseudonymisieren ist das Ersetzen des Namens und anderer Identifikationsmerkma-
le durch ein Kennzeichen zu dem Zweck, die Bestimmung des Betroffenen auszuschlie-
ßen oder wesentlich zu erschweren.“ (§ 3 Abs. 6a BDSG)
Unter Berücksichtigung der zuvor gemachten Ausführungen setzt sich das nachfolgende Ka-
pitel mit bestehenden Rechtsvorschriften, insbesondere betreffend Regelfristen für Lö-
schungs- und Mindestaufbewahrungsfristen, von personenbezogenen Daten auseinander. Da
das BDSG jedoch ein so genanntes Auffanggesetz ist, gehen spezielle Rechtsvorschriften vor.
Erst wenn solche bereichsspezifischen vorrangigen Bestimmungen keine rechtlichen Rege-
lungen beinhalten, kommt das BDSG zum Tragen (lex specialis vor lex generalis).
Aufgrund der in der Vergangenheit bereits stattgefundenen - damit auch zukünftig zu erwar-
tenden - Schaffung von neuen gesetzlichen Bestimmungen, wie z.B. des Allgemeinen Gleich-
behandlungsgesetzes (AGG) aus dem Jahre 2006, muss darauf hingewiesen werden, dass Re-
gelungen des Gesetzgebers, betreffend Löschung und Mindestaufbewahrung, in der Praxis ei-
14 Diesem Abschnitt liegen folgende Quellen zugrunde: Abel, Datenschutz, Band 2, Teil 6
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 49
ner Ausgestaltung - aufgrund von aktueller Rechtsprechung - bedürfen. Eine Vielzahl beste-
hender Rechtsprechung zu Löschungs- und Mindestaufbewahrungsfristen ist bereits ergangen.
Weitere gerichtliche Entscheidungen werden noch folgen, so dass auf die vorliegende Thema-
tik stets ein „juristisches Auge zu werfen ist“.
Im BDSG werden die so genannten Regelfristen für Löschungen - gemäß § 4e S. 1 Nr. 7
BDSG - genannt. Die Legaldefinition des § 3 Abs. 4 S. 2 Nr. 5 BDSG versteht unter löschen
„das Unkenntlichmachen gespeicherter personenbezogener Daten“, womit das unwieder-
bringliche Tilgen der Daten, ungeachtet der dabei verwendeten Verfahren, gemeint ist15. SAP
benutzt den Begriff der „Vernichtung“ von Daten.
Datenverarbeitung der öffentlichen Stellen
Die Datenverarbeitung der öffentlichen Stellen der Länder richtet sich insbesondere nach den
jeweiligen Landesdatenschutzgesetzen. Soweit diese einschlägig sind kommt das BDSG nicht
zum Tragen. Die Thematik Löschung bzw. Sperrung von personenbezogenen Daten durch öf-
fentliche Stellen des Bundes (was hierunter im Einzelnen gemeint ist, ergibt sich aus der Le-
galdefinition des § 2 Abs. 1 BDSG) ist in § 20 BDSG geregelt. Demnach gilt:
(2) Personenbezogene Daten, die automatisiert verarbeitet oder in nicht-
automatisierten Dateien gespeichert sind, sind zu löschen, wenn
1. ihre Speicherung unzulässig ist oder
2. ihre Kenntnis für die verantwortliche Stelle zur Erfüllung der in ihrer Zuständig-
keit liegenden Aufgaben nicht mehr erforderlich ist.
(3) An die Stelle einer Löschung tritt eine Sperrung, soweit
1. einer Löschung gesetzliche, satzungsmäßige oder vertragliche Aufbewahrungsfris-
ten entgegenstehen,
2. Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interes-
sen des Betroffenen beeinträchtigt würden, oder
3. eine Löschung wegen der besonderen Art der Speicherung nicht oder nur mit un-
verhältnismäßig hohem Aufwand möglich ist.
Gemäß dem Grundsatz lex specialis vor lex generalis (das besondere Gesetz geht dem allge-
meinen Gesetz vor) nachfolgend einige Beispiele für vorrangige bereichsspezifische Lö-
schungsfristen der öffentlichen Stellen:
Berufsgenossenschaften, spezielle gesetzliche berufsgenossenschaftliche Aufbewah-
rungspflichten bestehen grundsätzlich nicht, dennoch empfehlen die Berufsgenossenschaf-
ten in ihrem BG-Blatt B36, Ausgabe Oktober 2005, dass für Unterweisungen zur Arbeits-
sicherheit und zum Gesundheitsschutz eine Aufbewahrungsfrist von mindestens zwei,
besser fünf Jahren, in Betracht gezogen werden sollte,
Erziehungsregister, Maßnahmen nach dem Jugendgerichtsgesetz, Verfügungen des
Vormundschaftsgerichts; solche Eintragungen werden entfernt wenn der Betroffene das
24. Lebensjahr vollendet hat (§ 63 Abs. 1 BZRG),
15 siehe BDSG Kommentar Gola/Schomerus, §§ 3 Rn. 40
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 50
Gewerbezentralregister, Eintragungen werden - abhängig von der Höhe der Verhängung
einer Geldbuße - nach einer Frist von drei oder fünf Jahren getilgt (§ 153 Abs. 1 Nr. 1 und
2 GewO),
Öffentliche Archive, sofern Behörden Unterlagen zur Erfüllung ihrer öffentlichen Auf-
gaben nicht mehr benötigen, sind diese dem Bundesarchiv oder in bestimmten Fällen dem
zuständigen Landesarchiv zur Überlassung anzubieten (§ 2 Abs. 1 BArchG), dabei blei-
ben Rechtsvorschriften betreffend die Vernichtung (§ 2 Abs. 7 BArchG) bzw. Rechtsan-
sprüche Betroffener auf Vernichtung der sie betreffenden personenbezogenen Angaben (§
4 Abs. 1 BArchG) unberührt,
Schuldnerverzeichnis, Eintragungen sind nach Ablauf von drei Jahren, seit dem Ende
des Jahres in dem eine eidesstattliche Versicherung abgegeben wurde, zu löschen (§ 915 a
ZPO, § 284 AO),
Sozialrecht, Daten bei Krankenkassen, kassenärztlichen Vereinigungen und Geschäfts-
stellen der Prüfungsausschüsse sind, abhängig von der jeweiligen Art der Daten, nach ei-
ner Frist von vier oder zehn Jahren zu löschen (§ 304 SGB V, § 107 SGB XI, § 84 SGB
X),
Strafregister, Eintragungen werden, in Abhängigkeit der Schwere der Tatbegehung, nach
Ablauf von fünf, zehn, fünfzehn oder zwanzig Jahren getilgt (§ 46 Abs. 1 BZRG),
Verkehrszentralregister („Verkehrssünderkartei“), im Register gespeicherte Eintragun-
gen werden in Abhängigkeit der Schwere der Tat nach einer Frist von zwei, fünf oder
zehn Jahren getilgt (§ 29 Abs. 1 StVG).
Wie sich schon aus der Formulierung „Beispiel“ ergibt kann an dieser Stelle nur exemplarisch
angerissen werden, welche bereichsspezifischen Löschvorschriften existieren und welche Re-
gelfristen für die Löschung von personenbezogenen Daten für öffentliche Stellen Anwendung
finden.
Allein im Bereich der so genannten sozialen Sicherung haben etwa die gesetzlichen Kranken-
kassen Regelfristen für Löschungen zu beachten, die sich aus den
Sozialgesetzbüchern (SGB I - IX) sowie der
Sozialversicherungs-Rechnungsverordnung (SVRV)
allgemeinen Verwaltungsvorschriften über das Rechnungswesen in der Sozialversiche-
rung (SRVwV) und der
Risikostruktur-Ausgleichsverordnung (RSAV)
ergeben. Dabei variieren die anzuwendenden Aufbewahrungsfristen zwischen zwei und zehn
Jahren.
Die nach § 284 Abs. 1 S. 4 und § 304 Abs. 1 SGB V vorgegebene Verpflichtung zur Lö-
schung bestimmter Daten (Datenlöschung sobald diese für die vorgesehenen Zwecke nicht
mehr benötigt werden, spätestens jedoch nach zehn Jahren) geht der Löschfrist nach § 84
SGB X vor.
Datenverarbeitung der nicht-öffentlichen Stellen
Was im Einzelnen unter dem Begriff „nicht-öffentliche Stelle“ gemeint ist, folgt aus § 2
Abs. 4 BDSG. Demnach fallen hierunter alle natürlichen Personen, privatrechtliche organi-
sierte Personen, Personengesellschaften und nicht rechtsfähige Vereine die sich an die Verar-
beitungsregelungen der §§ 28 ff BDSG halten müssen. Ausgenommen sind somit so genannte
beliehene Unternehmen (natürliche oder juristische Personen des Privatrechts, die hoheitliche
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 51
Funktionen im eigenen Namen oder im Auftrag des Staates ausüben, wie z. B. der TÜV) so-
wie privatrechtlich organisierte Vereinigungen von öffentlichen Stellen des Bundes und der
Länder gemäß den besonderen Vorgaben des § 2 Abs. 3 BDSG.
§ 35 Abs. 2 BDSG enthält eine ganze Reihe von Löschungsvorschriften. Demnach sind per-
sonenbezogene Daten zu löschen, wenn
ihre Speicherung unzulässig ist
es sich um Daten über die rassische oder ethnische Herkunft, politische Meinungen, reli-
giöse oder philosophische Überzeugungen oder die Gewerkschaftszugehörigkeit, über Ge-
sundheit oder das Sexualleben, strafbare Handlungen oder Ordnungswidrigkeiten handelt
und ihre Richtigkeit von der verantwortlichen Stelle nicht bewiesen werden kann
sie für eigene Zwecke verarbeitet werden, sobald ihre Kenntnis für die Erfüllung des
Zweckes der Speicherung nicht mehr erforderlich ist
sie geschäftsmäßig zum Zwecke der Übermittlung verarbeitet werden und eine Prüfung
jeweils am Ende des vierten Kalenderjahres beginnend mit ihrer erstmaligen Speicherung
ergibt, dass eine länger währende Speicherung nicht erforderlich ist
Den Löschungsfristen auf der einen Seite stehen so genannte Mindestaufbewahrungsfristen
auf der anderen Seite entgegen. Diesbezüglich gibt es eine ganze Reihe von Bestimmungen
die explizite Regelungsgehalte aufweisen, welche nachfolgend - nicht abschließend - aufge-
führt sind. Wichtige Eckpunkte sind:
Aufbewahrung nach Handels- und Steuerrecht (z. B. Buchführung, Kundendaten, Lagebe-
richte, Personaldaten),
Aufbewahrungsbestimmungen zum Arbeits- und Sozialrecht, Berufsordnungen,
Aufbewahrungsvorschriften in der DV.
Handels- und Steuerrecht
sechs Jahre (§ 257 Abs. 4 HGB, § 147 Abs. 3 AO)
zehn Jahre (§ 257 Abs. 4 HGB, § 147 Abs. 3 AO)
Arbeits- und Sozialrecht, Berufsordnungen
Die Aufbewahrungsvorschriften erstrecken sich aufgrund gesetzlicher Vorgaben auf
zwei Jahre Arbeitszeitnachweise (§ 16 ArbZG), Jugendarbeitsschutzunterlagen (§ 50
Abs. 2 JArbSchG),
fünf Jahre Nachweise der Beitragsabrechnung und Beitragszahlung an Sozialversiche-
rungsträger (§ 28f Abs. 1 i. V. m. § 28p Abs. 1 SGB IV, Handakten von
Rechtsanwälten (§ 50 Abs. 2 BRAO),
sechs Jahre Betriebliche Altersversorgung (§ 11 Abs. 2 BetrAVG), Identifizierungs-
pflicht bei Finanztransaktionen (§ 9 Abs. 3 GwG),
zehn Jahre Jugendarbeitsschutz-Unterlagen - ärztlicher Untersuchungsbogen - (§ 4 Abs.
2 JArbSchUV),
Des Weiteren gibt es noch spezielle Aufbewahrungsvorschriften eingeteilt nach Kategorien
und Bereichen wie z. B.:
für die Dauer des Arbeitsverhältnisses bis Anfang eines jeden Jahres,
bis zum Ausscheiden eines Arbeitnehmers,
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 52
bis zum Ablauf des auf die letzte Prüfung folgenden Kalenderjahres,
bis zum Ablauf des Kalenderjahres, das auf das Jahr der Anlegung von Listen folgt.
Aufbewahrungsvorschriften in der Datenverarbeitung (§ 9 BDSG und Anlage zu § 9
BDSG, § 147 Abs. 5 AO, § 257 Abs. 3 HGB)
ein Jahr Job-Accounting, Netzwerkdaten, Systemnachrichten, Begleitpapiere und
Protokolle über Datenträgertransport und -Verwaltung, Konvertierungspro-
tokolle16,
drei Jahre Systemdateien (drei Generationen), Standardsoftware17
sechs Jahre Terminpläne, Schichtprotokolle, Arbeitsaufträge
zehn Jahre Anwenderprogramme einschließlich aller Unterlagen über die Übernahme
in die Produktion; Systemnachrichten; Protokolle über DV-Aktivitäten, so-
weit für die Nachvollziehbarkeit von nachweispflichtigen Aufträgen erfor-
derlich (für die Rechnungslegung relevante Tabellen).
Datenverarbeitung in besonderen Fällen
Protokolldateien
Eine besondere Problematik besteht hinsichtlich der Speicherung von sogenannten Protokoll-
dateien mit Hilfe von automatisierten DV-Anlagen. Dabei handelt es sich zum einen um Pro-
tokolle im Sinne eines „kaufmännischen“ Audits betreffend der inhaltlichen Änderungen an
Belegen (z.B. wer hat wann, was, gebucht, verändert) und zum anderen um Log-Files im Sin-
ne des System Logs oder des Security Audit Logs (z.B. Anmeldeversuche die zur Sperrung
führen können, abgebrochene Verarbeitungen, Warnmeldungen und sonstige Probleme; siehe
hierzu weitere Einzelheiten in Kapitel 4.2.1.9 des Leitfadens).
Die Log-Files und Protokolle beinhalten sowohl Informationen über alle oder nur bestimmte
Aktionen von Prozessen auf einem DV-Anwendungssystem, als auch personenbeziehbare Da-
ten. Einzelne Inhalte bestehender bzw. gespeicherter Log-Files können - ohne großen Auf-
wand - natürlichen Personen zugeordnet werden. Dabei sind gerade bei der Verwendung von
SAP-Anwendungen Log-Files und Protokolle - im Zusammenhang mit Tabellenzugriffen -
weit verbreitet, so dass hier nicht nur datenschutzrechtliche Normen, sondern auch betriebs-
verfassungsrechtliche Aspekte tangiert sind. Da den meisten SAP-Anwendern und selbst Ba-
sis-Administratoren nicht immer im Einzelnen klar ist was, wie und wo mittels Log-Files ge-
loggt oder mittels Verwendung von Protokollen protokolliert wird, ist hierauf ein besonderer
Augenmerk zu richten. Denn auch Gerichte haben längst die datenschutzrechtliche Brisanz
von Log-Files entdeckt. Aus den Urteilen des AG Darmstadt18, des LG Darmstadt19 20 und des
EuGH (24. November 2011, Rechtssache C-70/10) ist zu entnehmen, dass selbst dynamische
IP-Adressen geeignet sind, einen Personenbezug herzustellen und deshalb einer datenschutz-
rechtlichen und ggf. einer mitbestimmungsrechtlichen Beurteilung bedürfen. Damit hat auch
16 siehe Abel, Datenschutz, Band 2, Teil 6/2.4.1.4
17 siehe Abel, Datenschutz, Band 2, Teil 6/2.4.1.4
18 Az.: 300 C 397/04, vom 30.06.2005
19 Az.: 25 S 118/2005, vom 25.01.2006
20 Az.: 25 S 118/2005, vom 25.01.2006
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 53
bei der Erhebung bzw. Verarbeitung von Log-Files der Grundsatz der Datenvermeidung und
Datensparsamkeit - i. S. d. § 3a BDSG - im Vordergrund zu stehen.
Im Einzelfall kann es jedoch sein, dass der Arbeitgeber oder der Dienstherr ein berechtigtes
Interesse an der Erhebung und Speicherung von Log-Files und Protokollen hat. Hierzu nor-
miert § 28 Abs. 1 S. 1 Nr. 2 BDSG:
(1) Das Erheben, Speichern, Verändern oder Übermitteln personenbezogener Daten
oder ihre Nutzung als Mittel für die Erfüllung eigener Geschäftszwecke ist zulässig,
…
2. soweit es zur Wahrung berechtigter Interessen der verantwortlichen Stelle er-
forderlich ist und kein Grund zu der Annahme besteht, dass das schutzwürdige
Interesse des Betroffenen an dem Ausschluss der Verarbeitung oder Nutzung
überwiegt. …
Im Zuge dieser Bestimmung darf jedoch das schutzwürdige Interesse des Betroffenen, an dem
Ausschluss der Verarbeitung oder der Nutzung solcher Daten, nicht außer Acht gelassen wer-
den, so dass es stets zu einer Interessensabwägung kommen muss. Leider hat es der Gesetz-
geber in § 28 Abs. 1 S. 1 Nr. 2 BDSG verabsäumt, konkrete Anhaltspunkte zu formulieren,
die eine Interessensabwägung vereinfachen würden.21 Demnach hat eine solche Interessens-
abwägung im Zuge einer so genannten Verhältnismäßigkeitsprüfung stattzufinden, die unter
Berücksichtigung der Vorgaben des BDSG aber auch im Rahmen der gesetzlich normierten
Mitbestimmungsrechte der Arbeitnehmervertretungen durchgeführt werden muss.
In der Praxis könnte das wie folgt aussehen: Je mehr personenbezogene Daten in Log-Files
oder Protokollen erfasst werden, umso höher muss das schutzwürdige Interesse des Betroffe-
nen bemessen werden. Eine sinnvolle Maßnahme, die eine datenschutzkonforme Nutzung ge-
rade von Log-Files ermöglichen würde, wäre der Einsatz von Tools, welche automatisch per-
sonenbezogene bzw. personenbeziehbare Daten in Log-Files anonymisieren (z. B. Anonlog,
Pseudo/Core). Damit wäre nur noch bei wenigen abrechnungs- und steuerrelevanten Vorgän-
gen die Verwendung von klassischen, d.h. nicht anonymen Protokollen notwendig.
Lässt sich eine automatisierte Anonymisierung von Log-Files - aus welchen Gründen auch
immer - nicht durchführen, muss zwingend der Grundsatz der Zweckbindung (welcher aus §
31 BDSG folgt) beachtet und eingehalten werden. Demgemäß dürfen Log-Files „zu Zwecken
der Datenschutzkontrolle, der Datensicherung oder zur Sicherstellung eines ordnungsgemä-
ßen Betriebes einer Datenverarbeitungsanlage gespeichert werden“. Damit sind solche Daten
einer strikten Zweckbindung unterworfen, was auch in der Parallelregelung des § 14 Abs. 4
BDSG - für den öffentlichen Bereich - zum Ausdruck kommt. Daraus folgt, dass der Zugriff
auf Log-Files nur durch diejenigen Personen und Stellen erfolgen darf, die solche Daten für
die Erfüllung ihrer konkreten Aufgaben zwingend benötigen. Dies können – je nach Fallkons-
tellation – insbesondere Betriebsräte, Datenschutzbeauftragte, Sachverständige und Sys-
temadministratoren sein. Freilich sollten auch deren Zugriffe - trotz ihrer besonderen Vertrau-
enspositionen - auch nachträglich nachvollziehbar sein. Hierzu bietet sich insbesondere ein
„moderates“ Logging an, wobei sich hier die Frage einer Anonymisierung ernsthaft nicht
stellt (aufgrund der geringen Anzahl der diesbezüglich in Frage kommenden Personen bzw.
eingrenzbaren Stellen, ist grundsätzlich in jedem Fall, eine Zuordnung der Log-Files mög-
lich).
21 Simitis, Kommentar BDSG, S. 1030 Rn. 162
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 54
Anders verhält es sich dagegen bei Protokolldateien (Änderungsbelege), welche aufgrund
handels- bzw. steuerrechtlicher Grundsätze zu führen sind, beispielsweise muss stets erkenn-
bar sein, welcher „SAP-User“ eine Rechnung storniert hat. Gerade in diesen Fällen ist eine
Protokollierung schon zur Revisionssicherheit unumgänglich.
Bewerbungsunterlagen
Das Bundesarbeitsgericht stellte in seinem Urteil vom 6. Juni 198422 fest, dass eine längerfris-
tige Aufbewahrung von Personalbögen bzw. Bewerbungsunterlagen, eines erfolglos gebliebe-
nen Stellenbewerbers das verfassungsmäßige Persönlichkeitsrecht des Bewerbers verletzt.
Auch hier greift insoweit der Grundsatz der Datenvermeidung und Datensparsamkeit i. S. d.
§ 3a BDSG. Sofern die Bewerbungsphase abgeschlossen ist, bestehen grundsätzlich keine
Gründe, die es erforderlich machen, dass die Bewerbungsunterlagen weiterhin aufgehoben
werden müssen. Durch Inkrafttreten des AGG - im Jahr 2006 - wurde jedoch für den Bewer-
ber in § 15 AGG eine Rechtsgrundlage geschaffen, die es ihm erlaubt Entschädigung und
Schadensersatz, etwa bei der vorgetragenen Benachteiligung während der Bewerbung, binnen
einer Frist von zwei Monaten nach Zugang der Ablehnung, geltend zu machen. In diesem Fall
besteht seitens des Arbeitgebers eine Beweislast gemäß § 22 AGG. Aufgrund dieser Beweis-
lastpflicht, muss es dem Arbeitgeber möglich sein, die Unterlagen für einen Zeitraum von
mindestens zwei Monaten aufzubewahren, um seiner Nachweis- und Dokumentationspflicht
nachzukommen. Eine Klage auf Entschädigung und Schadensersatz muss gemäß § 61b Abs. 1
ArbGG i. V. m. § 15 AGG innerhalb von drei Monaten, nachdem der Anspruch schriftlich
geltend gemacht worden ist, erhoben werden. Daraus folgt, dass die beiden zuvor genannten
Fristen zusammen zu addieren und zusätzlich mit einer Karenzzeit von einem Monat zu ver-
sehen sind. Zusammenfassend kann somit festgestellt werden, dass für den Arbeitgeber eine
Aufbewahrungsfrist von insgesamt sechs Monaten gegeben ist.
Daten aus Schuldnerverzeichnissen
Handels- und Wirtschaftsauskunfteien wie etwa die SCHUFA erhalten in der Regel von den
Gerichten unmittelbar Daten aus dem Schuldnerverzeichnis (§ 915d Abs. 1, § 915e Abs. 1
Buchst. b ZPO). Das BDSG sieht in § 35 Abs. 2 Nr. 4 vor, dass personenbezogene Daten zu
löschen sind, wenn „sie geschäftsmäßig zum Zweck der Übermittlung verarbeitet werden und
eine Prüfung jeweils am Ende des vierten Kalenderjahres beginnend mit ihrer erstmaligen
Speicherung ergibt, dass eine länger währende Speicherung nicht erforderlich ist“. Eine Er-
forderlichkeit, über den Zeitpunkt von vier Jahren hinaus, ist in jedem Einzelfall zu prüfen.
Die Empfänger von Daten aus dem Schuldnerverzeichnis müssen die gesetzlichen Löschfris-
ten einhalten (§ 915g Abs. 1 i. V. m. § 915a Abs. 1 ZPO, § 15 SchuVVO - Schuldnerver-
zeichnisverordnung). Eine Eintragung im Schuldnerverzeichnis wird nach Ablauf von drei
Jahren gelöscht. Für Schuldnerdaten, die nach § 26 Abs. 2 InsO - aufgenommen wurden, gilt
eine Löschungsfrist von fünf Jahren.
Fazit
Im Datenschutzrecht besteht nach Ablauf der Aufbewahrungsvorschriften eine Löschpflicht.
Hierbei sind die Daten unwiderruflich zu entfernen, d.h. zu vernichten. Ein reines Sperren des
Zugriffspfads oder eine Archivierung in nicht mehr produktiven Systemen wären nach diesen
Normen nicht erlaubt. Eine solche Löschpflicht ist bereits aufgrund des Grundsatzes der Da-
tenvermeidung und Datenspeicherung dringend geboten.
22 Az: 5 AZR 286/81, Urteil vom 6. Juni 1984
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 55
Bei relationalen Datenbanken, wie sie in SAP-Anwendungen verwendet werden, hat der An-
wender jedoch keinen Einfluss auf die physikalische Speicherung. Löschung bedeutet Sper-
rung aller weiteren Zugriffe, ohne dass die Daten unbedingt zu 100% gelöscht werden. Theo-
retisch wären sie durch Datenbank-Spezialisten (Administratoren) wieder einsehbar. Es emp-
fiehlt sich, unerlaubt gespeicherte oder falsche bzw. angezweifelte Daten als Datensatz - so-
weit EDV-technisch möglich - unmittelbar zu löschen oder zu sperren Daten, die nicht mehr
zur Erfüllung des Zweckes benötigt werden oder deren Aufbewahrungsvorschrift abgelaufen
ist, sollten in periodischen Abständen gelöscht werden. Anschließend sollte die Datenbank -
soweit zeitlich und technisch möglich - reorganisiert werden.
SAP-Verfahren. Vernichtung von HCM-Daten
Eine regelmäßige Löschung von SAP HCM Datenbeständen kann über das Information-
Lifecycle-Management (ILM) realisiert und umgesetzt werden. Die reine Datenlöschungs-
möglichkeit ist in der Basis-Lizenz des HCM enthalten. ILM erlaubt eine Verwaltung der
„Retention Time“ (Aufbewahrungsfristen) an einer Stelle. Dabei sind die Regeln, nach denen
die Retention Time bestimmt wird, abhängig von der jeweiligen Anwendung. So lassen sich
unterschiedliche Löschfristen für verschiedene Datenkategorien, etwa für An- und Abwesen-
heitszeiten, für Gehaltsdaten oder Bewerbungsdaten, als auch für verschiedene Mitarbeiter-
gruppen, etwa für Beamte oder Angestellte, definieren. Mit der Datenlöschung wird auch der
mögliche Rückrechnungszeitraum entsprechend angepasst. ILM erlaubt eine Löschung (=
Vernichtung) der Daten unabhängig davon, ob die Daten schon archiviert wurden oder ob sich
die Daten noch im produktiven System befinden. Soweit für eine Anwendung sinnvoll, kann
über ILM auch eine Archivierung weiterer personenbezogener Daten ermöglicht werden, dies
ist allerdings nicht in der Basis Lizenz von HCM enthalten.
Die Vernichtung der Daten bedarf der Abstimmung zwischen der zuständigen Fachabteilung,
dem Datenschutzbeauftragten sowie der IT und ist über das Customizing-System einzurich-
ten. Die Durchführung kann sowohl über Programme - etwa als eingeplanter jährlicher Lösch-
lauf – als auch individuell über ein „Zwei-Schritt-Verfahren“ (Setzen eines Löschkennzei-
chens und anschließendes physische Datenlöschung) und unter Beachtung der bestehenden
Berechtigungen erfolgen. Das Setzen des Löschkennzeichens bewirkt im Grunde zunächst ei-
ne Sperrung der betroffenen Daten, damit werden sie über die normalen Transaktionen und
Reports nicht mehr angezeigt. Bis zur Durchführung der Löschung - die innerhalb eines Zeit-
raums von maximal 2 Monaten erfolgen sollte - ist eine Stornierung des Vorgangs möglich.
An Stelle einer Löschung kann ggf. eine Sperrung in Frage kommen, wenn wegen der beson-
deren Art der Speicherung eine Löschung nur mit unverhältnismäßig hohem Aufwand möglich
ist.
Der Datenschutzbeauftragte hat die Aufgabe, die verantwortliche Stelle auf die Einhaltung der
einschlägigen Aufbewahrungs- und Löschfristen hinzuweisen sowie entsprechende organisa-
torische Maßnahmen einzufordern, da diese Stelle die Verantwortlichkeit für die Umsetzung
der vorgeschriebenen Aufbewahrungs- und Löschfristen trägt (der Datenschutz ist hier nur ein
Aspekt). Des Weiteren sind zu den Löschfristen im betriebsinternen Verfahrensverzeichnis
(siehe Kap. 2.3.4) detaillierte Informationen anzugeben.
Ein Anspruch zur Löschung von Daten besteht nicht:
bei gesetzlichen, vertragsmäßigen oder vertragsrechtlichen Aufbewahrungsvorschriften
wenn ein Grund zur der Annahme besteht, dass durch eine Löschung schutzwürdige Inte-
ressen des Betroffenen beeinträchtigt werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 56
2.3.4.6 Geplante Übermittlung in Drittstaaten
Dieser Punkt ergänzt die unter § 4e BDSG zu nennenden Empfänger um die geplanten Über-
mittlungen an Drittstaaten. Hier sind insbesondere die Empfänger in Staaten außerhalb der
EU mit einem nicht EU-konformen Datenschutzstandard aufzuführen. Die verantwortliche
Stelle muss sich hier insbesondere nach den §§ 4b und 4c BDSG richten. Eine Übermittlung
muss unterbleiben, wenn ein angemessenes Schutzniveau nicht vorhanden ist und somit die
berechtigten Interessen des Betroffenen zum Schutz seiner Daten nicht gewährleitstet werden
können.
Als Ausnahmen sind neben der Einwilligung und der Übermittlung zur Erfüllung eines Ver-
trages insbesondere Garantien aus Vertragsklauseln oder verbindliche Unternehmensregelun-
gen (Binding Corporate Rules oder Codes of Conduct) möglich23. Die EU-Kommission selbst
bietet Standardvertragsklauseln für spezielle Übermittlungen von personenbezogenen Daten
in unsichere Drittländer an. Diese Standardvertragsklauseln sind eigenen Verträgen vorzuzie-
hen, da letztere nicht nur von der Aufsichtsbehörde zu genehmigen sind, sondern die erteilten
Genehmigungen nach Art 26 Abs. 3 EU-Richtlinie an die EU-Kommission und die anderen
Mitgliedsländer mitzuteilen sind. Diese Gremien können ihrerseits Widerspruch einlegen und
die Kommission zu geeigneten Maßnahmen über ein Ausschussverfahren drängen.
In den USA können einzelne Firmen durch eine Art Selbstzertifizierung (Stichwort Safe Har-
bor) ein angemessenes Schutzniveau nachweisen. Die aktuelle Mitgliederliste wird im Inter-
net veröffentlicht24.
Es empfiehlt sich, die Datenkategorien getrennt nach dem jeweiligen Drittland und den jewei-
ligen Empfängern anzugeben.
Auch die im Rahmen des Offshoring in Drittländer übermittelten Daten sind in das Verfah-
rensverzeichnis aufzunehmen. Dazu zählt auch eine Datenbank-/Serverbetreuung durch Ad-
ministratoren anderer Konzerngesellschaften in Drittländern. Details zur Auftragsdatenverar-
beitung sind in Kapitel 5 dargestellt.
2.3.4.7 Maßnahmen zur Gewährleistung der Sicherheit
Das BDSG (§ 4e S. 1 Nr. 9) fordert hier
… eine allgemeine Beschreibung, die es ermöglicht, vorläufig zu beurteilen, ob die
Maßnahmen nach § 9 zur Gewährleistung der Sicherheit der Verarbeitung angemes-
sen sind. …
Die Beurteilung der Datensicherungsmaßnahmen hängt u.a. davon ab, welche personenbezo-
genen Daten im Einzelnen verarbeitet werden. Für das betriebsinterne Verfahrensverzeichnis
(siehe Kap. 2.3.4) sind in diesem Zusammenhang detaillierte Angaben erforderlich bzw. mit
den SAP-Hilfsmitteln (vgl. Kap. 2.4) zu beschaffen.
Im Kapitel 4 widmen wir uns ausführlich den Anforderungen aus § 9 BDSG nebst Anlage
und den Umsetzungsmöglichkeiten im SAP ERP. Insbesondere Authentifizierung, Benut-
zeradministration, Berechtigung und Autorisierung werden hier ausführlich behandelt.
23 Siehe Arbeitsunterlage: Übermittlungen personenbezogener Daten an Drittländer: Anwendung von
Artikel 25 und 26 der Datenschutzrichtlinie der EU (WP12)
24 Link: http://web.ita.doc.gov/safeharbor/shlist.nsf/webPages/safe harbor list
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 57
2.3.4.8 Zugriffsberechtigte Personen
Zugriffsberechtigungen auf die Daten von Einzelpersonen bzw. Personengruppen werden
über Rollen bzw. Profile im SAP ERP vergeben und administriert. Die Rollen bzw. Profile er-
lauben bzw. verwehren i. d. R. über Berechtigungsobjekte das Lesen oder Ändern von be-
triebswirtschaftlichen oder technischen Objekten.
Die im SAP ERP-System definierten Rollen bzw. Profile können direkt Personen oder Grup-
pen zugeordnet werden. Über die vergebenen Rollen bzw. Profile können Zugriffsberechtigte
kategorisiert werden.
Das Benutzerinformationssystem (Transaktion SUIM) ermöglicht die Anzeige bzw. Analyse
der zugriffsberechtigten Personen im SAP ERP-System.
Beispiel aus der Personalwirtschaft (SAP HCM):
Verwaltungssachbearbeiter Arbeitgeberleistungen
Vergütungsmanagement
Organisationsmanagement
Fachvorgesetzter /
Disziplinarischer Vorgesetzter
Arbeitgeberleistungen
für Vergütungsmanagement
Organisationsmanagement
Personaladministration
Personalkostenplanung
Beurteilungssystem
Personalentwicklung
Raum Reservierungen
Veranstaltungsmanagement
Sachbearbeiter Leistungslohn
Zeiterfassung
Einsatzplanung
Abrechnung
Für weitergehende Erläuterungen zum Zugriffsschutz und Berechtigungskonzept wird auf
Kapitel 4.2 verwiesen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 58
Hinweise zur Verwendung des SAP Audit Information System und des ABAP Dictionary
werden im Abschnitt 2.4 Systemunterstützung gegeben.
2.3.5 Beispiel Melderegister
Die Aufsichtsbehörden verlangen, die Meldepflicht auf jeden einzelnen Verarbeitungsvor-
gang zu beziehen. In folgendem Beispiel für ein Melderegister sind die Vorschläge des Unab-
hängigen Landeszentrums für Datenschutz Schleswig-Holstein und weiterer Aufsichtsbehör-
den als Grundlagen enthalten25
Wenn man Standardsoftware im Unternehmen einsetzt, sollte man auch auf diese verweisen,
da dort ggf. bestimmte Verfahrensbeschreibungen und Abläufe allgemein zugänglich doku-
mentiert sind.
Öffentlicher Teil
Name/Firma verantwortliche
Stelle
Inhaber, Vorstände, Leiter DV
Anschrift der verantwortlichen
Stelle
Zweckbestimmungen der Da-
tenerhebung, -verarbeitung oder
–nutzung
SAP ERP HCM: Personaladministration, Personalabrech-
nung, Organisationsmanagement, Zeitwirtschaft, Personal-
beschaffung, Personalbetreuung (Vergütung, Arbeitgeber-
leistungen, Altersvorsorge), strategische Personalplanung
SAP for Healthcare: Patientenmanagement, Patientenab-
rechnung, klinische Auftragsabwicklung (Partner), medizi-
nische Dokumentation
SAP EH&S: Gesundheitsdienst, Arbeitsschutz
SAP ERP FI: Pflege und Service für Kunden und Lieferan-
ten
SAP CRM: Marketingplanung und Kampagnenmanage-
ment, Telemarketing, Kontaktmanagement, Kundenservice
Interaction Center, Internet Customer Self-Service, Ser-
vicemanagement, Einsatzplanung,
Betroffene Personengruppen
und diesbezügliche Datenkate-
gorien
Personen: Mitarbeiter, Bewerber, Kunden, Lieferanten,
Versicherungsnehmer, Patienten
Daten: Mitarbeiter-, Bewerber-, Kunden-, Lieferantendaten
nach Standard SAP ERP HCM, SAP ERP FI und SAP
25 www.datenschutzzentrum.de und Zusammenstellung in GDD-Ratgeber „Datenschutz im
Unternehmen“ 7. Aufl. 2010, S. 213 ff
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 59
CRM;
Besondere Arten personenbezogener Daten nach § 3 Abs.9
BDSG, zum Beispiel:
Patientendaten nach Standard SAP for Healthcare;
betriebliche Gesundheits- bzw. Arbeitsschutzdaten nach
Standard SAP EH&S;
Daten zur Gewerkschaftszugehörigkeit, ethnische Herkunft,
Religionszugehörigkeit, nach Standard SAP ERP HCM
Empfänger oder Kategorien von
Empfängern
Vertragspartner, Banken, Bausparkassen, Versicherungen,
Finanzamt, Krankenkassen, Versorgungsanstalten, Auf-
tragsdatenverarbeiter
Regelfristen für die Löschung
der Daten
Allgemein: Periodische Löschung nach Ablauf der gesetzli-
chen Aufbewahrungsfristen
Detailliert:
unterschiedliche Löschfristen für einzelne Datenarten
Frist oder Zeitpunkt für die Überprüfung der Erforder-
lichkeit der Datenbestände
Geplante Datenübermittlung in
Drittstaaten
Datenkategorien unterteilt nach Drittstaaten und Empfän-
gern
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 60
Nichtöffentlicher Teil
Allgemeine Beschreibung zur
Beurteilung der Angemessenheit
der Schutzmaßnahmen nach § 9
BDSG
Vorlage eines gesonderten Sicherheitskonzepts
Vorgesehene Protokollauswertungen
Systemumgebung: Systemsoftware (Betriebssystem, DB,
Netzwerk), Anwendungssoftware (SAP ERP;
www.sap.com), Sicherungssoftware (Antivirus, Firewall,
Kryptographie, ...)
Technisch-organisatorische Maßnahmen nach § 9
BDSG
Kontrolle Maßnahmenbeispiele
Zutritt Gesicherte Gebäude und Räume
Zugang PC-Sperre, Kennwortregeln
Zugriff Rollen, Berechtigungen
Weitergabe Kryptographie, digitale Signatur
Eingabe Protokollierung, Belege
Auftrag Vertragsregelungen, Prüfung
Verfügbarkeit DB-Recovery, Sicherungskopien außer
Haus
Trennung Systemtrennung, Mandanten
2.4 Systemunterstützung
Im SAP-System ist das ABAP Dictionary zur Verwaltung aller im System verwendeter Daten
vorgesehen. Das ABAP Dictionary gibt Auskunft über Tabellen, Domänen und Felder und
kann als Verwendungsnachweis in Reports, Dynpros oder weiteren Tabellen herangezogen
werden.
In diesem Abschnitt wollen wir einen kurzen Einblick in Techniken zur Erstellung einer
Übersicht über Daten und Datenkategorien für die Verfahrensbeschreibung sowie die Prüfung
von Zugriffsberechtigungen geben. Die vorgestellten Funktionen können auch Änderungsbe-
rechtigungen beinhalten, dies ist bei der Rollendefinition zu beachten.
Hilfreiche Systemunterstützung bieten dem DSB auch Werkzeuge wie z.B. SAP GRC Access
Control (siehe Kapitel 6.5 SAP GRC (Governance, Risk and Compliance)), SECURINFO for
SAP (www.securinfo.com), ZRPDINF01 (www.forba.de) oder CheckAud (www.check-
aud.de) (siehe auch Akquinet.de), die insbesondere zur Analyse der genutzte
personenbezogenen Daten und der Umsetzung der Sicherheitsmaßnahmen sowie von
Berechtigungskonzepten eingesetzt werden. Der DSB sollte sich diesbezüglich mit anderen
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 61
Abteilungen bzw. der IT in Verbindung setzen, um die Verfügbarkeit im Unternehmen zu
verifizieren.
Hinweis: Zum besseren Verständnis der benutzten Transaktionen lassen sich die technischen
Namen wie folgt in die Menüs einblenden:
Menüpfad:
Zusätze -> Einstellungen -> Technische Namen anzeigen
2.4.1 Auswertungen zur Tabellen- und Feldanalyse
Im Folgenden werden Hinweise gegeben, wie die verantwortliche Stelle dem Datenschutzbe-
auftragten mit SAP-technischen Mitteln die erforderlichen Übersichten gemäß BDSG erstel-
len kann.
Die folgende Aufzählung aller Tabellen mit personenbezogenen Daten des SAP-Standards
kann nicht vollständig sein, da hier die kundenspezifischen Erweiterungen, Modifikationen
oder Löschungen nicht berücksichtigt sein können.
Mit Hilfe des ABAP Dictionary kann dynamisch eine Tabellenübersicht erzeugt werden, die
den aktuellen Kundenstand wiedergibt.
Im Einzelfall können Verwendungsnachweise von Domänen oder Datenelementen zu abhän-
gigen Reports, Dynpros und Tabellen ermittelt werden.
Grober Überblick:
In einer Tabellenübersicht kann eine Kurzbeschreibung der Infotypen bzw. Tabellen erstellt
werden. Beispiele:
PA0* Personalstammdaten
HRP1* Personalplanungsdaten, -entwicklungsdaten
PA2* Zeitdaten
PB0* Stammdaten Bewerber
PB4* Bewerberdaten
PCL* Clustertabellen (HCM)
TRV* Reiseplanung und Reisekostenabrechnung
KN* Kundenstamm
LF* Lieferantenstamm
SADR* Adressverwaltung
Menüpfad:
Werkzeuge -> ABAP Workbench -> Entwicklung -> Dictionary (SE12): Objektname PA0*
als Datenbanktabelle: Anzeigen oder Drucken
Mit Hilfe dieser Übersichten können über das ABAP Dictionary gezielt einzelne Tabellen o-
der Felder bearbeitet werden.
Wir empfehlen, die Berechtigung für den Zugriff auf Tabellen mit personenbezogenen Daten
nur im Ausnahmefall und befristet zur fachlichen Betreuung und Fehleranalyse zu erteilen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 62
Daten des Personalwirtschaftsbereichs (HCM / HR)
Im HCM werden die Daten als Infotypen und Infosubtypen verarbeitet. Die Personalstamm-
daten und Zeitdaten sind in den Tabellen PAxxxx abgelegt. Eine Tabelle PAxxxx enthält ne-
ben systemspezifischen Einträgen wie z.B. Schlüssel nur die Daten des jeweiligen Infotyps
xxxx.
Eine ausführliche Darstellung der einzelnen Tabellen erhält man über das ABAP Dictionary
(SE12) bzw. das Repository Infosystem (Object Navigator, SE84).
Folgende Reports bieten einen Überblick über die Infotypen:
Infotypen und Subtypen (Report RPDSHOWI) listet die Infotypen und Subtypen mit An-
gabe der Infotypstruktur auf.
Infotypen und Subtypen mit DB-Statistik (Report RPDINF01) bietet zusätzlich noch eine
Datenbankstatistik der tatsächlich in der vorliegenden SAP-Installation verwendeten Info-
und Subtypen an. Außerdem dokumentiert die Infotyp-Übersicht für einen Mitarbeiter
(Report RPLINFC0) die für einen bestimmten Mitarbeiter belegten Infotypen, die mit dem
Report RPLERDX0: Auskunft mitarbeiterbezogener Daten(s. Hinweis 1569378) angezeigt
werden können.
Im Audit Information System sind die obigen Reports auch verfügbar.
In der Personalplanungskomponente werden personenbezogene Daten über Infotyp 1001 mit
einer Person verknüpft, wie z.B. Seminare, Qualifikationen, Karrierepfade, Vorsorgeuntersu-
chungen. Die einzelnen Verknüpfungsarten bzw. Subtypen sind in Tabelle T778V verzeich-
net. Alle Verknüpfungsdaten werden zentral in der Tabelle HRP1001 abgelegt.
Für einzelne Verknüpfungsarten (vgl. Tabelle T77AR) werden darüber hinaus noch Zusatzda-
ten in Tabellen der Form HRPAD* (vgl. Tabelle T77AD) gespeichert.
Eine Darstellung der einzelnen Tabellen (HRP1001, HRPAD*) liefert neben dem ABAP Dic-
tionary auch der Report RHDDIC00:Tabellenfelder aus dem DataDictionary.
Benutzerdaten 1 (Benutzerverwaltung)
Welche Tabellen gibt es im SAP-System, die Benutzerwerte speichern?
Tabellenname: US*
Domäne: XUBNAME Benutzername im Benutzerstamm
Benutzerdaten 2 (Sachbearbeiterkennzeichen)
Domänen:
AENUS Username der letzten Änderung
AS4USER Autor der letzten Änderung
BNAME Benutzername
BUSAB Nummer des Buchhaltungs-Sachbearbeiters
DDUSER Dictionary: Letzter ändernder Benutzer
DWNAM Name des zuständigen Sachbearbeiters
RALDB_NAME Name des Erstellers/Änderers der Variante
SACHA Sachbearbeiter Abrechnung/Personal/Zeiterfassung
UNAME Benutzername
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 63
UBNAME Benutzernamen
USERNAME Benutzername (SAP-Benutzer)
USNAM Name des Benutzers
XUBNAME Benutzername im Benutzerstamm
XUSER Benutzername
Benutzerdaten 3 (Protokolldaten)
Protokolldaten befinden sich u.a. im Accounting, Systemlog (SM21) und in den Protokollda-
teien.
Die Accountingdaten werden über die Abrechnungsnummern im Benutzerstamm identifiziert.
Die Auswertung des Accounting bzw. der Statistiksätze wird in der Transaktion des Work-
load Monitors durchgeführt.
Menüpfad:
Werkzeuge -> Administration -> Monitor -> Performance -> Systemlast -> Aggregierte Sta-
tistiksätze (ST03N/ST03G) oder Statistik-Einzelsätze (STAD)
In der Systemlogdatei (SM21) wird der Benutzername festgehalten:
Feldname: Benutzer
2.4.2 Techniken zum Auffinden personenbezogener Daten
Variante 1: Bei Projekteinführung
In der Einführungsphase werden vom Projektteam mit dem Datenschutzbeauftragten und dem
Betriebs- bzw. Personalrat die zulässigen personenbezogenen Daten festgelegt und deren
Auswertungen überprüft.
Hierbei werden die entsprechenden Transaktionen, Dynpros und Reports analysiert.
Durch Sperren von Transaktionen und Reports sowie durch Dynprovariationen im Customi-
zing kann die Eingabe der nicht zulässigen personenbezogenen Daten verhindert werden. Das
hätte den Vorteil, dass Variante 2 nur noch für zusätzliche Kontrollen benötigt würde.
Über die F1-Hilfe ist es möglich, aus den Dynpros das Dynprofeld zu ermitteln mit den ent-
sprechenden Namen von Tabelle, Feld, Datenelement und Domäne. Das ABAP Dictionary
ermöglicht mit diesen Informationen, Verwendungsnachweise in Programmen, Dynpros und
Tabellen der Einzelfelder zu ermitteln. Sofern hierbei kein Tabellenname sondern ein Struk-
turname angezeigt wird, ist die zugrunde liegende Datenbanktabelle über den Verwendungs-
nachweis zum angezeigten Datenelement zu bestimmen.
Beispiel: Transaktion PA20 mit Infotyp Bankverbindung:
F1-Hilfe liefert unter technischer Info bei Bankkonto:
Dynprofeld P0009-BANKN
Tabellenname P0009
Datenelement BANKN
Feldname BANKN
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 64
Menüpfad:
Werkzeuge -> ABAP Workbench -> Übersicht -> Infosystem-> ABAP Dictionary -> Daten-
elemente mit Auswahl BANKN -> Hilfsmittel -> Verwendungsnachweis -> indirekte Verwen-
dung (SE12)
Verweist z.B. auf Tabellen, Programme oder Dynpros.
Variante 2: Im aktiven System
Tabellen mit Personenbezug sind im SAP-System nicht als solche bezeichnet, können aber
mit dem ABAP Dictionary über Domänen ermittelt werden.
Wichtige Domänen:
AD_PERSNUM Personennummer (Adresse)
AFNAM Name des Anforderers in der Bestellanforderung
APLNO Bewerbernummer
APLNR Bewerbernummer
CATSXT_CALLER_ID Identifikation des Aufrufers
DISPO Disponent
EKGRP Einkaufsgruppe
KUNNR Kundennummer
LIFNR Kontonummer des Lieferanten
NAME Name eines Partners
FALNR Fallnummer (im IS-H)
PATNR Patientennummer (im IS-H)
PERSONAL_NUMBER Personalnummer
PERSNO Personalnummer
PERSONID Personennummer
PERNR Personalnummer
VKGRP Verkäufergruppe
Folgende Domänen haben ebenfalls Namensbezug:
BDEUNAME Benutzer im DASS
CYFC_NAME Name des Erstellers/Änderers einer Ablaufsteuerung
DOKU_USER Benutzername
HIER_USER Benutzername
I_PARNR Partner (Partnerpflege PM)
J_1BPARID Partneridentifikation (Kunde, Lieferant, Branch)
KUNDE Partnernummer (KUNNR,LIFNR,PERNR,PARNR)
NA_PARNR Partnernummer
QPRUEFER Name des Prüfers
RFC_TC_ID Benutzername des persönlichen Talentberaters
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 65
SC_OWNER Benutzername (Terminkalender)
SPARTNR Partnernummer
SO_ADRNAM SAPoffice: Adressname eines Officebenutzers
SO_SADRNAM SAPoffice: abgekürzter Adressname
STAT_USER Statistik, Account
TDUSER TDIC User
UDUSER Autor
XUAUTH Berechtigungsname
XUNAME1 Name des Benutzers (Adresse)
Das Datenelement GPART Geschäftspartner (z.B. Ärzte im SAP for Healthcare) kann eben-
falls Personenbezug haben (Domäne: RI_Rolle).
Um mit Hilfe des Reports RSCRDOMA aus dem Audit Information System ein firmenspezi-
fisches Verfahrensregister zu erhalten, sind die oben genannten Personen identifizierenden
Domänen zu überprüfen und ggf. zu ergänzen (AIS-Funktion: Dateiregister zu personenbezo-
genen Daten).
Dokumentation von Datenfeldern
Im ABAP Dictionary stehen Funktionen zur Verfügung, um bis auf die Einzelfelder von Ta-
bellen verzweigen zu können:
Anzeigen bzw. Drucken von Tabellen und Feldern (auch als Tabellenhandbuch mit RSS-
DOCTB druckbar)
Menüpfad:
Werkzeuge -> ABAP Workbench -> Übersicht -> Infosystem -> ABAP Dictionary -> Fel-
der -> Strukturfelder (SE84) P000* Drucken
Verwendungsnachweis von Tabellen, Datenelementen und Domänen
Über das ABAP Dictionary können Informationen zu Tabellen, Strukturen, Feldnamen, Da-
tenelemente und Domänen, sowie deren Verwendung in Programmen, Dynpros und Tabellen
ermittelt werden.
Menüpfad:
Werkzeuge -> ABAP Workbench -> Entwicklung -> Dictionary mit Auswahl Domänen und
Objektname 'PERSNO' für Personalnummer -> Hilfsmittel -> Verwendungsnachweis -> indi-
rekte Verwendung (SE12): verweist z.B. auf DB-Tabellen, Programme oder Dynpros.
2.4.3 Prüfung der Zugriffsberechtigungen
Das Benutzerinformationssystem bietet eine maschinelle Unterstützung, um die Zugriffsbe-
rechtigungen zu überprüfen.
Das Benutzerinformationssystem ist als Berichtsbaum über die Transaktion SUIM aufrufbar.
Hiermit können z.B. Benutzer mit bestimmten Berechtigungen, Rollen oder Profilen identifi-
ziert werden. Siehe hierzu auch Kapitel 4.3 bzw. 6.3.
Menüpfad:
Werkzeuge -> Administration -> Benutzerpflege -> Infosystem.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 66
Wer ist im System aktiv?
SM04 (Benutzerliste) bzw. AL08 (Liste aller angemeldeten Benutzer)
Anzeigen der aktiven Benutzer in einem definierten Mandanten bzw. im gesamten Sys-
tem.
Welche Benutzer (mit Adressdaten) gibt es im SAP-System?
SUIM Berichtsbaum anzeigen (siehe oben)
Menüpfad:
Infosystem -> Benutzer -> Benutzer nach Adressdaten -> Liste erzeugen -> * zeigt alle
Benutzer an
Änderungsbelege für Benutzer, Profile, Berechtigungen und Rollen sind direkt aus dem
SUIM-Berichtsbaum und im AIS über die Schaltfläche Änderungsbelege aufrufbar (Re-
ports RSUSR100, RSUSR101, RSUSR102, RSSCD100_PFCG).
Die Protokollanzeige der Zentralen Benutzerpflege kann mit dem Report RSUSRLOG er-
folgen.
Gezielte Selektionen zur Analyse eines SAP-Berechtigungskonzeptes können insbesonde-
re auch über den Schalter Benutzer nach komplexen Selektionskriterien für Benutzer mit
bestimmten Berechtigungen, Profilen, Rollen und Transaktionscodes erfolgen. Hierbei ist
auch eine Selektion nach Feldwerten in Berechtigungsobjekten möglich.
Welche Tabellen gibt es im SAP-System, die Benutzerwerte speichern?
SE16 und SE16N Data Browser
Tabellenname: USR* Anzeige aller Tabellen mit aktuellen Benutzerdaten
Tabellenname: USH* Anzeige aller Tabellen mit Benutzeränderungsbelegen
Sowie die Tabellen UST* und USL*.
TAANA Tabellenanalyse
Mit dem Transaktionscode TAANA: Tabellenanalyse aus dem Arbeitsfeld Archivierung
kann eine Detailsicht der vorhandenen personenbezogenen Daten vor allem für große und
für nicht indexierte Datentabellen erstellt werden. Es wird die Anzahl der Datensätze für
eine bestimmte Feldauswahl ermittelt und abgespeichert. Die Auswahl läßt sich temporär
( ad-hoc) eingeben und ausführen.
Über den Transaktionscode TAANA_AV: Tabellenanalyse_Analysevarianten kann die
Analyse dauerhaft anlegt werden und dann mit TAANA angestartet werden.
Die Feldauswahl BUKRS, VORGN, PERNR, GJAHR zeigt z.B. für die Tabelle BSEG:
Belegsegment_Buchhaltung die Anzahl der für eine Person vorhandenen Sätze mit glei-
chen Buchungskreis, Geschäftsjahr und betriebswirtschaftlichem Vorgangsschlüssel an.
Die Feldauswahl BUKRS, PERNR, PERNR, GJAHR, VRGNG zeigt z.B. für die Tabelle
COEP: CO-Objekt Einzelposten periodenbezogen die Anzahl der für eine Person vorhan-
denen Sätze mit gleichen Buchungskreis, Geschäftsjahr und betriebswirtschaftlichem
Vorgangsschlüssel an.
Welche Reports (ABAP) gibt es für die Benutzerverwaltung?
SA38 ABAP Reporting
Menüpfad:
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 67
System -> Dienste -> Reporting -> Programm RSUSR* (alle Programme zur Benutzer-
auswertung) -> F4-Suchhilfe -> Ausführen -> Programmnamen selektieren -> Auswählen
(= Ausführen)
Viele wichtige Reports werden im Rahmen des Benutzerinformationssystems zur Verfü-
gung gestellt, die auch separat über das ABAP Reporting (SA38) gestartet werden können:
Benutzer RSUSR002, RSUSR008, RSUSR009,
RSUSR008_009_NEW
Rollen RSUSR070, RSSCD100_PFCG
Profile RSUSR020
Berechtigungsobjekte RSUSR030, RSUSR040
Berechtigungen RSUSR030
Transaktionen RSUSR010
Vergleiche RSUSR050
Verwendungsnachweise RSUSR002, RSUSR020, RSUSR030, RSUSR070 (SAP-
Hinweis 608661), RSUSR060OBJ
Änderungsbelege RSUSR100, RSUSR101, RSUSR102, RSSCD100_PFCG
Weitere Reports:
RSUSRSUIM Benutzerinformationssystem
RHUSERRELATIONS Benutzerzuordnungen anzeigen (für HCM Berechtigungs-
objekte); frühere Transaktion OOAC, aktuell: Transaktion
HRAUTH (mit Reiter: „Benutzerspezifisch“)
RSUSR000 Aktive Benutzer
RSUSR003 In allen Mandanten die Kennwörter der Standard-Benutzer
prüfen
RSUSR005 Liste der Benutzer mit kritischen Berechtigungen
RSUSR006 Gesperrte Benutzer und Benutzer mit Falschanmeldungen
RSUSR012 Suche Berechtigungen, Profile und Benutzer mit bestimm-
ten Objektwerten
RSUSR060OBJ Verwendungsnachweis Berechtigungsobjekt in Program-
men und Transaktionen
RSUSR200 Liste der Benutzer nach Anmeldedatum und Kennwortände-
rung
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 68
3 Rechte der Betroffenen und von jedermann
Rechte der Betroffenen
Grundlage für die Rechte der Betroffenen ist das Transparenzgebot des BDSG. Danach ist der
Betroffene bereits bei der Erhebung seiner Daten, z. B. beim Vertragsabschluss, über die
Zweckbestimmung und die wesentlichen Umstände des Umgangs mit seinen Daten zu infor-
mieren (§ 4 Abs. 3 BDSG). Gemäß § 28b Nr. 4 BDSG ist beim Scoring (Berechnung des
Wahrscheinlichkeitswertes) sogar die Unterrichtung zu dokumentieren, wenn dazu Adressda-
ten verwendet werden. Soweit die Information nicht bereits bei der Datenerhebung erfolgt ist
oder Betroffene später weitere Informationen anfordern, besteht die Verpflichtung der ver-
antwortlichen Stelle zur Benachrichtigung der Betroffenen gem. § 33 BDSG und gem. § 6
Abs. 1 BDSG zur Beachtung der unabdingbaren Rechte des Betroffenen auf Auskunft (§§ 19,
34 BDSG) sowie auf Berichtigung, Löschung oder Sperrung (§§ 20, 35 BDSG). Hierzu gibt
es einige ergänzende Informationspflichten:
§ 28 Abs. 3 BDSG verlangt, dass bei einer Verwendung von Adressdaten zu eigenen Werbe-
zwecken, wenn diese von Dritten stammen - die Stelle, die die Daten erstmalig erhoben hat,
aus der Werbung eindeutig hervorgeht.
§ 42a BDSG verlangt eine unverzügliche Information der zuständigen Aufsichtsbehörde und
des Betroffenen, wenn eine nicht öffentliche oder öffentliche Stelle feststellt, dass bei ihr Da-
ten nach Satz 1 Nummern 1. – 4. des § 42a BDSG unrechtmäßig übermittelt oder auf sonstige
Weise Dritten unrechtmäßig zur Kenntnis gelangt sind, und schwerwiegende Beeinträchti-
gungen der Rechte und der schutzwürdigen Interessen der Betroffenen drohen.
Ausdrücklich hingewiesen sei in diesem Zusammenhang darauf, dass nach § 43 BDSG eine
vorsätzlich oder fahrlässig nicht erfolgte, nicht richtige oder nicht vollständige Benachrichti-
gung des Betroffenen eine Ordnungswidrigkeit darstellt. Diese kann im Fall des § 43 Abs. 1
BDSG mit einer Geldbuße bis zu EUR 50.000,- und im Fall des Absatzes 2 mit einer Geldbu-
ße bis zu EUR 300.000 geahndet werden.
Rechte von jedermann
Eine weitere Umsetzung des Transparenzgebotes findet sich im § 38 Abs. 2 BDSG wieder.
Danach kann das von der Aufsichtsbehörde geführte Register nach § 4e S. 1 Nr. 1-8 BDSG
von jedem (Recht von jedermann) eingesehen werden.
Das Recht von jedermann von der verantwortlichen Stelle etwas über die gespeicherten Daten
zu erfahren, findet sich ferner im § 4g Abs. 2 S. 2 BDSG wieder. Hier ist der Beauftragte für
den Datenschutz zuständig – auf Antrag – jedermann die Angaben gem. § 4e S. 1 Nr. 1-8
BDSG in geeigneter Weise verfügbar zu machen.
Zusammenfassend ist festzuhalten, dass das Informations- und Transparenzgebot von der ver-
antwortlichen Stelle, dem Beauftragten für den Datenschutz und der Aufsichtsbehörde zu ge-
währleisten ist.
Allerdings ist der Umfang und die konkrete Umsetzung dieser Rechte zwischen dem Recht
der Betroffenen und jedermann zu differenzieren.
Bei dem Recht der Betroffenen handelt es sich um ein detailliertes Informations- und Aus-
kunftsrecht, welches die Inhalte jedes einzelnen Datums zu seiner Person umfasst.
Beim Jedermannrecht ist in der Regel dem Informations- und Auskunftsrecht genüge getan,
wenn die Struktur der Dateien bzw. die Tatsache, dass überhaupt personenbezogene Daten er-
hoben, verarbeitet und genutzt werden, bekannt gegeben werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 69
3.1 Benachrichtigung und Auskunft
3.1.1 Rechtliche Anforderungen
In der Regel werden personenbezogene Daten in SAP ERP-Systemen nur auf Basis einer
(vor-) vertraglichen Grundlage (z. B. Arbeitsvertrag, Kaufvertrag) gespeichert. Daher wird die
Benachrichtigungspflicht in der Regel durch die Information bei der Erhebung (§ 4 BDSG)
verdrängt (zu Ausnahmen bei CRM-Systemen s. Leitfaden hierzu).
Daher sind Benachrichtigungen und die Beantwortung von Auskunftsersuchen (Antrag des
Betroffenen erforderlich) individuell zu behandeln.
Bei der Benachrichtigung sind Angaben zu einer konkreten Verarbeitung in allgemeiner Form
zu machen, z. B. Datenkategorien, Kategorien möglicher Empfänger. Die Frage, ob eine Be-
nachrichtigungspflicht für konkrete Verarbeitungsprozesse besteht, und die Organisation der
Benachrichtigung inklusive ihrer Dokumentation sind bereits zu Beginn der Verarbeitung /
Verfahrenseinführung zu klären (s. a. Kap. 1, Kap. 2.3).
Dagegen hat der Betroffene im Rahmen des Auskunftsrechts einen Anspruch auf vollständige
Auskunft über alle der verantwortlichen Stelle zu seiner Person zur Verfügung stehenden Da-
ten. Dabei sind dem Betroffenen die konkreten Daten in verständlicher Form mitzuteilen.
3.1.2 SAP-Fakten
Es gibt im SAP-Standard keinen zusammenfassenden Report, der sozusagen auf Knopfdruck
alle zu einer Person gespeicherten Daten für die Auskunftserteilung oder zur Benachrichti-
gung eines Betroffenen anzeigt oder ausdruckt.
Diese Feststellung trifft auch für einzelne Module zu, in denen ein Betroffener in seiner Rolle
als Arbeitnehmer, als Kunde, Patient, Lieferant, Geschäftspartner oder ähnliches gespeichert
ist. Gleichwohl gibt es in einzelnen Modulen Anzeige- und Druckmöglichkeiten, mit denen
einzelne Aspekte eines Datensatzes zu einer Person ausgegeben werden können.
Als Hilfsmittel im SAP ERP-System bietet sich das Audit Information System (AIS) an (vgl.
hierzu Kap. 6.3), wobei die Funktionalitäten im Rahmen der Übersichten (Dateiregister26 zu
personenbezogenen Daten) grundsätzliche Informationen über die verwendeten Tabel-
len/Domänen mit Personenbezug liefern.
Im ERP steht für kundenbezogene Daten das Customer Fact Sheet zur Verfügung.
Transaktion VC/2 (Programm RVKUSTA1). Das Kundenstammblatt kann auch aus
verschiedenen ERP Transaktionen heraus aufgerufen werden, z. B. VA01, VC01N.
Das Kundenstammblatt kann ausgedruckt werden: Programm SD_CFS_PRINT01
Für SAP ERP HCM (Personalwirtschaft) steht die Funktion „Infotypübersicht für einen Mit-
arbeiter“ zur Verfügung (Personal Personalmanagement Administration Personal-
stamm Anzeigen), mit der alle für einen Mitarbeiter tatsächlich belegten Infotypen ange-
zeigt werden. Mit der entsprechenden Transaktion des SAP ERP HCM (PA20, ‚Personal-
26 Eine Anpassung der Terminologie an die aktuelle Rechtslage des BDSG durch die SAP steht bislang
aus.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 70
stammdaten anzeigen’) können im zweiten Schritt die Daten der belegten Infotypen für eine
Auskunftserteilung ausgedruckt werden27.
Der Report RPLERDX0 „Auskunft mitarbeiterbezogener Daten“ (s. Hinweis 1569378) gibt
Auskunft über die im System gespeicherten Daten zu einem Mitarbeiter und zeigt alle zu sei-
ner Person in den verschiedenen Infotypen des HCM gespeicherten Daten an. Die Informatio-
nen werden am Bildschirm dargestellt und können über die Drucktaste – etwa zur Beantwor-
tung eines Auskunftsersuchens – angedruckt und dem Antragsteller ausgehändigt werden. Je-
de Ausführung dieses Reports wird protokolliert, da hier zum Teil sehr sensible Informatio-
nen angezeigt werden. Dabei werden der entsprechende Benutzername, das Datum und die
Zeit der Ausführung, der Ausgabebereiche sowie der Grund der Ausführung in einer entspre-
chenden Tabelle gespeichert.
Zur detaillierten Konfiguration gibt es das Kapitel „Auskunft mitarbeiterbezogener Daten“ im
IMG unter Personalmanagement Personaladministration
3.1.3 Anforderungen an die Organisation des Datenschutzes
Da es keine universelle Unterstützung des SAP-Systems gibt, die es dem Anwender (i.d.R.
datenschutzrechtlich verantwortliche Stelle oder DSB bzw. dessen Hilfspersonal) erleichtert,
den Anforderungen des BDSG in Bezug auf die Auskunftspflicht nachzukommen28, muss sich
der Anwender einen Arbeitsplan erstellen, in dem festgehalten wird, wie im konkreten Fall
das Auskunftsersuchen eines Betroffenen mit den vorhandenen Mitteln befriedigt werden
kann.
Ein systematisches Vorgehen bei der Organisation der technischen Umsetzung von Aus-
kunftsersuchen kann folgende Elemente enthalten:
Eine rechtliche Prüfung, auf welche Rechtsgrundlage sich das Auskunftsersuchen eines
Betroffenen stützt, ob es sich um eine auskunftsberechtigte Person handelt, ob eine Aus-
kunft ggf. nicht erforderlich ist usw.
Bestimmung der Rolle, in der der Betroffene zur verantwortlichen Stelle steht, um
dadurch die zu untersuchenden Datenbereiche eingrenzen zu können. Eventuell kann man
einem Auskunftssuchenden Hilfsmittel anbieten, um seine Daten “näher zu bezeichnen“,
falls das für die Abwicklung der Auskunftserteilung hilfreich sein sollte.
Bestimmung der Module, die im Unternehmen in Einsatz sind und in denen Daten des Be-
troffenen aufgrund seiner Rolle enthalten sein können.
Extraktion der Daten aus dem System: Da es für diesen Schritt (mit Ausnahme der o.a. ge-
schilderten Funktion für die Personalwirtschaft) keine speziellen Hilfsmittel gibt, muss man
versuchen, ihn mit den vorhandenen Möglichkeiten zu bewältigen. Mögliche Ansätze sind:
27 Hierzu steht auch eine allgemein verfügbare Auswertung (Z_RPDINF001) zur kostenlosen Bestellung
unter www.forba.de zur Verfügung
28 SAP bietet inzwischen mit TREX / SES eine Suchmaschine an, die auch Datentabellen durchsuchen
kann und daher zum Suchen nach Namen bzw. personenbezogenen Daten geeignet ist. Die Nutzung
der TREX/SES-Funktionen bedarf allerdings der exakten beschränkenden Regelungen, da
Suchmaschinen immer die Gefahr beinhalten, jede Zweckbindung und die erforderliche
Vertraulichkeiten personenbezogener Daten aufzuheben.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 71
ABAP Dictionary
Ein systematisches Vorgehen über das ABAP Dictionary mit der Transaktion SE11 bzw.
SE12. kann z.B. folgende Schritte umfassen:
1. Bestimmung der Domänen, die in diesem Fall auf personenidentifizierende Daten verwei-
sen (z.B. PERSNO (Personalnummer) im SAP ERP HCM, PATNR (Patientennummer)
und FALNR (Fallnummer) im SAP for Healthcare (IS-H), USNAM (Name des Benutzers
bei Benutzerdaten)
2. Anschließend sind für alle beteiligten Domänen die betroffenen Tabellen nachzuweisen
3. Zu sämtlichen betroffenen Tabellen sind über das ABAP Dictionary oder den Data Brow-
ser (Transaktion SE17) eine Datenanzeige für alle der Auskunft unterliegenden Datenfel-
der aufzurufen. Enthält die Tabelle tatsächlich Daten über den Betroffenen, dann sind die
Daten per Hardcopy, per Download in ein Textverarbeitungsprogramm oder per Ausdruck
auszugeben.
4. Zur Aufbereitung der Auskunft in einer verständlichen Form sind Schlüsselfelder im Voll-
text auszugeben und unverständliche Datenfeldbezeichnungen im Klartext neben die
technische Feldbezeichnung zu schreiben.
5. Schritt 3. und 4. sind für alle in Frage kommenden Tabellen zu wiederholen.
Sonstige Möglichkeiten
Es sind noch weitere Möglichkeiten denkbar, die in Frage kommenden Tabellen zu bestim-
men, z.B. über die Anwendungshierarchie (Transaktion SE81) oder das Repository-
Infosystem (Transaktion SE84).
Über die Anzeigetransaktionen und ABAP-Programme der Fachmodule
Es müssten alle einer jeweiligen Rolle zugehörigen (Anzeige-) Transaktionen und Dynpros
ermittelt und diese vollständig per Hardcopy dokumentiert werden. Nicht zu beauskunftende
Daten (z.B. Name des erfassenden Sachbearbeiters) sind aus den Ausdrucken ggf. zu entfer-
nen, wenn die Hardcopies im Original weitergegeben werden sollen. Einschlägige Anzeige-
transaktionen können den bearbeitenden Sachbearbeitern auch im Benutzermenü zur Verfü-
gung gestellt werden. (Zur Einrichtung von Favoriten siehe die SAP ERP-Dokumentation).
Einschlägige Reports können durch die Ergänzung in Bereichsmenüs (Bereichsmenüpflege
Transaktion SE43N) dem Endbenutzer zur Verfügung gestellt werden.
Über Reports
Zu einzelnen Themen gibt es Reports oder Transaktionen, die einen Teil der gespeicherten
Daten ausgeben.
Beispiele aus dem SAP ERP HCM:
Personalstammblatt (Aufruf mit dem Report RPPSTM00)
Die Personalakte zeigt alle Stammdaten einer Person an.
Menüpfad:
Personal Personalmanagement Administration Personalstamm Personalakte
(PA10)
Infotypübersicht für einen Mitarbeiter im Audit Information System (AIS) oder direkt mit
dem zugrunde liegenden Report RPDINF01.
Es werden aber nicht die gespeicherten Daten ausgegeben, sondern nur die Datenstruktur, so
dass man, je nach Anfrage des Betroffenen, ggf. nacharbeiten muss.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 72
Über Queries
Sind entsprechende Sachgebiete eingerichtet, dann können die geforderten Auskünfte auch
mit ABAP Query erzeugt werden. Voraussetzung dafür ist jedoch, dass die betroffenen Tabel-
len und Datenfelder bei der Erstellung einschlägiger Sachgebiete ermittelt wurden.
Je nach Query-Werkzeug (SAP-Query, Ad-Hoc-Query und Qick-Viewer) sind unterschiedli-
che Berechtigungen zum Anlegen/ Pflegen der Query-Funktion und zum Ausführen der
Query-Funktion erforderlich. Abhängig von der ausgewählten Datenquelle (Tabellen-
Join/View, Sachgebiet/SAP Query InfoSet, Tabelle, Logische Datenbank) werden unter-
schiedliche Berechtigungen für das Ausführen der Query-Funktion benötigt.’ Bei Auswahl
oder der Auswahlmöglichkeit von Tabellen oder Tabellen-Joins/Views sind Tabellenberechti-
gungen (Berechtigungsobjekt: S_TABU_DIS) erforderlich.
Queries müssen als kritische Berechtigung eingestuft werden, da die Tabellenberechtigungs-
gruppen regelmäßig nicht detailliert auf das Kundensystem und die Sicherheitsanforderungen
des Kunden abgestimmt sind, Sie sind durch vordefinierte Reports, die in Transaktionen um-
gesetzt werden, zu ersetzen. Davon kann abgesehen werden, wenn es ein detailliertes und do-
kumentiertes Berechtigungskonzept für Tabellen gibt, das auf Datensatz-/feldebene die Risi-
ken bewertet.
Fazit :
Alle aufgezeigten Möglichkeiten sind - außer im SAP ERP HCM - recht arbeitsaufwen-
dig, so dass es bei häufiger auftretenden Auskunftsersuchen sinnvoll sein kann, spezielle
Reports programmieren zu lassen.
Zur Auskunft nach § 34 BDSG gehören auch Zweck der Speicherungen und Personen o-
der Stellen, an die die Daten übermittelt werden. Diese Angaben können u.U. dem Ver-
fahrensverzeichnis gemäß § 4d BDSG entnommen und müssen der Auskunft beigefügt
werden. Zuletzt ist der datenschutzgerechte Versand der erstellten Dokumente zu organi-
sieren.
3.2 Berichtigung, Löschung und Sperrung
3.2.1 Rechtliche Anforderungen
Die verantwortliche Stelle hat gemäß §§ 20 bzw. 35 BDSG personenbezogene Daten von Be-
troffenen zu berichtigen, wenn sie unrichtig sind. Ggf. sind Daten zu löschen; zum Beispiel
dann, wenn ihre Speicherung unzulässig ist oder die ursprüngliche Zweckbindung weggefal-
len ist. In gewissen Fällen tritt an die Stelle einer Löschung die Sperrung der personenbezo-
genen Daten. Im Zusammenhang mit der Berichtigung, Löschung und Sperrung von Daten
sind im Vorwege gewisse Fragen zu klären:
a) Zum Inhalt der Berichtigung, Löschung oder Sperrung
Auf welche Daten / Tabellen bezieht sich der Berichtigungs-/Löschungs- bzw. Sper-
rungsanspruch?
Welches Verfahren ist bei Rücksicherungen/Sicherungskopien vorgesehen, wenn ge-
sperrte Daten betroffen sind?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 73
Sind die systemtechnischen Voraussetzungen für eine Löschung konform mit den
rechtlichen Anforderungen definiert (z.B. im SAP ERP HCM durch die geeignete De-
finition der Zeitbindung der Infotypen in der Tabelle T582A)?
b) Besonderheiten für spezielle Datenarten
Wie soll/kann mit Protokolldaten verfahren werden?
Welche Vorgehensweise ist bei Änderung/Löschung von Zugriffsberechtigungen und
anderen Benutzerstammdaten angebracht?
Wie wirksam sind Lösch- bzw. Sperrvermerke bei Daten mit Doppelbezug (z.B. Info-
typ 0021 Familie/Bezugsperson)?
3.2.2 SAP-Fakten
Es gibt keine speziellen SAP ERP-Funktionen - etwa Transaktionen oder Reports -, die die
Anforderungen der §§ 20 bzw. 35 BDSG gewährleisten.
Datenschutzkonformes Löschen
In SAP HCM gibt es verschiedene Möglichkeiten des datenschutzkonformen Löschens.
Löschen von nicht mehr benötigten Daten der Mitarbeiter für die Aufbewahrungsfristen
abgelaufen sind. Hierzu finden sich Details im Kapitel 6.1.1 Datenschutzkonformes Lö-
schen in der Personalwirtschaft (SAP HCM); Verfügbar für Releases ab ERP 6.0 Enhan-
cement Package 4
Löschen von Abwesenheiten für Release vor ERP 6.0 Enhancement Package 4. Details in
diesem Kapitel
Löschen aller Daten zu einem Mitarbeiter. Details in diesem Kapitel
Korrektur falscher Daten für einzelne Mitarbeiter. Details in diesem Kapitel
Löschen von Abwesenheiten
RPUDESTROY_ABSENCE löschen / vernichtet die Abwesenheiten von Personalnummern
bis zu einem festgelegten Stichtag. Der Report kann ausschließlich bei deutschen Personalfäl-
len die Abwesenheiten löschen. Sollen Personalfälle von der Löschung der Abwesenheiten
ausgenommen werden, erfolgt dies über eine spezielle Datumsart im Infotyp 41.
Löschen aller Daten zu einem Mitarbeiter
Vollständige Löschung eines Personalfalls, zur Sicherstellung eines Vier-Augen-Prinzip mit
den Rollen "Löschbeantrager" und "Löscher", durch folgende zwei Reports (SAP Hinweis
989664):
RPUDELPP Vorbereitung der Löschung
RPUDELPN Durchführung der vollständigen Löschen von Personalnummern
Es werden alle Infotypen einer Personalnummer gelöscht.
Es werden alle personalnummernabhängigen Cluster, die für diese Personalnummer ange-
legt worden sind, gelöscht.
- Tabelle Zuordnung von Werten zu Objekten (T52B5)
- Cluster TX aus der Tabelle RP-Cluster PCL1.
Es wird die Tabelle der Zeitereignisse (TEVEN) gelöscht.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 74
Es werden Daten über Aktivitäten mit Abrechnungsergebnissen/Buchungen (Überleitung
FI) gelöscht:
- Aktivitäten pro Abrechnungsergebnis (PCALAC)
- Index Abrechnungsergebniszeile -> Buchungszeile) (PPOIX)
- Index alte <-> neue Belegzeile für 'P'-Ergebnisse (PPOPX)
Es werden die zu den zu löschenden Personalnummern existierenden Einträge aus folgen-
den Tabellen gelöscht:
- Übernahme Lohnkonto alt (T558A)
- Übernahme Lohnkonto: Abrechnungsperioden (T558B)
- Übernahme Lohnkonto: Lohnarten alt (T558C)
- Übernahme Lohnarten mit Splitterkennzeichen (T558D)
Es werden Integrationsdaten (Organisationsmanagement) und Buchungen im Veranstal-
tungsmanagement gelöscht.
Gelöschte Daten sind endgültig gelöscht / vernichtet!
Korrektur falscher Daten für einzelne Mitarbeiter
Das SAP ERP-System bietet allerdings hinsichtlich der Berichtigung von Daten in den ver-
schiedenen Anwendungsmodulen die Möglichkeit, mit den Standard-Pflegetransaktionen un-
richtige Daten zu korrigieren, soweit diese noch im Onlinezugriff sind. Im Rahmen des SAP
ERP HCM bietet sich hierfür z.B. die Transaktion PA30 ‚Personalstamm pflegen’ an.
Es gibt keine Standardfunktion, die den Zugriff auf historische Daten mit personenbezogenen
Angaben, die nur noch aus Gründen der Aufbewahrungspflichten gespeichert werden, be-
schränkt - auch wenn alle buchhalterischen Abschlusstätigkeiten erledigt sind.
Auch die Löschung von Daten kann mit dieser Pflegetransaktion vorgenommen werden, wo-
bei darauf zu achten ist, dass eine tatsächliche Löschung erst mit der physischen Reorganisa-
tion der Datenbank erfolgt (eventuell ist der kritisierte Dateninhalt noch in Protokollen vor-
handen). Die unrichtigen Daten sind außerdem nach wie vor Bestandteil des Änderungsproto-
kolls für Infotypen, der mit dem Report RPUAUD00 angezeigt werden kann.
Sperren
Explizite Funktionen zur Sperrung von Daten einzelner Personen sind im SAP ERP-System
z.Z.. nicht vorhanden. So lassen sich etwa inkriminierte Daten eines Betroffenen im SAP ERP
HCM nicht auf einfache Weise sperren, weil u. a. das entsprechende Berechtigungsobjekt
P_ORGIN (Stammdaten) die Zulässigkeit des Zugriffs lediglich bis auf die Ebene des gesam-
ten Infotyps, nicht aber bezogen auf das einzelne Datenfeld prüft.
3.2.3 Anforderungen an die Organisation des Datenschutzes
Außer zu den unter Kapitel 3.2.1. genannten Fragen sind Grundsatzfragen des Archivierungs-
konzeptes wie auch eines Datenlöschungskonzeptes einzubeziehen und organisatorische Vor-
kehrungen ggf. in folgender Hinsicht zu treffen:
a) Organisation der Sperrung:
Da eine Sperrung einzelner Daten zur Person als technische Funktion im SAP ERP-
System explizit nicht vorgesehen ist, muss die verantwortliche Stelle ein adäquates orga-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 75
nisatorisches Verfahren entwickeln. Übergangsweise könnte die verantwortliche Stelle
statt einer Sperrung von Daten ihre datenschutzgerechte Dokumentation/ Archivierung in
Kombination mit einer vorübergehenden Löschung vornehmen.
b) Form der Löschung:
Wie erfolgt die Löschung aus dem aktuellen Datenbestand? (manuell?)
Wie erfolgt die Löschung aus dem archivierten Datenbestand? (manuell?)
c) Aufbewahrungsfristen (vgl. hierzu Abschnitt 2.3.5)
Wer ist für die Festlegung der Aufbewahrungsfristen zuständig?
(Wo) sind die Aufbewahrungsfristen und ihre Rahmenbedingungen im SAP ERP -
System dokumentiert?
Wie erfolgt die Löschung von Daten nach Ablauf formeller Aufbewahrungsfristen?
Diese Anforderungen an die Organisation des Datenschutzes lassen sich auch im GRC Pro-
cess Control (kostenpflichtige Komponente, vgl. Kap. 6) abbilden. Es besteht die Möglichkeit
Prozesse (wie z.B. zur fristgerechten Löschung von Daten, Reorganisation der DB) zu defi-
nieren/dokumentieren und diesen Prozessen manuelle Kontrollen zu zuordnen. Auf diese
Weise kann eine regelmäßige Überprüfung gewährleistet und dokumentiert werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 76
4 Umsetzung der Anforderungen aus § 9
BDSG und Anlage: Technisch-
organisatorische Maßnahmen
4.1 Anforderungen
In diesem Abschnitt werden die technisch-organisatorischen Anforderungen an die Verarbei-
tung personenbezogener Daten und deren Prüfungen behandelt. Die Anforderungen sind all-
gemein, d.h. insbesondere auch bei der Verarbeitung außerhalb des Geltungsbereichs nationa-
ler Gesetze, zu erfüllen.
Diese Vorschriften beziehen sich nicht alleine auf Produktivsysteme, sondern auch auf vorge-
lagerte Systeme, soweit dort personenbezogene Daten zugreifbar sind oder dort Einstellungen
vorbereitet werden, die später in die Produktionsumgebung transportiert werden.
Auf Grund der EU-Richtlinie 95/46/EG ist die Ausweitung der erforderlichen technisch-
organisatorischen Maßnahmen auf solche erfolgt, die einerseits Schutz gegen die zufällige
oder unrechtmäßige Zerstörung und den zufälligen Verlust der Daten bieten (Nr. 7: Verfüg-
barkeitskontrolle) und dass andererseits die zu unterschiedlichen Zwecken erhobenen Daten
getrennt verarbeitet werden können (Nr. 8).
4.1.1 Gesetzliche Anforderungen aus § 9 BDSG
Das Bundesdatenschutzgesetz und, in vergleichbarer Form, die Landesdatenschutzgesetze,
verlangen von der verantwortlichen Stelle zwingend, dass technisch-organisatorische Maß-
nahmen ergriffen werden, um sicherzustellen, dass die Anforderungen des Datenschutzes ge-
währleistet werden können. Insbesondere sind Maßnahmen zur Einhaltung der in der Anlage
zum BDSG aufgeführten acht Anforderungen zu treffen.
Für die dort aufgeführten Anforderungen sind im Rahmen des SAP-Einführungsprojektes
aufeinander abgestimmte, geeignete und erforderliche Maßnahmen auf der technischen und
der organisatorischen Ebene zu identifizieren und umzusetzen. Hierzu sind projektbezogen
Risikoanalysen vorzunehmen sowie Maßnahmen zu implementieren, die sowohl auf der or-
ganisatorischen als auch auf der technischen Ebene greifen. Die Maßnahmen sollen unzuläs-
sige und zweckwidrige Verarbeitung personenbezogener Daten verhindern und - soweit er-
forderlich/möglich – auch Missbrauch nachträglich feststellbar machen. Auf die einschlägigen
Projektschritte, an die insbesondere im Rahmen der Vorabkontrolle angeknüpft werden soll,
ist im Kapitel 1 hingewiesen worden.
Die aufeinander abgestimmte Form der technischen und organisatorischen Maßnahmen soll
verhindern, dass technische Maßnahmen wirkungslos bleiben, weil entsprechende organisato-
rische Maßnahmen fehlen. Beispielhaft für einen solchen Fall kann die fehlende organisatori-
sche Umsetzung der Möglichkeiten des SAP-Berechtigungskonzeptes sein, die trotz der viel-
fältigen Schutzmöglichkeiten keinen solchen bietet, etwa weil viele Anwender mit umfassen-
den Berechtigungen ausgestattet wurden. Ebenso wirkungslos können vielfach organisatori-
sche Maßnahmen sein, denen es an einer technischen Unterstützung fehlt. Ein Beispiel hierfür
ist der vergebliche Versuch der Sicherstellung einer Zweckbindung, wenn ein Abfluss der
personenbezogenen Daten aus SAP ERP mittels Download nicht technisch unterbunden wird.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 77
4.1.2 SAP-Funktionalität zur Abdeckung der gesetzlichen
Anforderungen
Die nachfolgende Abbildung listet in der linken Spalte die acht Anforderungen aus der Anla-
ge zu § 9 BDSG auf und stellt in der mittleren Spalte ausgewählte Ansatzpunkte zur Umset-
zung der Anforderungen im SAP ERP-System daneben. Es folgen in der rechten Spalte Hin-
weise auf weiterführende Literatur zu diesem Thema.
Ziele der gesetzlichen
Anforderungen
Ansatzpunkte auf Seiten des SAP
ERP-Systems Weiterführende Hinweise
Es ist – laut Anlage zu
§ 9 BDSG –
1) den Unbefugten der
Zutritt zu Daten-
verarbeitungsanla-
gen, mit denen per-
sonenbezogene Da-
ten verarbeitet oder
genutzt werden, zu
verwehren
(Zutrittskontrolle)
nicht einschlägig und deshalb keine Un-
terstützung seitens der SAP-Software
2) zu verhindern, dass
Datenverarbei-
tungssysteme von
Unbefugten genutzt
werden können
(Zugangskontrolle)
Personenbezogenes Anmeldever-
fahren (problematisch bei mehreren
Benutzern an einem Gerät; dann
müssen zusätzliche Hilfsmittel (wie
Chipkarten und PC-
Sicherheitssysteme sicherstellen,
dass die Anwender ohne Belastung
zwischen ihren Anmeldungen
wechseln können);
Die Verwaltung der Zugangskon-
trolle kann über ein SAP
NetWeaver Identity Management
erfolgen.
Die Verschlüsselung der
SAP_GUI<>Anwendungsserver-
Kommunikation über das DIAG-
Protokoll ist mit SNC möglich.
Damit ist dem unsicheren Transport
der Passwort-„Hash“s abgeholfen
(„Password-Sniffing“).
Die SAP NetWeaver
und SAP ERP Central
Component Sicherheits-
leitfäden
Prüfen Sie die VPN-
Zugriffe! Was ist bei
APPs und Notebooks
und BOYD und mit der
Nutzung außerhalb von
Räumen des Unterneh-
mens?
Auto-Logoff nach einer vorgegebe- SAP NetWeaver Si-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 78
Ziele der gesetzlichen
Anforderungen
Ansatzpunkte auf Seiten des SAP
ERP-Systems Weiterführende Hinweise
Es ist – laut Anlage zu
§ 9 BDSG –
nen Zeit; Bildschirmschoner mit
Kennwortschutz;
cherheitsleitfaden
Single Sign-On Ergänzung und An-
schlussmöglichkeiten für Chipkar-
ten
SAP NetWeaver Si-
cherheitsleitfaden
3) zu gewährleisten,
dass die zur Benut-
zung eines Daten-
verarbeitungssys-
tems Berechtigten
ausschließlich auf
die ihrer Zugriffs-
berechtigung unter-
liegenden Daten
zugreifen können,
und dass personen-
bezogene Daten bei
der Verarbeitung,
Nutzung und nach
der Speicherung
nicht unbefugt ge-
lesen, kopiert, ver-
ändert oder entfernt
werden können
(Zugriffskontrolle)
innerhalb des SAP NetWeaver mit
Hilfe eines angepassten Berechti-
gungskonzeptes für den ABAP-
Stack und den Java-Stack, welches
den Anforderungen von SAP, des
Revisionsleitfadens und des Daten-
schutzes gerecht wird;
Die Verwaltung der Zugriffskon-
trolle kann über ein SAP
NetWeaver Identity Management
erfolgen.
Die Verwaltung von externen Zu-
griffen kann mit dem Konzept Uni-
fied Connectivity (UCON) erfolgen.
SAP Dokumentation
SAP NetWeaver
(help.sap.com)
Lehnert / Stelzner /
John / Otto, SAP-
Berechtigungswesen,
Galileo Press Bonn
2013
Lehnert / Otto / Stelz-
ner, Datenschutz in
SAP-Systemen, Galileo
Press Bonn 2011
Linkies / Karin, „Si-
cherheit und Risikoma-
nagement für SAP-
Systeme“, Galileo Press
Bonn 2010
Esch / Junold / Klüßen-
dorf, Berechtigungen in
SAP ERP HCM, Gali-
leo-Press Bonn 2012
DSAG Prüfleitfaden FI
UCON SAP Help:
http://help.sap.com/saph
elp_nw74/helpdata/de/a
b/35e1c69f744d69a4fcf
4ca93284e0c/content.ht
m?frameset=/de/69/f70a
cfd3424c74809634c85b
3c02e5/frameset.htm
UCON SAP Help:
http://help.sap.com/saph
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 79
Ziele der gesetzlichen
Anforderungen
Ansatzpunkte auf Seiten des SAP
ERP-Systems Weiterführende Hinweise
Es ist – laut Anlage zu
§ 9 BDSG –
elp_nw74/helpdata/de/a
1/18cb4e3cd04ffdb57d2
d602e3da1b9/content.ht
m?frameset=/de/69/f70a
cfd3424c74809634c85b
3c02e5/frameset.htm
SAP Insider Artikel:
http://sapinsider.wispub
s.com/Assets/Articles/2
014/January/SPI_Colum
n_Secure-Your-System-
Communications-with-
Unified-Connectivity
RFC-BLOG:
http://scn.sap.com/com
muni-
ty/security/blog/2010/12
/05/how-to-get-rfc-call-
traces-to-build-
authorizations-for-srfc-
for-free
außerhalb des SAP NetWeaver:
Verschlüsselung im Netz, restrikti-
ve Vergabe von Berechtigungen auf
SAP-Dateien und Tabellen auf der
Ebene der Datenbank und des Be-
triebssystems;
Einsatz der SAP-RAL-Funktion
(Read_Access_Logging), siehe Ka-
pitel 6.2
SAP NetWeaver Si-
cherheitsleitfaden
SAP GRC Access Con-
trol: Analyse und Ad-
ministration von SAP-
Berechtigungskonzep-
ten (siehe Kapitel 6)
die Download-Funktion könnte per
Kundenerweiterung mit einer Be-
rechtigungsprüfung auf Transaktion
und Programm verfeinert und pro-
tokolliert werden
SAP-Hinweise 28777
und 210733
Angebot der Akqui-
net.de: SAST Download
Observer
4) zu gewährleisten,
dass personenbe- innerhalb des SAP ERP mit Hilfe
eines angepassten Berechtigungs-
SAP-
Systemdokumentation
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 80
Ziele der gesetzlichen
Anforderungen
Ansatzpunkte auf Seiten des SAP
ERP-Systems Weiterführende Hinweise
Es ist – laut Anlage zu
§ 9 BDSG –
zogene Daten bei
der elektronischen
Übertragung oder
während ihres
Transports oder ih-
rer Speicherung auf
Datenträger nicht
unbefugt gelesen,
kopiert, verändert
oder entfernt wer-
den können, und
dass überprüft und
festgestellt werden
kann, an welche
Stellen eine Über-
mittlung personen-
bezogener Daten
durch Einrichtun-
gen zur Datenüber-
tragung vorgesehen
ist
(Weitergabekon-
trolle)
konzeptes für ABAP und Java;
außerhalb des SAP Systems: Ver-
schlüsselung im Netz (LAN/WAN)
und auf sonstigen Datenträgern;
zur Downloadfunktion und zum
XXL/ALV-Listviewer siehe Ziffer
3.
Druckerkonzept
Kritisch: .pdf-Dokumente erzeugen
und ablegen bzw. mailen
Bei Internet-Anbindung:
Firewall-Konzept und SAP-Router;
SAP NetWeaver Si-
cherheitsleitfaden
Einstellungen der Berechtigungen; SAP NetWeaver Si-
cherheitsleitfaden
Zum geforderten Nachweis zur
Überprüfbarkeit gem. § 10 Abs.4
BDSG (Einrichtung automatischer
Abrufverfahren) können Hinweise
dem Read Access Log entnommen
werden (siehe Kapitel 6.2).
ggf. Stichproben über
Trace
5) zu gewährleisten,
dass nachträglich
überprüft und fest-
gestellt werden
kann, ob und von
wem personenbe-
zogene Daten in
Datenverarbei-
tungssysteme ein-
gegeben, verändert
oder entfernt wor-
den sind
(Eingabekontrolle)
durchgängig in allen Modulen, bei
allen SAP Objekten und bei allen
Daten mit automatischer Erfassung
von Erfasser/Änderer, Datum und
Uhrzeit realisiert;
SAP-
Systemdokumentation,
SAP-
Sicherheitsleitfäden
in den einzelnen Modulen stehen
neben den Anzeigetransaktionen
z.T. zusätzliche Reports für die An-
zeige von Änderungsbelegen zur
Verfügung;
Funktionen zur Anzeige
der Änderungsbelege in
den jeweiligen Fach-
funktionen
ggf. Konfiguration der zu schrei-
benden Änderungsbelege
Empfehlungen der SAP-
Sicherheitsleitfäden
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 81
Ziele der gesetzlichen
Anforderungen
Ansatzpunkte auf Seiten des SAP
ERP-Systems Weiterführende Hinweise
Es ist – laut Anlage zu
§ 9 BDSG –
6) zu gewährleisten,
dass personenbe-
zogene Daten, die
im Auftrag verar-
beitet werden, nur
entsprechend den
Weisungen des
Auftraggebers ver-
arbeitet werden
können
(Auftragskontrolle)
Im Standard ist keine besondere
Unterstützung vorgesehen.
vgl. Kapitel 5.2.2 und
5.2.6 dieses Leitfadens
Die Kontrolle der Auftragsdaten-
verarbeitung kann durch den Ein-
satz der SAP GRC Process Control
(zusätzliche Software) detailliert
geplant, dokumentiert und ausge-
wertet werden.
GRC Process Control
(siehe Kapitel 6.5)
7) zu gewährleisten,
dass personenbe-
zogene Daten ge-
gen zufällige Zer-
störung oder Ver-
lust geschützt sind
(Verfügbarkeits-
kontrolle)
regelmäßige Datensicherung auf der
Ebene der Datenbank;
Datensicherungskonzept;
an die Aufgaben angepasste Be-
rechtigungen;
Protokollierung der wichtigsten Da-
tenänderungen;
angemessene Schulung der Anwen-
der
SAP-
Systemdokumentation
siehe die allgemeinen
Empfehlungen der SAP-
Sicherheitsleitfäden
bzgl. Datensicherung
8) zu gewährleisten,
dass zu unter-
schiedlichen Zwe-
cken erhobene Da-
ten getrennt verar-
beitet werden kön-
nen
(Trennungsgebot).
Realisierung über Trennung: der
Systeme, der Mandanten und inner-
halb eines Mandanten durch ent-
sprechende Einrichtung des Berech-
tigungskonzeptes, insbesondere hin-
sichtlich der Anzeige und Auswer-
tung der Daten.
SAP-Broschüre zum Multi-Client-
Betrieb:
http://help.sap.com/bp_bniv2604/B
NI_DE/Documentation/Multi_Clien
t_System_Cookbook_EN.pdf
Die bereitgestellten InfoSets für
Query oder flexible Abgrenzungen
dürfen keine zu unterschiedlichen
Zwecken erhobenen Daten für die
Verarbeitung bzw. Nutzung bereit-
vgl. Prüfleitfäden des
DSAG AK Revision
und Dokumentation
Empfehlungen der SAP-
Sicherheitsleitfäden
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 82
Ziele der gesetzlichen
Anforderungen
Ansatzpunkte auf Seiten des SAP
ERP-Systems Weiterführende Hinweise
Es ist – laut Anlage zu
§ 9 BDSG –
stellen.
Innerhalb eines Mandanten ist si-
cherzustellen, dass Zugriffe auf die
personenbezogenen Daten außer-
halb des HR/HCM von den
HR/HCM Zugriffen so weit wie
möglich getrennt werden. Die
Kombination der Daten könnte zu
detaillierten personenbezogenen
Leistungs- und Verhaltensauswer-
tungen führen.
Insbesondere kostenrechnungsrele-
vante und produktionsbezogene Da-
ten sind besonders zu betrachten.
Bei Auswertungen von Konzernda-
ten in einem Mandanten mit Perso-
nenbezug (z.B. in einem Shared-
Service-Center) ist zu beachten,
dass eine unternehmensübergrei-
fende Auswertung nur durch eine
entsprechende Rechtsgrundlage le-
gitimiert werden kann.
Das BDSG weist im Anhang zum § 9 auf die Möglichkeit von Verschlüsselungsverfahren hin.
SAP bietet Funktionen zur Verschlüsselung von Transportwegen, näheres findet sich in den
Sicherheitsleitfäden.
4.2 SAP-Fakten, Risiken und Maßnahmen
Mit SAP ERP wird die klassische ABAP-Welt (ABAP Stack) um die JAVA-Welt (JAVA
Stack) ergänzt. Das bedeutet, dass neben die klassischen ABAP-Sicherheitsmaßnahmen nun
die JAVA Sicherheitsmassnahmen treten müssen. Dies trifft im besonderen Maße auch für die
§ 9 BDSG Maßnahmen, nämlich die Authentifizierung der Benutzer, die Autorisierung und
die Protokollierung zu. Die Aktivierung des JAVA-Stacks erfolgt mit dem Instanzparameter:
rdisp/j2ee_start = 1.
Zugriffe von der JAVA Präsentationsschicht können auf die ABAP Daten über die ABAP-
Berechtigungsprüfungen umgeleitet werden. Dies ist typischerweise bei Zugriffen auf die
ABAP-Daten über ein Portal der Fall. Folgender Fall soll die rechtliche Relevanz verdeutli-
chen: Im Portal können etwa über iViews auf dieser Ebene Verknüpfungen von zwei separa-
ten Datenbeständen (etwa denen von Personaldaten zweier Firmen) vorgenommen werden,
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 83
die jeder für sich rechtlich zulässig ist (etwa bei dem Zugriff eines Shared Service Centers).
Die Verknüpfung der Personal-Daten zweier Firmen wäre jedoch rechtlich anders zu beurtei-
len und nicht mehr durch ein reines Auftragsdatenverhältnis zweier Firmen an einen gemein-
samen Dienstleister gedeckt.
Auf der JAVA Ebene können jedoch auch eigene Datenbestände verwaltet werden, für die
auch auf JAVA Ebene adäquate Berechtigungsprüfungen im Sinne der Nummern 2-4 der An-
lage zu § 9 BDSG vorgesehen werden.
NWBC (NetWeaverBusinessClient) als Webclient auf der Basis von WebDynproABAP
(WDA).
Alternativ zum Enterprise-Portal (EP) in einem JAVA-Stack und als Ablösung der ITS-
Funktion (Internet Transaction Server) bietet SAP den NWBC an, der über das Internet kom-
muniziert und vom Anwender als HTML-Code im Browser ausgeführt wird. Eine sichere
Konfiguration der Internet-Verbindung ist erforderlich und zu überprüfen
Das nachfolgende Kapitel 4.2.1 befasst sich mit den ABAP spezifischen § 9 BDSG Maßnah-
men.
4.2.1 ABAP-Fakten, Risiken und Maßnahmen
4.2.1.1 Identifizierung und Authentifizierung
SAP-Fakten
Bevor ein SAP ERP-Benutzer auf die Informationen und Funktionen im ERP-System zugrei-
fen kann, muss er sich über das SAP-Logon mittels einer Benutzer-ID und einem Kennwort
anmelden. Durch die Eingabe dieser Daten identifiziert sich der Anwender gegenüber dem
SAP ERP-System und das System kontrolliert, ob der Benutzer berechtigt ist, mit dem Sys-
tem zu arbeiten. In Bezug auf das Kennwort gelten hierbei, sofern keine Änderungen in der
konkreten Installation vorgenommen worden sind, die in den Startparametern getroffenen
Einstellungen. Diese bei der Installation gesetzten Parameterwerte sind für ein Testsystem
vorgesehen und müssen für das Produktivsystem neu eingestellt werden. Für die Verwaltung
der Parameter stehen die Transaktionen RZ10 (Verwaltung von Instanzenprofilen) und RZ11
(Pflege von Profilparametern) oder TU02 (mit Historie) zur Verfügung.
Die für die Benutzeridentifizierung relevanten Parameter werden im Folgenden erläutert. Die
ebenfalls angegebenen Empfehlungen beziehen sich auf einen Grundschutz und Erfahrungs-
werte. Dabei ist zu beachten, dass die Parameter-Werte in Abhängigkeit von der Sicherheits-
politik in jedem Unternehmen durchaus unterschiedlich definiert werden können.
SAP hat die Funktionen mit SAP NW 7.40 erweitert und lässt nun für Benutzer unterschiedli-
che Einstellungen / Policys der Login-Parameter etc. zu, die in der SU01-Benutzerpflege im
Reiter LOGON_DATA im Feld Security_policy einzurichten sind. (siehe Dokument:
20130617_Identity_Security__SAP_NW 7.40_Whats NEW on Security 05.2013)
Mindestlänge des Kennwortes
Der Parameter login/min_password_lng bestimmt die Mindestanzahl der Stellen, die das
Kennwort besitzen muss. Ab SAP NetWeaver 6.40 ist der System-Defaultwert 8.
Zusammensetzung des Kennwortes
Die Parameter login/min_password_letters, login/min_password_digits, und lo-
gin/min_password_specials erlauben bis einschließlich SAP NetWeaver 6.40 eine Festle-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 84
gung der Mindestanzahl von alphabetischen Zeichen, Ziffern und Sonderzeichen im
Kennwort. Groß- und Kleinschreibung ist dabei unbedeutend. Nach SAP NetWeaver 6.40
können alle Unicode Zeichen verwendet werden und das System berücksichtigt dabei
auch Groß-/Kleinschreibung.
Empfohlene Parameter-Werte für die drei Parameter: jeweils “1” (Die Mindestanzahl von
Zeichen, Ziffern und Sonderzeichen beträgt 1 Stelle.) ACHTUNG: bei internationalen In-
stallationen ist wegen der unterschiedlichen Tastaturbelegungen ggf. auf die Anforderung
an ein Sonderzeichen zu verzichten.
Mindestanzahl kleiner und/oder großer Zeichen im Kennwort
Über die Parameter login/min_password_lowercase und login/min_password_uppercase
kann ab SAP NetWeaver 6.40 die Mindestanzahl der kleinen und/oder großen Zeichen im
Kennwort gesteuert werden.
Empfohlene Parameter-Werte für login/min_password_lowercase und lo-
gin/min_password_uppercase:“1“
Wartezeit für einen Kennwortwechsel
Bis einschließlich SAP NetWeaver 6.40 konnte ein Benutzer nur einmal am Tag sein
Kennwort wechseln. Danach kann mit dem Parameter login/password_change_waittime
die Wartezeit auf mehr Tage erhöht werden.
Empfohlene Parameter-Wert für login/password_change_waittime:“1“
Kennworthistorie
Bis SAP NetWeaver 6.40 prüft das SAP System, ob ein neues Kennwort mit den 5 ver-
gangenen Kennwörtern des Benutzers identisch ist. Ist dies der Fall weist das System das
neue Kennwort ab. Ab SAP NetWeaver 6.40 kann über den Parameter lo-
gin/password_history_size die Kennworthistorie auf eine Übereinstimmung mit den letz-
ten 100 Kennworten erweitert werden.
Empfohlene Parameter-Wert für login/password_history_size: “12“
Mindestunterschied zum vorherigen Kennwort
Ab Web AS 6.10 hat der Sicherheitsadministrator die Möglichkeit über den Parameter lo-
gin/min_password_diff festzulegen, wie viel Zeichen sich vom alten zum neuen Kennwort
unterscheiden müssen.
Empfohlene Parameter-Wert für login/min_password_diff: “4“
Kompatibilität eines Kennwortes zu einer geänderten Kennwortregel
Ab SAP NetWeaver 6.40 kann mit dem Parameter lo-
gin/password_compliance_to_current_policy festgelegt werden, dass ein in Gebrauch be-
findliches Kennwort auf die Verträglichkeit mit den geänderten Kennwortregeln überprüft
und ggf. eine Kennwortänderung erzwungen wird..
Empfohlene Einstellung: 1 (Aktivieren)
Verfallsdauer des Kennwortes
Der Parameter login/password_expiration_time bestimmt das Intervall für den Kenn-
wortwechsel bei Dialoganmeldung und ITS-Services, die die Flowlogic verwenden.
Empfohlener Parameter-Wert: “60” oder weniger (Nach maximal 60 Tagen muss der Be-
nutzer sein Kennwort ändern.)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 85
Verfallsdauer eines nicht gebrauchten Kennwortes
Ab SAP NetWeaver 6.40 kann mit dem Parameter login/password_max_idle_productive
die Verfallsdauer eines vom Benutzer vergebenen Kennworts in Tagen festgelegt werden.
Empfohlener Parameter-Wert für login/password_max_idle_productive : “30“
Verfallsdauer eines Initialkennwortes
Ab SAP NetWeaver 6.40 kann mit dem Parameter login/password_max_idle_initial die
Verfallsdauer eines vom Administrator vergebenen Initialkennwortes in Tagen festgelegt
werden.
Empfohlener Parameter-Wert login/password_max_idle_initial: “3“
Verbotene Kennwörter
Über die genannten Einstellungen hinaus können in der Tabelle USR40 Kennwörter defi-
niert werden, die von der Benutzung ausgeschlossen werden (zum Beispiel Ausschluss
von Trivialkennwörtern oder Tastaturkombinationen). Zu erwarten sind 15-40 Einträge
Weitere Anmeldevarianten
Je nach Releasestand gibt es neben der kennwortbasierten Anmeldung weitere Anmelde-
varianten, wie z.B.:
- Zertifikationsanmeldungen über den Browser und den Webserver
- SAP Anmeldeticket (z.B. bei Nutzung des SAP NetWeaver Portals)
- Single Sign On
Siehe dazu auch die Komponente SAP NetWeaver Identity Management, die als selbstän-
dige Anwendung die SAP-Landschaftsweite Verwaltung der Benutzer und ihrer Rollen
unterstützt.
Beenden der SAP-Sitzung
Der Parameter login/fails_to_session_end steuert, nach wie vielen Fehlversuchen der An-
meldung die SAP-Session beendet wird. Das automatische Beenden der Sitzung wird als
ein fehlgeschlagener Anmeldeversuch registriert.
Empfohlener Parameter-Wert: “3” (Nach 3 Fehlversuchen wird die Sitzung beendet.)
Mögliche Anmeldeversuche
Der Parameter login/fails_to_user_lock steuert, nach wie vielen Anmeldeversuchen der
Benutzer gesperrt wird.
Empfohlener Parameter-Wert: “5” (Nach 5 Anmeldeversuchen wird der Benutzer ge-
sperrt.)
Entsperrung um Mitternacht
Ist der Wert für den Parameter login/failed_user_auto_unlock auf “1” gesetzt, so werden
Benutzer, die aufgrund von Falschanmeldungen gesperrt wurden, um Mitternacht ent-
sperrt.
Empfohlener Parameter-Wert: “0” (Es erfolgt kein automatisches Entsperren um Mitter-
nacht.)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 86
Der Datenfluß zwischen SAP-GUI und Anwendungsserver ist mit SNC zu verschlüsseln,
das das Kennwort des Anwenders über das DIA-Protokoll nur ge“HASH“t übertragen
wird (SAP-Hinweis#: 1237762).
Automatisches Abmelden bei Inaktivität
Der Parameter rdisp/gui_auto_logout steuert, nach welcher Zeitspanne in Sekunden ein
automatisches Abmelden erfolgt. Bei der automatischen Abmeldung eines Benutzers ge-
hen nicht gespeicherte Daten verloren, so dass das Risiko des Datenverlustes bei einem
“harten” Abmelden besteht.
Empfohlener Parameter-Wert: “0” (Es erfolgt kein automatisches Abmelden durch das
SAP ERP-System. Anstatt der SAP-seitigen automatischen Abmeldung mit dem Risiko
des Datenverlustes sollte ein SAP-fremder Bildschirmschutz mit Kennwort normalerweise
nach 15 Minuten aktiviert werden.)
Wie der Vorgang der Anmeldung am System durch Parameter gesteuert wird, ist auch die Be-
rechtigungsprüfung bei der Arbeit mit dem SAP ERP-System von der Einstellung in Profilpa-
rametern abhängig. Die nachfolgend aufgeführten empfohlenen Einstellungen beziehen sich
wiederum auf einen Grundschutz. Folgende zentrale Parameter sind hier zu nennen:
Ausschalten von Berechtigungsprüfungen
Durch den Parameter auth/no_check_in_some_cases können Berechtigungsprüfungen un-
terdrückt werden. Die von SAP vorgeschlagene Anzahl von Berechtigungsprüfungen kann
mit Hilfe der Transaktion SU24 reduziert werden. Dies setzt voraus, dass der Parameter
mit “Y” für das Ausschalten von Berechtigungsprüfungen eingestellt ist. Bei Verwendung
des Profilgenerators wird der Wert „Y“ gefordert.
Empfohlener Parameter-Wert: “N” bzw. “Y“ bei Verwendung des Profilgenerators
(Berechtigungsprüfungen werden mit „N“ nicht ausgeschaltet. Bei der Einstellung „Y“
sollte zur Wahrung des Zugriffsschutzes regelmäßig überwacht werden, ob Berechti-
gungsprüfungen deaktiviert wurden. Hierzu kann die Tabelle USOBX_C und das Vorge-
hen gemäß Kapitel 0 verwendet werden.
Berechtigungsprüfung bei RFC
Durch den Parameter auth/rfc_authority_check wird festgelegt, ob Berechtigungsprüfun-
gen bzgl. Remote Function Call (RFC) gegen das Berechtigungsobjekt S_RFC erfolgen.
Empfohlener Parameter-Wert: “1” (Die Berechtigungsprüfung für RFC ist aktiv.)
Grundsätzlich soll die RFC-Berechtigung auf der Ebene der Funktionsbausteine erfolgen.
Siehe Report ZRFC_STATRECS_SECURITY im BLOG:
http://wiki.sdn.sap.com/wiki/display/Snippets/Show+RFC+Workload+Statistic+to+build+
authorizations+for+authorization+object+S_RFC
Berechtigungsprüfung zu ABAP-Sprachelementen
Durch den Parameter auth/system_access_check_off können automatische Berechtigungs-
prüfungen bei bestimmten ABAP-Sprachelementen ausgeschaltet werden. Diese Spra-
chelemente sind z.B. Dateioperationen, Aufruf von Kernelfunktionen oder CPIC-Aufrufe.
Empfohlener Parameter-Wert: “0” (Die Berechtigungsprüfung zu ABAP-
Sprachelementen ist aktiv.)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 87
Risiken und zu ergreifende Maßnahmen
Um dem Risiko der unzulässigen Zugriffe auf das SAP ERP-System zu begegnen und die
grundsätzlichen Schutzmechanismen der im SAP ERP-System zur Verfügung gestellten In-
strumente zum Berechtigungskonzept zu aktivieren, sind folgende Maßnahmen geeignet:
Definition der Soll-Werte für die Profilparameter und der “verbotenen” Kennwörter auf
der Basis eines unternehmensindividuellen Sicherheitskonzeptes
Anpassen der Werte zu den Profilparametern (Transaktionen RZ10, RZ11)
Pflege der Tabelle der “verbotenen” Kennwörter (Tabelle USR40)
Regelmäßige Überwachung der Parametereinstellungen (Report RSPARAM oder mit Hil-
fe des Audit Information Systems; Transaktion TU02 zur Anzeige der Änderungen)
Regelmäßige Überwachung der Tabelle der “verbotenen Kennwörter” (Transaktion SE17
(Data Browser) für die Tabelle USR40 oder mit Hilfe des Audit Information Systems )
Ergänzend oder alternativ sind - in Abhängigkeit von der gesamten IT-Architektur, in die ein
SAP ERP-System eingebunden ist – weitere und auch externe Sicherheitsprodukte empfeh-
lenswert. Solche sind z.B. SNC (Secure Network Communications - Authentication) oder bei
der Verwendung von Web-Frontends sogenannte X.509 Client Certificates. Für SNC steht auf
dem Service Marktplatz (http://www.service.sap.com/swdc -> Download -> SAP Cryptogra-
phic Software) die Cryptographic Library zum Download zur Verfügung, dabei ist auch der
SAP-Hinweis 397175 zu beachten..
4.2.1.2 Standardbenutzer
Es gibt im SAP ERP-System insgesamt vier Standardbenutzer, deren Funktion im Folgenden
vorgestellt werden. Im Rahmen der zu ergreifenden organisatorisch-technischen Maßnahmen
sind diese Standardbenutzer besonders zu schützen.
SAP*
Der Benutzer SAP* ist der von SAP fest codierte Initialuser und somit für die Installations-
phase mit allen Rechten ausgestattet. Nach erstmaliger Anmeldung (Initialkennwort vgl. SAP
NetWeaver Sicherheitsleitfaden) im SAP-System muss ein neuer Benutzer (eindeutige na-
mentliche Zuordnung) mit umfassenden Berechtigungen angelegt werden, der für die weite-
ren Administrationsaufgaben verantwortlich ist.
Auch wenn weiterführende Aktivitäten des Benutzers SAP* nicht erforderlich sind, darf
SAP* nicht gelöscht werden, da ansonsten, sofern keine weiteren technischen Maßnahmen
ergriffen werden, jeder andere Benutzer sich als SAP* mit dem Standardkennwort anmelden
kann. Bei dieser Anmeldung erhält SAP* dann auch wieder die mit diesem Benutzerstamm-
satz verbundenen besonderen Systemrechte.
Daher empfiehlt SAP, aus Sicherheitsgründen dem Benutzer SAP* alle Berechtigungen zu
entziehen bzw. die Berechtigungen auf reine Anzeigefunktionalitäten zurückzusetzen. Wei-
terhin sollte SAP* der Benutzergruppe "SUPER" zugeordnet werden, um zu verhindern, dass
dieser User leichtfertig gelöscht werden kann. SAP* kann nämlich physisch nicht gelöscht
werden. Wenn jemand z.B. über die SU01 SAP* löscht, erscheint dieser zwar nicht mehr in
der Benutzerliste, existiert aber trotzdem noch weiter im System. D.h. mit einer Anmeldung
als SAP* und dem bekannten Kennwort kann sich in diesem Fall jeder einen SAP_ALL-
Zugang verschaffen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 88
Werden die vorgenannten Maßnahmen nicht ergriffen, kann eine Neuanmeldung über folgen-
den Parameter unterbunden werden:
LOGIN/NO_AUTOMATIC_USER_SAPSTAR mit dem Wert „1“
(automatischer Benutzer SAP* ist deaktiviert)
Ab SAP NetWeaver 7.0 wurde der Defaultwert des Profilparameters auf 1 geändert, damit ist
der Benutzer SAP* automatisch deaktiviert.
SAPCPIC
Der Benutzer SAPCPIC ist ein eingerichteter Standarduser der SAP. Er kann nicht zur An-
meldung im Dialog verwendet werden, erlaubt aber den Aufruf einiger Programme und Funk-
tionsbausteine im SAP ERP-System. Er wird benötigt, um Performance-Daten zu sammeln,
externe Hintergrundprogramme zu starten und Werte für das Computer Center Management
System (CCMS) zurückzuliefern.
Als Schutzmaßnahme kann neben der Änderung des Standardkennworts auch die Sperrung
des Benutzers erwogen werden. Bei Durchführung dieser Maßnahmen sollte SAP-Hinweis
29276 beachtet werden.
Grundsätzlich sollten CPIC-Benutzer, auch wenn eine Anmeldung im Dialog nicht möglich
ist, über funktionsbezogenen Rollen/Profile verfügen.
DDIC
Neben SAP* ist der Benutzer DDIC durch SAP definiert. Der Benutzer DDIC wird für die
Pflege des ABAP-Dictionaries und der Softwarelogistik verwendet. Daher sind auch für die-
sen Benutzer weitreichende Systemrechte hinterlegt, die über die in Benutzerprofilen definier-
ten Rechte hinausgehen.
DDIC wird im Rahmen der Installation nur in den Mandanten 000 und 001 erstellt (Initial-
kennwort vgl. SAP NetWeaver Sicherheitsleitfaden). Für andere Mandanten muss der Benut-
zer DDIC, sofern erforderlich, angelegt werden.
Da es sich bei DDIC auch um einen Benutzer handelt, der Sonderrechte besitzt und bei dem
eine eindeutige personenbezogene Zuordnung i.d.R. erschwert ist, unterliegt seine Nutzung
auch besonderen Anforderungen hinsichtlich der Nachvollziehbarkeit der durchgeführten Ak-
tivitäten.
Auch für den Benutzer DDIC ist das Profil SAP_ALL aus Datenschutzsicht nicht zulässig. Es
wird nur in den Mandanten 000 und 001 benötigt und sollte nur bei Bedarf freigeschaltet wer-
den. Zur Ausübung der erforderlichen Aktivitäten (z.B. Starten und Stoppen von Tasks im
Rahmen des System-Monitorings) sollten funktionsbezogene Profile/Rollen erstellt werden.
Weiterhin sind organisatorische Festlegungen zu treffen, über die eine personenbezogene
Nutzung (Eindeutigkeit der Verantwortung) sichergestellt werden kann.
Um den Benutzer DDIC zu schützen, muss sein Standardkennwort geändert werden. Er muss
gesperrt werden, solange er nicht benutzt wird. Allerdings darf weder der Benutzer noch seine
Profile gelöscht werden. DDIC wird für bestimmte Aufgaben bei der Installation und bei Up-
grades, für die Softwarelogistik und das ABAP Dictionary benötigt. Das Löschen von DDIC
führt zu Funktionsverlusten in diesen Bereichen.
TMSADM
Für den automatisch angelegten System/Batch-Benutzer TMSADM für das Transportma-
nagement-System ist das Standardkennwort zu ändern:
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 89
Siehe:
http://help.sap.com/saphelp_nw73/helpdata/de/e7/c5066e05034f4a9cbcf9c84b513b7b/
frameset.htm und den Hinweis # 761637.
EarlyWatch
Der User EARLYWATCH ist der Dialogbenutzer für den Earlywatch-Service im Mandanten
066. Mit diesem Benutzer arbeiten die EarlyWatch-Experten der SAP; er wird für die Early-
Watch-Funktionen (Monitoring und Performance) benötigt.
Zum Schutz dieses Benutzers vor unberechtigtem Zugriff ist das Initialkennwort zu ändern.
Weiterhin sollten auch hier technische und organisatorische Maßnahmen ergriffen werden,
über die sichergestellt ist, dass ausschließlich Funktionen ausgeführt werden, die für die Nut-
zung dieses Benutzers vorgesehen sind.
Batch User / WF-BATCH
Batch User sind grundsätzlich als technische User einzurichten. Sie sind sämtlichen relevan-
ten Verfahren zuzuordnen. Zusätzlich sind diese jeweils auf die notwendigen Berechtigungen
einzuschränken.
Risiken und zu ergreifende Maßnahmen
Um grundsätzlich dem Risiko der unzulässigen Zugriffe auf das SAP ERP-System zu begeg-
nen, sind spezielle technische und organisatorische Maßnahmen zu ergreifen, über die sicher-
gestellt ist, dass eine unberechtigte Kenntnisnahme, bzw. versehentliche/absichtliche Manipu-
lation von Daten unterbunden wird. Dies gilt auch und vor allem in Bezug auf Sonderbenut-
zer.
Folgende Maßnahmen sollten ergriffen werden:
Erstellung funktionsbezogener Rollen/Profile für die o. g. Benutzer
Sperrung von Benutzern, die im Tagesgeschäft nicht benötigt werden, bzw. nicht aktiv
sind
Setzen der Systemparameter (vgl. z.B. Unterbindung der Anmeldung mit dem Benutzer
SAP*) zur Unterbindung unzulässiger Anmeldungen
Regelmäßige Überwachung der Aktivitäten der vorgenannten Benutzer, z.B: bezüglich
der Kennungen etc. mit dem Report RSUSR003.
Festlegung/Erstellung von Verfahrensanweisungen zur Handhabung der Sonderbenutzer
zur Unterstützung der technischen Maßnahmen
4.2.1.3 Benutzerberechtigungskonzept: ausgewählte
Berechtigungsobjekte
Im Folgenden werden wichtige Berechtigungsobjekte aus dem Modul HCM und der Basis
behandelt. Die komplette Dokumentation der Berechtigungsobjekte ist im Profilgenerator
(PFCG) durch Doppelklick auf das Berechtigungsobjekt, mit der Transaktion SU03 bzw. über
das Benutzerinformationssystem (Transaktion SUIM) zu erhalten.
Berechtigungsobjekte im HCM
Das Berechtigungsobjekt P_ORGIN (HR: Stammdaten) wird im Rahmen der Berechtigungs-
prüfung für Personaldaten (Stamm- und Zeitdaten) verwendet. Eine Prüfung findet grundsätz-
lich statt, wenn HR-Infotypen bearbeitet werden sollen. Wesentlich sind hierbei die organisa-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 90
torische Zuordnung des Mitarbeiterstammes, die Sicht auf Daten (Infotypen) und der Berech-
tigungslevel.
Das Berechtigungsobjekt besteht aus folgenden Feldern:
AUTHC Berechtigungslevel
INFTY Infotyp
SUBTY Subtyp
PERSA Personalbereich
PERSG Mitarbeitergruppe
PERSK Mitarbeiterkreis
VDSK1 Organisationsschlüssel
Weiterhin sind hinsichtlich des Berechtigungslevels (vgl. bzgl. weiteren Details die Doku-
mentation des Berechtigungsobjekts) u.a. folgende Werte von Bedeutung:
R Lesen
W Schreiben
M Lesen bei Eingabehilfen (Matchcode) (Empfehlung: Man sollte
nie nur W oder nur R vergeben; sonst erhalten die Anwender
keine Suchhilfe (früher Matchcodesuche) und müssen immer di-
rekt die Personalnummer eingeben.)
S gesperrt schreiben, entsperren, sofern der letzte Änderer des
Satzes nicht der aktuelle Benutzer ist.
E gesperrt schreiben
D ändern des Sperrkennzeichens
* alle Operationen
Neben dem Berechtigungsobjekt P_ORGIN gibt es noch 4 weitere Berechtigungsobjekte die
ggf. zusätzlich oder alternativ beim fachseitigen Zugriff auf Personalstammdaten geprüft
werden. Diese sind:
P_ORGINCON HR: Stammdaten mit Kontext prüfung auf ein strukturelles Be-
rechtigungsprofil
P_ORGXX HR: Stammdaten–erweiterte Prüfung
P_ORGXXCON HR: Stammdaten–erweiterte Prüfung mit Kontext prüfung auf
ein strukturelles Berechtigungsprofil
P_PERNR HR: Stammdaten-Personalnummernprüfung
Die Berechtigungsobjekte P_ORGINCON und P_ORGXXCON erlauben die zusätzliche Prü-
fung eines strukturellen Berechtigungsprofils aus der Tabelle T77PR. Damit ist die Differen-
zierung / Datentrennung bezogen auf den Anwender möglich.
Dagegen ist das Berechtigungsobjekt P_PERNR speziell zur Einschränkung des Zugriffs auf
eine Personalnummer (im Falle der ESS Szenarien) oder des Ausschlusses der Pflege einer
Personalnummer (um die Pflege der eigenen Daten zu untersagen).
Zusätzlich zu den oben genannten Berechtigungsobjekten für die HCM Stammdaten ist für
die Stammdatenpflege eine Berechtigung für die jeweilige Transaktion, z.B. PA30 (Personal-
stamm pflegen), erforderlich.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 91
Außerdem ist zu berücksichtigen, dass ggf. weitere Berechtigungsobjekte (bspw. HR:Bewer-
ber oder FI:Reiseplanung) zu Prüfzwecken herangezogen werden sollten (für weitere Details
siehe Dokumentation der SAP-Berechtigungsobjekte).
Berechtigungsobjekt P_ABAP
Für den Schutz des Zugriffs auf Reports ist im SAP ein Berechtigungsobjekt vorgesehen, das
Objekt S_PROGRAM (ABAP: Programmablaufprüfungen, Objektklasse BC_C).
Über das Objekt S_PROGRAM wird grundsätzlich gesteuert, ob und auf welche Reports mit
den Transaktionen SA38, SE38 und START_REPORT zugegriffen werden kann, sofern der
Benutzer eine Zugriffsberechtigung zu der Berechtigungsgruppe des Reports (siehe Details
unter Kapitel 4.2.1.5.4) besitzt.
Im HCM steuert zusätzlich das Berechtigungsobjekt P_ABAP (HR: Reporting) die Berechti-
gungsprüfungen während der Reportausführung. Für die Ausführung der Reports sind keine
Berechtigungen für das Objekt erforderlich, stattdessen soll es die die Performance bei der
Ausführung verbessern, bzw. Berechtigungen für die Ausführung bestimmter Reports ertei-
len, die über die vorhandenen Berechtigungen nicht möglich wären. Der zweite Fall kommt
häufiger vor, z.B. bei den Reports der Reisekostenabrechnung, oder der Zahlungsträgerpro-
gramme des Rechnungswesens.
Über das Objekt P_ABAP wird gesteuert, auf welche Weise die Objekte:
HR: Stammdaten (P_ORGIN/P_ORGINCON)
HR: Stammdaten - erweiterte Prüfung – (P_ORGXX/P_ORGXXCON)
strukturelle Berechtigungsprüfung in spezifischen Reports
zur Prüfung der Berechtigungen für HCM-Infotypen verwendet bzw. reduziert werden. Durch
eine entsprechende Aussteuerung der Felder:
REPID (Reportname) < auch generisch >
COARS (Vereinfachungsgrad der Berechtigungsprüfung)
1 = Zusätzliche Berechtigungen werden ebenfalls berücksichtigt
2 = während der Reportausführung findet keine Berechtigungsprüfung statt.
können Berechtigungsprüfungen übersteuert werden. Eine genaue Erläuterung zur richtigen
Ausprägung des Berechtigungsobjekts P_ABAP finden Sie in SAP-Hinweis 138526.
Hintergrund für die Erstellung dieses Berechtigungsobjektes durch die SAP ist eine erhöhte
Verarbeitungsgeschwindigkeit durch die “Ausschaltung” von weiteren Berechtigungsprüfun-
gen.
Das Berechtigungskonzept sollte eine Sondergenehmigung für die Nutzung der P_ABAP-
Berechtigungsprüfung vorsehen.
Grundsätzlich ist somit die Ausprägung dieses Berechtigungsobjektes kritisch zu hinterfragen,
um sicherzustellen, dass keine unberechtigte Kenntnisnahme personenbezogener Daten über
das Reporting erfolgen kann. Immer wieder wird auch das Programm SAPDBPNP: Logische
Datenbank PNP im P_ABAP in das Feld REPID eingetragen. Dies hat zur Folge, dass im Re-
porting keine HCM-Berechtigungsprüfung mehr stattfindet.
Berechtigungsobjekt P_TCODE
Das Berechtigungsobjekt P_TCODE stellt ein anwendungsspezifisches Berechtigungsobjekt
dar, das ein Vorläufer des Berechtigungsobjektes S_TCODE war. Über die Ausprägung des
Berechtigungsobjektes P_TCODE (HR: Transaktionscode) kann der Zugriff auf verschiedene
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 92
HCM-Transaktionen geschützt werden. Dabei ist zu beachten, dass dieses Objekt nicht bei je-
der HCM-Transaktion genutzt wird, so dass zusätzlich das Objekt S_TCODE verwendet wer-
den muss.
Als Anhaltspunkt, welche Transaktionen über die Ausprägung des Objektes P_TCODE ge-
schützt werden, können die Tabellen USOBT und USOBX verwendet werden. Sie werden mit
der Transaktion SE17 und der Angabe „P_TCODE“ für das Objekt ausgewertet.
Berechtigungsobjekt S_TCODE
Über das Berechtigungsobjekt S_TCODE wird beim Aufruf von Transaktionen geprüft, ob
der Benutzer zur Ausführung der angewählten Funktion berechtigt ist. Zu diesem Berechti-
gungsobjekt ist das Feld Transaktionscode (TCD) definiert.
Durch eine funktionsbezogene Ausprägung dieses Berechtigungsobjektes ist es somit auf ei-
ner ersten Stufe möglich, Zugriffschutzmaßnahmen abzubilden. Sofern eine differenzierte
Ausprägung dieses Objektes nicht vorgenommen wird, werden im weiteren Verlauf von Be-
rechtigungsprüfungen die modul-, bzw. funktionsspezifischen Objekte herangezogen.
Eine entsprechende Ausprägung aller miteinander korrespondierenden Objekte ist demzufolge
erforderlich, um sicherzustellen, dass die Anforderungen des BDSG hinreichend abgedeckt
sind.
Mithilfe der Transaktionen SE38, SA38 und START_REPORT ist es möglich die meisten im
Standard verfügbaren Reports auszuführen ohne das eine Prüfung auf eine entsprechende Be-
rechtigung erfolgt. Dies kann über die in Abschnitt 4.2.1.5.4 beschrieben Schutzmaßnahmen
verhindert werden.
Die Transaktion sub% sollte nicht an Benutzer vergeben werden. Mit dieser Transaktion las-
sen sich beliebige Transaktionen durch den Benutzer starten. Dabei wird nicht überprüft, ob
der Benutzer über die Berechtigungen zum Starten der entsprechenden Transaktionen verfügt
(siehe SAP-Hinweis 842915). Mit der sub% lassen sich auch Reports ausführen, allerdings
findet hier die Prüfung auf die Berechtigungsgruppe statt.
Tabelle TSTCA Transaktion SE93
In der Tabelle TSTCA sind sämtliche Transaktionen mit zusätzlichen Prüfobjekten hinterlegt.
Die Tabelle kann mit Hilfe der Transaktion SE17 ausgewertet werden.
Die Pflege der Tabelle unterliegt, da hier mandantenunabhängige Eintragungen gepflegt wer-
den, den Mechanismen des CTS/CTO (Change Transport System/Change Transport Organi-
zer).
In der Tabelle wird die „Eingangsprüfung hinterlegt“. Dabei wird kontextfrei geprüft ob das
Objekt mit den ausgeprägten Werten im Benutzerpuffer vorhanden ist. Eine sachverhaltliche
Prüfung (Aktivität in Bezug auf ein Merkmal) findet im Programmlauf statt. In der Tabelle
USOBT kann die Prüfung für Objekte ausgeschaltet werden, dies gilt aber nicht für HCM und
Basisobjekte.
Zu beachten ist, dass Zugriffsberechtigungsprüfungen umgangen werden können, indem der
Authority-Check (Berechtigungsprüfung) in den der Transaktion zugrunde liegenden ABAP-
Programmen ausgeschaltet wird.
Umwandlung von Reports in Transaktionen
SAP bietet die Möglichkeit, auf zwei verschiedene Arten Reports Transaktionen zuzuordnen.
Die erste wird automatisch durchgeführt, wenn der Report in ein Bereichsmenü oder in das
Menü einer Rolle eingegliedert wird. Allerdings besteht zwischen dem Report und dem
Transaktionsnamen keine sprechende Verbindung, da SAP die Transaktionen laufend durch-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 93
nummeriert (Aufbau S_XXX_xxxxxxxx). Daher bietet sich die zweite Art an: Reports werden
dabei bei einer eigenerstellten Transaktion hinterlegt und durch den Aufruf dieser Transaktion
gestartet. Bei beiden Methoden ist zu beachten, dass der Benutzer die Reports auch weiterhin
über das “normale” Reporting starten kann, wenn er Rechte für die Transaktionen wie SA38
oder SE38 besitzt. Das Starten ist auch indirekt aus SE80 und SE84 und verschiedenen
weiteren Transaktionen möglich.
Aus datenschutzrechtlicher Sicht ist in diesem Zusammenhang
a) eine Konzeption zum Schutz der einzelnen Reports zu erarbeiten (Berechtigungskonzept
S_Program, Verwaltungsreport RSCSAUTH) und
b) zu hinterfragen, ob und in wie weit über die dargestellten Möglichkeiten ggf. Berechti-
gungsprüfungen unterlaufen werden können.
Berechtigungen für die Transaktionen SA38 (ABAP Programmausführung), SE38 (ABAP
Editor) und START_REPORT sollten an die Benutzer der Fachabteilungen nicht vergeben
werden. Stattdessen empfiehlt es sich, für die freigegebenen Reports Transaktionscodes zu
generieren. Den einzelnen Benutzern ist der Zugriff auf diese Transaktionscodes über das Be-
nutzermenü zu ermöglichen (Berechtigungsobjekt S_TCODE).
Berechtigungsobjekt S_TABU_DIS, S_TABU_NAM S_TABU_CLI und S_TABU_LIN
Über das Berechtigungsobjekt S_TABU_DIS ist der Zugriff auf die Tabellenpflege – mit
Transaktionen wie z.B. SE16, SE16N, SE17, SM30 bis SM34 - und über das Berechtigungs-
objekt S_TABU_CLI ist der Zugriff auf die mandantenübergreifende Tabellenpflege gesteu-
ert. Zusätzlich zu einer entsprechenden Ausprägung dieser genannten Objekte sind Transakti-
onsberechtigungen zur Tabellenpflege (vgl. S_TCODE) erforderlich.
Das Berechtigungsobjekt S_TABU_DIS besteht aus den Feldern Aktivität und Berechti-
gungsgruppe. Über die Ausprägung des Feldes Aktivität kann die Art des Zugriffs auf Tabel-
len (anzeigen oder ändern) gesteuert werden. Das Feld Berechtigungsgruppe dient zur Ein-
schränkung des Zugriffs auf bestimmte Tabellen.
Das Berechtigungsobjekt S_TABU_NAM mit dem Feld: TABLE: Tabellenname bezieht
sicht immer auf eine einzelne Tabelle und ersetzt für spezifische Tabellen das Berechtigungs-
objekt S_TABU_DIS, wenn die Tabellenberechtigungsgruppen eine zu weite und nicht ge-
wollte Zugriffsberechtigungen ermöglichen. Das Objekt wird nur dann geprüft, wenn die Berechti-
gungsprüfung auf das Objekt S_TABU_DIS fehlgeschlagen ist.
Das Berechtigungsobjekt S_TABU_CLI besteht aus dem Feld Kennzeichen für mandanten-
unabhängige Pflege.
Das Berechtigungsobjekt S_TABU_LIN definiert Berechtigungen für die Anzeige oder Pfle-
ge von Tabelleninhalten. Das Objekt ergänzt die Berechtigungsobjekte S_TABU_DIS und
S_TABU_CLI:
Während S_TABU_DIS auf der Ebene von Customizing-Tabellen oder Pflegeviews wirkt,
kann man mit S_TABU_LIN den Zugriff auf einzelne Tabellenzeilen regeln. Voraussetzung
für die Verwendung des Berechtigungsobjekts ist die Existenz von Organisationskriterien.
Organisationskriterien stehen für betriebswirtschaftliche organisatorische Einheiten (z.B. ein
Land oder ein Werk) und stellen eine Verbindung zwischen Tabellen-Schlüsselfeldern und
den Berechtigungsfeldern von S_TABU_LIN her. Sie werden innerhalb des Customizings
(IMG-Pfad Basis -> Systemadministration -> Benutzer und Berechtigungen -> Zeilenbezoge-
ne Berechtigungen -> Organisationskriterien definieren) definiert.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 94
Eine Berechtigung auf Zeilenebene wirkt nur dann, wenn das zugehörige Organisationskrite-
rium im betreffenden Mandanten eingeschaltet ist (Basis -> Systemadministration -> Benutzer
und Berechtigungen -> Zeilenbezogene Berechtigungen -> Organisationskriterienaktivieren).
An dieser Stelle wird empfohlen die Transaktionen SE16/SE16N/SE17 nur sehr eingeschränkt
an Benutzer zu vergeben. Die fachliche Zugriffsbegrenzung und die Datentrennung ist nicht
mehr gewährleistet. Wir empfehlen dem Datenschutzbeauftragten jede Verwendung kritisch
zu hinterfragen.
Falls eine Vergabe erfolgt, ist aus datenschutzrechtlicher Sicht darauf zu achten, dass zur
Vermeidung eines unzulässigen Zugriffs auf personenbezogene Daten mittels der Tabellenan-
zeige SE16/SE17 auf eine restriktive Vergabe des Zugriffs auf Berechtigungsgruppen sol-
cher Tabellen (z.B. den Infotypen in den PA-Tabellen) geachtet wird.
Eine Zuordnung von Tabellen zu Berechtigungsgruppen kann über die Transaktion SE17 und
Angabe der Tabelle TDDAT oder die Transaktion SE53: Generieren Tabellenpflegedialog
abgerufen werden.
Berechtigungsobjekt S_TOOLS_EX
Über das Berechtigungsobjekt S_TOOLS_EX (Objektklasse BC_A) können Berechtigungen
vergeben werden, die zur Anzeige fremder Statistikaufzeichnungen bei der Nutzung von Mo-
nitoring-Tools dienen.
Dabei enthält dieses Objekt ein Feld (AUTH), über das Berechtigungsnamen vergeben wer-
den können. Durch den Eintrag S_TOOLS_EX_A wird der Zugriff auf fremde Statistiken
möglich.
Um zu verhindern, dass hier eine Leistungs- und Verhaltenskontrolle ermöglicht wird, sollte
dieser Zugriff nur äußerst restriktiv vergeben werden. Auswertungen über Benutzerverhalten
sind nur in begründeten und abgestimmten Ausnahmefällen zulässig.
Die Mitbestimmungsrechte der Arbeitnehmervertretung sind bei der Vergabe dieser Berechti-
gung besonders zu beachten.
Berechtigungsobjekt S_SCD0
Das Berechtigungsobjekt S_SCD0 (Änderungsbelege, Objektklasse BC_Z) ermöglicht den
Zugriff auf Änderungsbelege und Änderungsbelegobjekte. Änderungsbelege werden z.B. bei
Stammdaten- und Benutzerstammsatzänderungen erzeugt.
Änderungsbelege (Stammdaten) gehören zu den nach § 257 HGB aufbewahrungspflichtigen
Unterlagen (Dauerbelege). Im SAP besteht die Möglichkeit über die entsprechende Ausprä-
gung des Berechtigungsobjektes S_SCD0 (vgl. Benutzerberechtigungskonzept), Änderungs-
belege und -objekte zu pflegen (= verändern) bzw. zu löschen und somit direkten Einfluss auf
die Protokollierung zu nehmen.
Die Mitbestimmungsrechte der Arbeitnehmervertretung sind bei der Vergabe der Berechti-
gung zum Anzeigen der Änderungsbelege besonders zu beachten.
Objekte zur Benutzer- und Berechtigungspflege (S_USER_xxx)
Die Berechtigungsobjekte zur Benutzer- und Berechtigungspflege (vgl. im Einzelnen unter
Kapitel 4.2.1.6.1) erlauben eine differenzierte Gestaltung des Prozesses der Benutzereinrich-
tung, -pflege usw. sowie der Vergabe der gewünschten Berechtigungen an die Benutzer.
Unter datenschutzrechtlichen Gesichtspunkten ist besonders darauf zu achten, dass deren
Ausprägungen sorgfältig vorgenommen werden und ausschließlich diejenigen Personen Zu-
griff bekommen, die hierzu autorisiert werden sollen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 95
Berechtigungsobjekt S_GUI und XXL-Listviewer
SAP bietet die Möglichkeit, die unterschiedlichsten Auswertungen per Download oder den
XXL-Listviewer aus der ”gesicherten SAP-Umgebung” auf den PC zu übertragen und dort
ohne zusätzliche Kontrollen weiterzuverarbeiten. Grundsätzlich sind alle Daten, die aufgrund
der an den Benutzer vergebenen Berechtigungen am Bildschirm angezeigt werden, auch auf
den PC übertragbar. Die Funktionen des XXL-Listviewers können derzeit nur eingeschränkt
über das Berechtigungsobjekt S_OLE_CALL geschützt werden
Zum Schutz der Downloadfunktionalität sieht SAP das Berechtigungsobjekt S_GUI vor. Zu
diesem Objekt ist derzeit das Feld “Aktivität” definiert. Der Wert “61” berechtigt dazu, alle
Listen, die man am Bildschirm anzeigen kann, als lokale Datei zu sichern. Es lassen sich über
einen User-Exit (EXIT_SAPLGRAP_001 mit dem Include ZXFILU01)weitere Berechti-
gungsprüfungen (z.B. auf gestartete Reports oder Transaktionen) hinzufügen.
Siehe auch SAP-Hinweise 28777, 210733 und 510399.
Berechtigungsobjekt S_SPO_DEV
Über das Berechtigungsobjekt S_SPO_DEV können die Berechtigungen zum Drucken auf
namentlich vorgegebenen Druckern vergeben werden. Durch eine generische Vergabe von
Druckernamen kann auf diese Art und Weise z.B. festgelegt werden, dass ein Benutzer des
HCM-Moduls ausschließlich auf Druckern der Personalabteilung drucken kann. Risiken birgt
das Drucken auf Druckern, die nicht in Sichtweite stehen, bzw. für die kein SECURE-PRINT-
Verfahren zum Einsatz kommt.
Berechtigungsobjekt S_ADMI_FCD
Mit der Berechtigung S_ADMI_FCD kann die Mandantengrenze überschritten werden; d.h.
Spool- und TemSe-Druck- und Datenobjekte können in anderen Mandanten verwaltet und
administriert werden, wenn die Systemadministrationsfunktion: SPAD: Berechtigung zur
mandantenübergreifenden Spooladministration bzw. SPTD: Berechtigung zur mandanten-
übergreifenden TemSe-Administration in der Berechtigung enthalten sind.
Risiken und zu ergreifende Maßnahmen
Um dem Risiko eines unberechtigten Zugriffs auf personenbezogen Datenbestände vorzubeu-
gen, ist es erforderlich, über die Ausprägung der vorgenannten Berechtigungsobjekte sicher-
zustellen, dass lediglich die Daten gelesen, bzw. gepflegt werden können, die im Aufgaben-
gebiet des entsprechenden Arbeitsplatzes liegen.
Beim Einsatz von HCM ist somit über eine entsprechende Ausprägung des Benutzerberechti-
gungskonzeptes sicherzustellen, dass der Zugriff auf die o.g. Objekte sowie alle anderen Ob-
jekte der Klasse Personalwesen restriktiv und unter Funktionstrennungsgesichtspunkten er-
folgt. Weiterhin sollte der Zugriff auf alle Infotypen äußerst restriktiv gehandhabt werden.
Somit ist insbesondere sicherzustellen, dass:
technische und organisatorische Maßnahmen geschaffen werden, die den ändernden und
löschenden Zugriff auf Änderungsbelege verwehren. Hier sind v.a. auch unerwünschte
Zugriffsmöglichkeiten über Reports, z.B. RSCDOK99: Löschen von Änderungsbelegen
zu verhindern
der Download von Daten nur in zulässiger Weise erfolgt, d.h. es muss sichergestellt sein,
dass eine hinreichende Ausprägung des Berechtigungskonzeptes lediglich einen funkti-
onsbezogenen Zugriff auf Daten ermöglicht
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 96
Zweckentfremdung der Daten über Download und/oder XXL-/ ALV-Listviewer und an-
schließende Verarbeitung zu datenschutzrechtlich nicht zulässigen Zwecken sowie unter
unzulässigen Bedingungen (wie etwa mangelnder Prüfbarkeit) ausgeschlossen wird.
der Ausdruck in .pdf-Dokumente mit einer Ablage im Verzeichnis-Baum und einem
Mailversand nicht möglich ist.
Tabellenanzeige- und -pflegeberechtigungen über die Ausprägung des Feldes Berechti-
gungsgruppe hinreichend eingeschränkt werden
der Zugriff bzgl. Änderungsmöglichkeiten zu Transaktionen und Programmen äußerst
restriktiv gehandhabt, bzw. durch organisatorische Regeln unterbunden wird (inkl. Erstel-
lung einer Organisationsanweisung bzgl. der Verfahrensdokumentation bei durchzufüh-
renden Pflegemaßnahmen)
das Löschen von Änderungsbelegen grundsätzlich im Produktivsystem (Ausnahme Not-
falluser) unterbunden wird, bzw. nur durch die vorgesehenen Archivierungs- bzw. Reor-
ganisationsprogramme durchgeführt wird
eine restriktive Ausprägung des Feldes Berechtigungslevel im Hinblick auf den Zugriff
auf HCM Infotypen erfolgt
die Ausprägungen der Berechtigungsobjekte P_TCODE und S_TCODE sinnvoll aufei-
nander abgestimmt sind
Sollte aufgrund der vorhandenen Personalstärke eine differenzierte, an Funktionstrennungsge-
sichtspunkten orientierte Ausprägung verschiedener der vorgenannten Berechtigungsobjekte
nicht realisierbar sein, empfiehlt es sich, über Organisationsanweisungen die Nutzung von
nachgelagerten Kontrollen festzulegen. Deren Einhaltung gilt es in regelmäßigen Abständen
von einer neutralen Stelle zu kontrollieren.
4.2.1.4 Benutzerberechtigungskonzept: ausgewählte Profile
Um die notwendigen Aufgaben in Bezug auf die Systemadministration durchführen zu kön-
nen, sind sog. Systemadministratoren einzurichten. Diese verfügen dabei naturgemäß über
weitreichende Berechtigungen. SAP sieht hierzu im Standard i.d.R. zur Nutzung im Testsys-
tem die nachfolgenden Auslieferungsprofile vor, die jedoch unbedingt den Anforderungen im
Unternehmen entsprechend angepasst werden müssen.
In Notfällen, bzw. bei Put- oder Releasewechseln, muss ggf. temporär eine Vergabe von um-
fassenden Berechtigungen (Profilen oder Rollen) erfolgen. Dabei ist zu beachten, dass die
Vergabe dieser Berechtigungen durch eine andere Person erfolgt (4-Augen-Prinzip) und eine
Deaktivierung dieser Nutzer bzw. Berechtigungen außerhalb der erforderlichen Nutzungszeit
gewährleistet ist.
Notfallzugriffe mit kritischen Usern stellen ein zentrales Problem der Administration dar. Die
Überwachung sollte neben dem Vier-Augen-Prinzip und dem Einschalten des Security Audit
Logs auch ein einschlägiges Genehmigungsverfahren und eine detaillierte nachfolgende
Auswertung umfassen. Die GRC Access Control (kostenpflichtige Komponente s. Kapitel 6)
stellt eine entsprechende Super User Management Lösung bereit.
Profil SAP_ALL
Mit diesem Profil sind nahezu uneingeschränkte Zugriffe auf das gesamte System (inkl. An-
wendungen) möglich. Dies beinhaltet v.a. auch den Zugriff auf die Werkzeuge der Anwen-
dungsentwicklung. Somit kann bei der Nutzung verschiedener in diesem Profil enthaltenen
Berechtigungen die BDSG-konforme Datenspeicherung und -verarbeitung genauso gefährdet
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 97
werden wie die Ordnungsmäßigkeit der Buchführung. Des öfteren werden die SAP_ALL-
Berechtigungen unter anderem Namen versteckt. Hilfreich ist hier der Check des SOSS-
Reports auf Benutzer mit besonders vielen Berechtigungen. Check 0027 zeigt Benutzer mit
„*“ (Wildcards) in den Berechtigungswerten; Check 0028 zeigt die Benutzer mit den meisten
Rollen und Check 0029 zeigt die Benutzer mit den meisten Profilen.
Das Profil kann bei Bedarf vom Kunden neu erzeugt werden.
Profil SAP_NEW
Über das Profil SAP_NEW werden Berechtigungen für neue Berechtigungsobjekte zu bereits
vorhandenen Funktionen zur Verfügung gestellt. Dabei sind die einzelnen Felder der im Profil
SAP_NEW enthaltenen Objekte i.d.R. mit umfassenden Werten (*) ausgeprägt. SAP_NEW
wird dabei jeweils Release bezogen mit ausgeliefert.
Da die Ausprägung der in SAP_NEW enthaltenen Objekte ggf. in Verbindung mit dem im
Unternehmen implementierten Berechtigungskonzept zu unerwünschten Erweiterungen der
Berechtigungen führt, sollte dieses Profil in einem produktiven SAP-System keinem Anwen-
der zugeordnet werden.
Profil P_BAS_ALL
Auch für den Bereich HCM werden seitens SAP Standardprofile für ein Testsystem ausgelie-
fert. Über das Profil P_BAS_ALL (Alle Berechtigungen für Personendaten) ist ein umfassen-
der Zugriff auf personenbezogene Daten möglich. Darüber hinaus können auch über die
Funktionalitäten der allgemeinen Tabellenanzeige Inhalte aus anderen Anwendungen ange-
zeigt werden. Dieses Profil sollte in Produktivsystemen nicht verwendet werden.
Sonstige S_xxx-Profile
Nachfolgend genannte Profile stellen auch lediglich Muster dar. Grundsätzlich ist es erforder-
lich, die in diesen Profilen vorliegende Ausprägung der einzelnen Berechtigungsobjekte funk-
tionsbezogen einzuschränken.
S_A.SYSTEM Dieses Profil ist für den zentralen Systemverwalter vorgesehen.
Hierüber werden alle Basis-Berechtigungen vergeben (ohne
Module). In diesem Profil sind auch die Berechtigungen zur Be-
nutzeradministration enthalten.
S_A.ADMIN Dieses für den Systemoperator vorgesehene Profil beinhaltet die
Berechtigungen zur Anwendungsentwicklung, zur Administrati-
on der Benutzergruppe SUPER und zur Pflege der Profile der
Gruppe S:A.
S_A.CUSTOMIZ Dieses Profil beinhaltet die Berechtigungen Customizing-
Einstellungen durchzuführen.
S_A.DEVELOP Dieses Profil ist für Anwendungsentwickler vorgesehen und mit
entsprechenden Programmierberechtigungen versehen.
Rollen mit kritischen Berechtigungen
Rollen können über das Benutzerinformationssystem (Transaktion SUIM29) nach verschiede-
nen Kriterien analysiert werden, z.B:
29 Abhängig von der Pflegequalität der Rollen kann die SUIM irreführend sein. In den
Rollenauswertungen werden nur die Transaktionen ausgewertet, die über das Menü vergeben wurden,
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 98
‚Rollen’ ‚nach Berechtigungsobjekt’ (z.B. P_ORGIN, HR: Stammda-
ten)
Es erfolgt eine Anzeige der Rollen mit Berechtigungen für die
HR-Stammdaten (über das Berechtigungsobjekt P_ORGIN).
Ebenso kann nach Rollen mit (kritischen) Transaktionen, Be-
rechtigungen oder Profilen gesucht werden.
‚Benutzer’ ‚mit kritischen Berechtigungen’
es erfolgt u.a. eine Anzeige der kritischen Berechtigung und der
dieser Rolle zugeordneten Benutzer (Report
RSUSR008_009_NEW).
Anmerkung: Die SAP Vorschläge zu kritischen Berechtigungen fokussieren kritische Berech-
tigungen aus technischer Sicht. Zur optimalen Nutzung dieses Reports sind die „kritischen
Berechtigungen“ unbedingt kundenseitig nachzupflegen.
Über den Solution-Manager kann jederzeit der SOSS-Report (Security Optimization Self Ser-
vice) erzeugt und abgerufen werden. Diese bietet einen Überblick über vorhandene und als
kritisch eingeschätzte Berechtigungen. Die Checks des SOSS können vom Kunden auch er-
gänzt werden.
Mit SAP GRC Access Control (kostenpflichtige Komponente) ist es möglich, die im SAP-
System vergebenen Rollen und Berechtigungen zu analysieren. Kritische Berechtigungen
werden auf der Basis von vordefinierten Regeln identifiziert, siehe hierzu Kapitel 6.
Risiken und zu ergreifende Maßnahmen
Um dem Risiko der unzulässigen Zugriffe auf das SAP ERP-System zu begegnen und die
grundsätzlichen Schutzmechanismen der im SAP ERP-System zur Verfügung gestellten In-
strumente zum Berechtigungskonzept zu aktivieren, sollten die o.g. Profile grundsätzlich in
einem Produktivsystem nicht vergeben werden. Dies ist v.a. aufgrund folgender Sachverhalte
erforderlich:
Fehlende Prüfbarkeit und Nachvollziehbarkeit, z.B. durch die Nutzung der Replace-
Funktion im Debugging oder dem Löschen von Änderungsbelegen (Bestandteil der Be-
rechtigungen u.a. in SAP_ALL)
Verletzung der Datenschutzanforderungen durch ein nicht angepasstes Berechtigungskon-
zept
Umgehung des Zugriffschutzes des SAP ERP-Systems mit Hilfe von Entwicklerrechten
(insbesondere Umgehung bzw. Ausschalten des Authority Checks)
Umgehung der für die logischen Datenbanken benötigten Zugriffsrechte durch das direkte
Lesen der transparenten Tabellen z.B. durch Zugriff auf die Tabellen des Personalstamms
(PAxxxx). Durchsuchen Sie die Reportsourcen mit RS_ ABAP_SOURCE_SCAN_nach
direkten Zugriffen auf kritische Tabellen ohne Berechtigungsprüfung (z.B: nach dem Pro-
grammcode „SELECT PA0001“ suchen).
Umgehung der Mandantentrennung durch Verwendung von ABAP-Select Befehlen mit
dem Zusatz CLIENT-SPECIFIED, Prüfung wie oben.
wenn im Profil die das Objekt S_TCODE manuell ergänzt wurde, kann diese Transaktion in der
SUIM nur über eine Suche über Objekt S_TCODE ausgewertet werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 99
Reduzieren und auch Ausschalten der HR-Berechtigungsprüfung mit dem Berechtigungs-
objekt P_ABAP oder dem Funktionsbaustein
HR_READ_INFOTYPE_AUTHC_DISABLE: Berechtigungsprüfung für
HR_READ_INFOTYPE abschalten der Funktionsgruppe HRAC: HR-
Berechtigungsprüfung.
Veränderung des Systemzustandes, z.B.:
- Vergabe von Zugriffsberechtigungen an einen unberechtigten Benutzer oder für unzu-
lässige Programme
- Einrichtung nicht vereinbarter Dateien, Datenfelder oder Schlüssel
Vertuschen von Verstößen durch Änderung der Systemparameter, z.B. durch:
- Verfälschen der Protokolldateien z.B. durch zeitweiliges Ausschalten der Tabellenpro-
tokollierung. Dies erfordert aber Zugriff auf die Profilparameter, die Tabellenaktivie-
rungsberechtigung oder die Entwicklerberechtigung
- Umgehung von Zugriffsberechtigungsprüfung durch Ausschaltung der Berechtigungs-
prüfung
Grundsätzlich ist es erforderlich, die von SAP ausgelieferten “Musterprofile” funktionsbezo-
gen an die Anforderungen des Unternehmens anzupassen um so einen adäquaten und den un-
terschiedlichen rechtlichen Anforderungen entsprechenden Zugriffschutz zu gewährleisten.
Ausnahme von der dargestellten Anforderung kann die Zulässigkeit der Vergabe eines weit-
reichenden Profils an Notfall-User sein. Ein Beispiel hierfür könnte das von SAP ausgeliefer-
te Profil SAP_ALL sein, das um die Berechtigung zum Löschen oder Deaktivieren von Pro-
tokollierungen reduziert werden sollte (Objekt S_SCD0).
4.2.1.5 Besonderheiten bei der Berechtigungsprüfung
Ausschaltung/Modifikation von Berechtigungsprüfungen
Wie in Kapitel 4.2.1.1. (Identifizierung und Authentifizierung) dargestellt, können Berechti-
gungsprüfungen durch entsprechende Parametereinstellungen ausgeschaltet werden.
Außerdem ist es möglich, die Prüfung zu einzelnen Berechtigungsobjekten im SAP ERP-
System global mit Hilfe der Transaktionen SU24, SU25, SU26 auszuschalten (Ausnahme:
Berechtigungsobjekte der Basis und des HCM-Moduls (beginnend mit S_xxx und P_xxx las-
sen sich auf diese Weise nicht global ausschalten). Die Berechtigungsprüfungen des Java-
Stacks (UME30 -Rollen) werden durch diese Transaktionen nicht global ausgeschaltet.
Die Transaktionen SU25 und SU26 umfassen verschiedene Aktivitäten wie z.B. ‚Installation
des Profilgenerators’ oder ‚Transport von Kundentabellen’. Das ‚globale Ausschalten von Be-
rechtigungsobjekten’ in der SU25/SU26 wird mit Hilfe der Transaktion
AUTH_SWITCH_OBJECTS durchgeführt.
Das globale Ausschalten von Berechtigungsobjekten ist aus Datenschutzsicht problematisch.
Folgende Schutzmaßnahmen können ergriffen werden:
30 UME (User Management Engine)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 100
Sperren der Transaktion AUTH_SWITCH_OBJECTS mit Hilfe der Transaktion SM01
(Transaktionscodes Sperren/Entsperren)
Profilparameter ‚auth/object_disabling_active’ auf den Wert "N" setzen (um Berechtigungs-
prüfungen für bestimmte Berechtigungsobjekte zu unterdrücken, muss der Profilparameter
auth/object_disabling_active auf den Wert "Y" gesetzt werden).
Für den Fall, dass ausnahmsweise das globale Ausschalten von einzelnen Berechtigungsob-
jekten erlaubt sein soll, ist mindestens die folgende Empfehlung aus der SAP-Dokumentation
zu befolgen:
„Zum Sichern bzw. Aktivieren von deaktivierten Berechtigungsprüfungen zu Berechti-
gungsobjekten wird eine Berechtigung zum Objekt S_USER_OBJ benötigt. Aus Si-
cherheitsgründen sollten Sie die Berechtigungen für das Sichern und das Aktivieren
von deaktivierten Berechtigungsprüfungen zu Berechtigungsobjekten verschiedenen
Benutzern zuordnen. Es ist sinnvoll, wenn das Deaktivieren von Berechtigungsprüfun-
gen nach dem 4-Augen-Prinzip stattfindet.“
Prüfkennzeichen in der SU22/SU24
Für die Prüfkennzeichen eines Berechtigungsobjektes sind folgende Werte vorgesehen.
U Prüfkennzeichen wurde nicht spezifiziert - Berechtigungsobjekt
wird geprüft (wie bei 'P')
N Berechtigungsobjekt wird unter Transaktion nicht geprüft
P Berechtigungsobjekt wird unter Transaktion geprüft
PP Berechtigungsobjekt wird unter Transaktion geprüft und im
Profilgenerator werden die angegebenen Feldwerte vorgeschla-
gen
Der Wert N ist prüfungsrelevant und nur nach genauer Prüfung und Dokumentation der Prü-
fungsergebnisse zu setzen. Dieser Wert sollte nur in dem Fall gesetzt werden, in dem die Or-
ganisation mit an Sicherheit grenzender Wahrscheinlichkeit ausschließen kann, dass das Ob-
jekt (und / oder die Applikation) genutzt wird.
Die P_ABAP-Berechtigung ist nur einzuräumen, wenn diese nachweislich im Programmcode
(der Funktionen für die Buchungssatzübernahme für Gehalts- und Reisekostenbuchenen) bei
AUTHORITY-CHECK angefordert wird.
Authority Check bei ABAP-Programmen (Standardprogramm oder Eigenentwicklun-
gen)
Der Zugriffsschutz baut bei SAP ERP-Systemen im Wesentlichen auf maschinellen Kontrol-
len auf, die in den Programmen hinterlegt sind. Dabei handelt es sich um das ABAP-
Sprachelement “Authority Check”, welches in den Programmen hinterlegt werden kann. Bei
Ausführung eines Programms erfolgt durch diesen Authority Check die Kontrolle, ob die Be-
rechtigungen des aufrufenden Benutzers ausreichend sind. Im positiven Fall wird der Zugriff
auf die Informationen zugelassen; im negativen Fall ist das Programm so zu gestalten, dass
der Zugriff ausgeschlossen ist.
Ein zuverlässiger Zugriffsschutz kann nur sichergestellt werden, wenn die Authority Checks
technisch und inhaltlich sachgerecht programmiert sind. Dies betrifft sowohl SAP-
Standardprogramme als auch kundeneigene Reports.
Es wird empfohlen in einer Programmierrichtlinie die technische und inhaltlich sachgerechte
Programmierung detailliert festzulegen. Dabei ist die inhaltliche Richtigkeit in Verbindung
mit dem bestehenden Berechtigungskonzept und dem Schutzanliegen zu definieren.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 101
Es empfiehlt sich, beim Lesen und Ausprobieren der folgenden Hinweise die mySAP HR
Spezial-Dokumentation vom SMP (Service Market Place (service.sap.com) Suchbegriffe: hr
special documentation) bereitzustellen und zu lesen.
Berechtigungshauptschalter HR (Tabelle T77S0; GRPID „AUTSW“)
Wie dargestellt, kommt dem Berechtigungsobjekt P_ORGIN (HR: Stammdaten) im Rahmen
des Zugriffs auf personenbezogene Informationen eine besondere Bedeutung zu. Ob dieses
Berechtigungsobjekt und weitere HCM-Berechtigungsobjekte oder strukturelle Berechtigun-
gen (Schalter ORGPD) systemseitig verprobt werden, ist von Customizing-Einstellungen ab-
hängig. Die Einstellung erfolgt in der Tabelle T77S0 (Systemtabelle). Dort wird über sog.
Semantische Kürzel festgelegt, ob die Berechtigungsobjekte überhaupt für Berechtigungsprü-
fungen aktiv sind.
Eine systematische Überprüfungsmethode für die vergebenen HCM-Berechtigungen inklusive
der strukturellen Berechtigungen mit dem Benutzerinformationssystem gibt es nur teilweise.
Die Prüfung auf der Ebene der Einzelberechtigung eines Benutzers kann mit der Transaktion
HRAUTH_ Berechtigungs-Workbench (Programm; RHANALYSIS_TOOL; Hinweise:
902000 – Analyse von HR-Berechtigungen) erfolgen. (Es fehlt bisher ein Reiter für die rever-
se Funktion: Wer alles hat auf einen Infotyp einer bestimmten Person welche Berechtigun-
gen?)
Um den Prüfaufwand zu verringern, kann die ausschließliche Nutzung der kontextsensitiven
Berechtigungen und die Definition kritischer struktureller Profile in Verbindung mit den ent-
sprechenden Berechtigungsobjekten (PLOG_CON, P_ORGINCON, P_ORGXXCON) als
„kritische Berechtigung“ oder „kritische Berechtigungskombination“ wirksam genutzt wer-
den. Dabei müssen Struktur- und Funktionsinformationen zusammengebracht und bewertet
werden. Hier empfiehlt sich der Einsatz von Zusatztools (s. Kap. 6).
Die Nutzung der HR-Berechtigungs-BAdIs:
HRPAD00AUTH_CHECK: Kundenindividuelle Berechtigung einrichten,
HRPAD00AUTH_TIME: Kundenindividuelle Zeitlogik zusätzlich einrichten,
HRBAS00_STRUAUTH: Strukturelle Berechtigungen
HRBAS00_RHBAUS00: (Index für Strukturberechtigung)
HRBAS00_GET_PROFL: Kundenindividuelle Bestimmung der strukturellen Profile
ist im Berechtigungskonzept zu begründen und fundiert zu prüfen, da die durch die BAdI-s
vorgenommen Berechtigungsprüfung die Prüfung durch die HR-Berechtigungsobjekte teil-
weise ersetzt.
Die in den BAdIs:
HRBAS00INFTY: (Verbucher bei PBO, PAI, vor Update und während Update)
HRPAD00INFTY: (Verfahren für Infotypen PBO, PAI und während Update)
per Auslieferung zur Verfügung gestellten Funktionen sind zu überprüfen und als kundenei-
gene Funktionen zu dokumentieren bzw. zu deaktivieren.
Report Berechtigungsgruppen
Der Zugriff auf sensible Reports kann neben der skizzierten Verwendung von Authority-
Checks über Transaktionscode-Zuordnungen oder Berechtigungsgruppen geschützt werden.
Bei der Transaktionscode-Zuordnung ist sicherzustellen, dass Benutzer Reports ausschließlich
über eine eigens zugeordnete Transaktion aufrufen können. Der allgemeine Aufruf über
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 102
Transaktionen wie SA38, SE38, START_REPORT (ABAP Reporting) ist in diesem Fall
auszuschließen.
Alternativ kann ein Schutz über Berechtigungsgruppen realisiert werden. Dabei sollte jeder
relevante Report einer spezifischen Berechtigungsgruppe zugeordnet werden. Nicht verwen-
dete Reports sollten einer Berechtigungsgruppe ‚Gesperrt‘, allgemeinzugängliche einer Be-
rechtigungsgruppe ‚Allgemein‘ zugeordnet werden. Die Zuweisung kann über den Report
RSCSAUTH vorgenommen werden. Korrespondierend sind im Berechtigungskonzept die Be-
rechtigungen zu dem Objekt S_PROGRAM (ABAP: Programmablaufprüfungen) zu definie-
ren. Da im Regelfall die SAP Standardreports ohne Zuordnung zu einer Berechtigungsgruppe
ausgeliefert werden, muss dieser Schutzmechanismus vom Anwenderbetrieb realisiert wer-
den.
Aus den oben genannten Gründen ist die SA38 nur sehr restriktiv an Benutzer zu vergeben.
Jeder Report der keiner Berechtigungsgruppe zugeordnet ist, kann mit der SA38 ohne weitere
Prüfung31 ausgeführt werden.
Risiken und zu ergreifende Maßnahmen
Das Ausschalten von Berechtigungsprüfungen ist mit erheblichen Risiken verbunden, da im
SAP-Standard vorgesehene Zugriffsschutzmechanismen dadurch außer Kraft gesetzt werden
können. Neben der Kontrolle des Parameters AUTH/NO_CHECK_IN_SOME_CASES dient
folgendes Vorgehen zur Überwachung:
Anzeigen der Tabelle USOBX_C (Checktabelle zu Tabelle USOBT_C) mit Hilfe der
Transaktion SE17 (Allg. Tabellenanzeige)
Analyse, ob die Tabelle Einträge mit OKFLAG = N enthält. Die Berechtigungsprüfung zu
entsprechenden Berechtigungsobjekten ist transaktionsbezogen deaktiviert
Schutzmaßnahmen gegen das globale Ausschalten von Berechtigungsobjekten (Transaktionen
AUTH_SWITCH_OBJECTS, SU25, SU26) sind in Abschnitt 4.2.1.5.1 beschrieben.
In Bezug auf die Verwendung von Authority-Checks bilden folgende Maßnahmen geeignete
Ansatzpunkte zur Gewährleistung des Datenschutzes:
Aufbau einer Entwicklungsrichtlinie bei der Programmierung von kundeneigenen ABAPs.
In dieser Richtlinie sind z.B. die Verwendung von Authority-Checks, Berechtigungsgrup-
pen für Reports sowie Test-, Freigabe- und Dokumentationsanforderungen festzulegen.
Für SAP ERP-Standardprogramme sollten entsprechende SAP-Hinweise (SAP Service
Marketplace; service.sap.com/notes) beachtet werden, um bei bekannten Lücken bzw.
notwendigen Korrekturen die Authority-Checks in den Programmen ergänzen oder korri-
gieren zu können.
In Bezug auf den Berechtigungshauptschalter HR sind die Einstellungen für die aktiven Be-
rechtigungsobjekte im Anwenderbetrieb als Soll-Werte festzulegen. In regelmäßigen Abstän-
den sollten die im SAP ERP-System vorgenommenen Ist-Einstellungen (Tabelle T77S0)
überwacht werden. Ferner sind Maßnahmen zu definieren, wie z.B. der Zeilenschutz für die
Tabellenadministration über das Berechtigungsobjekt S_TABU_LIN, um eine Manipulation
des Berechtigungshauptschalters durch unberechtigte Benutzer auszuschließen.
31 Die Authority Checks im Programmcode der Reports werden weiterhin ausgeführt, sofern sie
vorhanden sind.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 103
Bezüglich der Report-Berechtigungsgruppen sollte im Rahmen des Berechtigungskonzeptes
definiert werden, mit welchen Maßnahmen Reports vor unzulässigem Zugriff geschützt wer-
den. Werden hierzu Berechtigungsgruppen verwendet, sind die Zuordnungen von Reports zu
Berechtigungsgruppen periodisch zu überwachen. Insbesondere ist bei Releasewechseln zu
beachten, dass mit neuen SAP-Standardprogrammen auch deren Einstellung in Berechti-
gungsgruppen neu installiert wird.
4.2.1.6 Benutzeradministration
Konzeption der zentralen Benutzeradministration
Der Benutzer identifiziert sich gegenüber dem SAP-System durch Eingabe seiner Benutzer-
ID und seines Kennwortes. Im Benutzerstammsatz sind die Zugriffsrechte des Anwenders
hinterlegt. Für diese Hinterlegung, die Pflege der Zugriffsrechte im Benutzerstammsatz, bietet
das SAP-System verschiedene organisatorische Alternativen, die im Folgenden beschrieben
werden.
Bei der zentralen Benutzerpflege ist eine zentrale Stelle für die Pflege aller Benutzerstamms-
ätze zuständig. Die Rollen- oder Profilzuordnung kann zentral oder auch dezentral – über das
Customizing bis auf Berechtigungsobjekt- und Feldebene einstellbar – erfolgen.
Da die Benutzeradministration sowie die Administration der Zugriffsrechte sicherheitssensib-
le Aktivitäten darstellen, besteht im SAP-System die Möglichkeit, ein organisatorisches
Mehr-Augen-Prinzip abzubilden.
Dabei spricht SAP die Empfehlung aus, eine Funktionstrennung zu gewährleisten, z.B. durch
Einrichtung eines Benutzeradministrators, eines Rollenadministrators und eines Aktivierungs-
administrators.
Die Aufgaben des Benutzeradministrators beziehen sich auf die Anlage und Pflege von Be-
nutzerstammsätzen.
Der Rollenadministrator pflegt die Elemente des Berechtigungskonzeptes. Dies sind je nach
konzeptuellem Vorgehen Rollen, Profile bzw. Berechtigungen.
Der Aktivierungsadministrator ist für die Verwendbarkeit der Elemente des Berechtigungs-
konzeptes zuständig. Auch hier sind die Aufgaben von dem konzeptionellen Vorgehen ab-
hängig. Sie bestehen in einer Aktivierung von Berechtigungen bzw. Profilen, die der Rollen-
administrator in der Pflegeversion erstellt hat. Alternativ bestehen sie in der Durchführung
des Benutzerabgleichs. Dabei werden die Rollen mit den darin hinterlegten Profilen und Be-
rechtigungen den Benutzerstammsätzen zugeordnet.
Um diese Trennung der unterschiedlichen Administrationsaufgaben zu ermöglichen, hat SAP
in der Objektklasse “Basis-Administration” u.a. die folgenden Berechtigungsobjekte definiert:
Benutzerstammpflege: Benutzergruppen (S_USER_GRP)
Benutzerstammpflege: Berechtigungen (S_USER_AUT)
Benutzerstammpflege: Berechtigungsprofil (S_USER_PRO)
Berechtigungswesen: Prüfung für Rollen (S_USER_AGR)
Berechtigungswesen: Transaktionen in Rollen (S_USER_TCD)
Berechtigungswesen: Feldwerte in Rollen (S_USER_VAL)
Adminfunktion für Benutzer/Berechtigungsverwaltung (S_USER_ADM)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 104
Benutzerstammpflege: Systemspezifische Zuordnungen (S_USER_SAS) Das Berechti-
gungsobjekt S_USER_SAS ist einer Weiterentwicklung der Objekte S_USER_AGR,
S_USER_PRO und S_USER_GRP
Die oben genannten Berechtigungsobjekte werden ebenfalls bei der Verwendung des Profil-
generators (Transaktion PFCG) geprüft.
Konzeption der dezentralen Benutzeradministration
Bei dieser Form der Administration können die Pflegeaufgaben auf mehrere Stellen verteilt
werden. Für welche Benutzerstammsätze ein Administrator zuständig ist, kann über die Be-
nutzergruppe gesteuert werden. Über korrespondierende Berechtigungen zu dem Berechti-
gungsobjekt S_USER_GRP (Benutzerstammpflege: Benutzergruppen) besteht die Möglich-
keit, die organisatorische Zuständigkeit systemseitig abzubilden.
Benutzeradministration mit dem Profilgenerator
Rollen enthalten die Berechtigungen, mit denen ein Benutzer auf die im Menü enthaltenen
Funktionen (Transaktionen, Berichte/Reports, web-gestützten Anwendungen usw.) zugreifen
kann. Rollen werden im Benutzerstammsatz hinterlegt.
Mit dem Werkzeug zur Rollenpflege, dem Profilgenerator, werden auf der Basis ausgewählter
Menüfunktionen Berechtigungen bzw. Profile automatisch erzeugt und zur Nachbearbeitung
angeboten. Darüber hinaus bietet der Profilgenerator eine Integration mit dem HR-
Organisationsmanagement.
Im Gegensatz zu der konventionellen Benutzerpflege können zeitabhängige Rollenzuordnun-
gen erfasst werden (befristete Vergabe von Berechtigungen).
Umgekehrt können auch die Benutzerstammsätze den Rollen zugeordnet werden. Hierfür ste-
hen auch die Transaktion PFUD bzw. der Report RHAUTUPD_NEW (Abgleich Benutzer-
stammsatz) zur Verfügung.
Veraltete Benutzeradministration mit Profilen
Bei der veralteten Benutzeradministration erfolgt die Zuweisung unmittelbar über Profile
(Einzel- oder Sammelprofile) im Benutzerstammsatz. Pflegt der Benutzeradministrator einen
Benutzerstammsatz, so ist die Änderung für den entsprechenden Anwender unmittelbar bei
seiner nächsten Anmeldung am SAP-System wirksam.
Die Nutzung von manuell erzeugten Profilen kann zu einer nicht mehr kontrollierbaren Pflege
von Berechtigungen führen.
Risiken und zu ergreifende Maßnahmen
In Bezug auf die dargestellte Benutzeradministration liegt das Risiko in Zugriffen auf das
SAP-System durch unbefugte Benutzer sowie in unzulässigen bzw. zu umfangreichen Zu-
griffsrechten der angelegten Benutzerstammsätze. Diesen Risiken ist durch organisatorische
Maßnahmen, z.B. Mehr-Augen-Prinzip, und deren technische Abbildung im SAP-System zu
begegnen.
Hierzu stehen die im Kapitel 4.2.1.6.1 dargestellten Berechtigungsobjekte zur Verfügung.
Über die für die entsprechenden Administratoren notwendige Ausprägung dieser Objekte
kann eine im o.g. Sinne verstandene Funktionstrennung abgebildet werden.
Da bei den SAP-Standardprofilen bzw. Standard-Rollen bezüglich des Datenschutzes Funkti-
onstrennungsgesichtspunkte häufig unzureichend berücksichtigt sind (vgl. u.a. S_A.SYSTEM
oder SAP_BC_USER_ADMIN), ist es erforderlich, unternehmensspezifisch eigene Elemente
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 105
zu erstellen. Hierbei sind die in 4.2.1.6.1 genannten Berechtigungsobjekte entsprechend den
sich stellenden Anforderungen auszuprägen.
Sollte aufgrund der vorhandenen Personalstärke eine dreistufige Funktionstrennung (6-
Augenprinzip) nicht realisierbar sein, empfiehlt es sich, zumindest eine zweistufige Funkti-
onsrennung zu implementieren (Benutzeradministration mit Rollenzuordnung einerseits und
Berechtigungsadministration mit Rollen- und Aktivierungsadministration andererseits).
4.2.1.7 Änderungen am Produktivsystem
Änderungen, die im produktiven SAP-System vorgenommen werden, unterliegen zu Nach-
weiszwecken der eingesetzten Verfahren bestimmten Protokollierungsanforderungen. Diese
Anforderung ergibt sich aus § 238 HGB ff.
Zur Sicherstellung der Protokollierung von Änderungen sind verschiedene Systemeinstellun-
gen zu treffen oder grundsätzliche Schutzmechanismen zu aktivieren, die unerlaubte Ände-
rungen von vornherein unterbinden.
Change and Transport System
Begriffsabgrenzung
CTO Der Change and Transport Organizer (CTO) stellt Funktionen
zur Erzeugung, Dokumentation und Freigabe von Änderungs-
aufträgen im Rahmen des Customizings zur Verfügung.
TMS Über das Transport Management System (TMS) wird u.a. die
Organisation und der Transport von diesen Aufträgen unter-
stützt.
Grundsätzlich sieht SAP im Rahmen der Anwendungsentwicklung und des Customizings vor,
dass drei voneinander unabhängige SAP-Systeme - Entwicklungssystem, Qualitätssicherungs-
system und Produktivsystem - genutzt werden sollen.
Daher sollten wegen
Einhaltung der Sicherheit der Datenbestände
Schutz vor unberechtigter Kenntnisnahme von personenbezogenen Daten
Nachvollziehbarkeit der Systemänderung
Berechtigungen zur Anwendungsentwicklung und zum Customizing in einem produktiven
SAP-System nicht vergeben werden. Um für die drei o.g. Systeme die Transportwege zu kon-
figurieren, sind Berechtigungen zur Administration (Objekt S_CTS_ADMIN) erforderlich.
Änderungen sollten zunächst grundsätzlich im Entwicklungssystem erfolgen und mit Hilfe
des TMS in das Qualitätssicherungssystem transportiert werden.
Nach Durchlaufen eines entsprechenden Test-, Abnahme-, und Freigabeverfahrens erfolgt
wiederum über das TMS die Einstellung in die Produktionsumgebung.
Je nach Konfiguration und Datenbestand können vom Datenschutzrecht geschützte personen-
bezogene Daten in allen Systemen vorkommen.
Über die bei der Nutzung des TMS erstellten Protokolle kann dabei die Nachvollziehbarkeit
der vorgenommenen Einstellungen sichergestellt werden.
Auf Protokolle über durchgeführte Transporte, vorgenommene Änderungen etc. kann aus den
Transaktionen STMS oder SE03 heraus zugegriffen werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 106
Tabellenprotokollierung / Customizing
Im Rahmen der Einführung von SAP sowie im laufenden Betrieb wird eine Vielzahl von Ta-
bellen den Anforderungen des Unternehmens entsprechend angepasst.
Da Änderungen an Tabellen in der Regel mit Programmänderungen gleichgesetzt werden
können, sind vorgenommene Änderungen ab Produktivstart zu protokollieren. Die Tabellen-
änderungsprotokolle sind entsprechend den gesetzlich geforderten Aufbewahrungsfristen (10
Jahre) vorzuhalten.
Im Auslieferungsstandard sieht SAP die Protokollierung von Tabellenänderungen aufgrund
der notwendigen Customizing-Maßnahmen nicht vor.
Für das Testsystem ist der Parameter - rec/client - auf OFF gestellt. Diese Einstellung muss
zum Beginn der Customizing-Arbeiten im Entwicklungssystem und nach Produktivstart im
Produktivsystem durch Ändern des Systemprofils (DEFAULT.PFL) dahingehend geändert
werden, dass entweder alle Tabellenänderungen im System protokolliert werden (ALL) oder
zumindest die des Auslieferungsmandanten (000) und des/der Produktivmandanten. Die Ein-
stellung ON ist nicht zulässig.
Wenn der Parameter rec/client eingeschaltet ist, werden Änderungsprotokollsätze für diejeni-
gen Tabellen geschrieben, die bei den technischen Einstellungen das entsprechende Kennzei-
chen gesetzt haben. Selbsterstellte Tabellen (T9, X, Y oder Z) müssen ggf. vom Kunden als
protokollierungspflichtig gekennzeichnet werden.
Die Pflege des Protokollierungskennzeichens von Tabellen wird mit der Transaktion SE13
durchgeführt.
Customizing-Einstellungen sollten i.d.R. nicht im Produktivsystem vorgenommen werden,
um ein erforderliches Test-, Abnahme- und Freigabeverfahren nicht zu unterlaufen und si-
cherzustellen, dass die vorgenommenen Einstellungen anforderungsgerecht vorgenommen
wurden.
Zu berücksichtigen ist in diesem Zusammenhang, dass bei der Nutzung des TMS sicherzustel-
len ist, dass auch bei Transporten von Customizing-Änderungen im Zielsystem eine Protokol-
lierung der Tabellen erfolgt. Hierzu ist es erforderlich, den Parameter RECCLIENT (Para-
meter für die Tabellenprotokollierung beim Transport) zu setzen (off: keine Protokollierung;
all: die Protokollierung erfolgt für alle Mandanten; xxx: für die aufgeführten Mandanten wird
protokolliert). Dieser Parameter ist von rec/client bzgl. der Tabellenprotokollierung im Pro-
duktivsystem zu unterscheiden.
Systemänderbarkeit
Über die Transaktion SE06 kann gesteuert werden, ob Objekte des Repository und des man-
dantenunabhängigen Customizings änderbar sind.
Dabei können einzelne Objekte, wie z.B:
Kundenentwicklungen
SAP-Basiskomponente
Development Workbench
spezifisch geschützt werden. Über eine dieser Transaktion zugeordneten Schaltfläche lassen
sich entsprechende Änderungsprotokolle auswerten.
Über die in dieser Transaktion festgelegten Schutzmechanismen ergeben sich keine Auswir-
kungen auf mandantenabhängige Customizing-Änderungen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 107
Diesbezüglich werden entsprechende Sicherheitsmechanismen über die Mandantensteuerung
(vgl. Schutz der Tabelle T000) festgelegt.
Protokolle
Wenn in SAP Änderungen an Objekten/Tabellen vorgenommen werden, wird – entsprechen-
de Systemeinstellungen vorausgesetzt – ein Eintrag in einer Änderungsprotokolldatei erzeugt.
Dieser ist in dem Datei-/Datenbanksystem des SAP-Systems abgelegt. Jede SAP-Installation
besitzt ihre eigene Datenbank und somit ein eigenes Datei-/Datenbanksystem. Ausnahmen
gelten für Transportprotokolle, da diese in einem gemeinsamen Transportverzeichnis abgelegt
werden.
Schutz der Tabelle T000: Mandanten
Über entsprechende Einstellungen der Tabelle T000 ist es möglich, Änderungen am SAP-
System grundsätzlich oder für bestimmte Teilbereiche zu unterbinden. Um entsprechende
Einstellungen anzuzeigen oder zu pflegen dient die Transaktion SCC4: Mandantenver-
waltung. Es können verschiedene Einstellungen bzgl.
Änderungen für Transporte und mandantenabhängige Objekte
Änderungen an mandantenübergreifenden Objekten
Schutz bzgl. Mandantenkopier- und Vergleichstools
getroffen werden.
Grundsätzlich sollten die Einstellungen so gewählt werden, dass Änderungen im Produk-
tivsystem nicht möglich sind.
Sollte es erforderlich werden, das System hinsichtlich Änderungsmöglichkeiten zu öffnen, ist
sicherzustellen, dass keine unkontrollierten Änderungen vorgenommen werden – entspre-
chende Dokumentationsunterlagen sollten erstellt werden – und das nach den vorgenomme-
nen Einstellungen der Änderbarkeitsstatus wieder zurückgesetzt wird.
Risiken und zu ergreifende Maßnahmen
Zur Sicherstellung der ordnungsmäßigen Programmanwendung und zum Schutz vor unbe-
rechtigter Kenntnisnahme oder versehentlicher/absichtlicher Manipulation von Daten ist si-
cherzustellen, dass über die getroffenen Systemeinstellungen ein hinreichender Systemschutz
vor Veränderungen gegeben ist und erforderliche Änderungsprotokolle erstellt werden. In
diesem Zusammenhang sollte sichergestellt werden, dass
eindeutige und verbindliche Regelungen bzgl. der Pflege, der Kontrolle und der Protokol-
lierung von Tabellen getroffen werden, um sowohl die gesetzlichen Anforderungen erfül-
len zu können als auch dem Risiko der bewussten oder unbewussten Manipulation von
Datenbeständen vorzubeugen sowie den Anforderungen, die sich an den Schutz personen-
bezogener Daten stellen, gerecht zu werden
die entsprechenden Systemparameter hinsichtlich des TMS, der Transaktion SE06 und der
Einstellungen bzgl. der Tabelle T000 getroffen sind
die erzeugten Protokolle gemäß den gesetzlichen Aufbewahrungsfristen vorgehalten und,
sofern erforderlich, wieder lesbar gemacht werden können.
Eine regelmäßige Kontrolle der getroffenen Einstellungen bzw. nachgelagerte Kontrollen der
erzeugten Änderungsbelege ist ebenfalls geboten.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 108
4.2.1.8 Systemschnittstellen
Für die Kommunikation innerhalb eines SAP ERP-Systems, dem Informationsaustausch zwi-
schen verschiedenen SAP ERP-Systemen oder der Kommunikation zwischen SAP ERP- und
Fremdsystemen stellt SAP verschiedene Schnittstellenmethoden zur Verfügung.
Batch-Input
Bei dem Batch-Input-Verfahren werden Daten in einer sogenannten Batch-Input-Mappe ge-
speichert. Die Übernahme der Daten erfolgt durch das Abspielen der Batch-Input-Mappe. Sie
simuliert die Online-Eingabe von Transaktionscodes und Daten und durchläuft beim Abspie-
len die entsprechenden Berechtigungs- und Plausibilitätsprüfungen.
RFC, ALE, BAPI
Der Remote Function Call (RFC) dient der Kommunikation zwischen verteilten Programmen
in einer SAP-Systemlandschaft. Mit Hilfe von RFC können Funktionsbausteine in einem
fremden SAP-System aufgerufen werden und die Ergebnisse an das aufrufende System zu-
rückgegeben werden.
Die Technik von RFC bildet auch die Grundlage für weitere SAP spezifische Schnittstellen-
methoden, wie Application Link Enabling (ALE) und Business Application Program Interface
(BAPI).
Eine besondere Fragestellung wirft die Übergabe von HCM-Daten in ein separates Logistik-
system auf. SAP bietet hierzu im Customizing Standard ALE Schnittstellen an, die immer
vollständige Infotypen an das angeschlossene Logistiksystem weiter geben (siehe in der
Transaktion SPRO ( SAP Referenz-IMG) SAP NetWeaver Application Server Ap-
plication Link Enabling Geschäftsprozesse modellieren vordefinierte ALE Geschäfts-
prozesse Personalwirtschaft HR <->LO). Das bedeutet, dass bei der Übermittlung des
Infotyps 0002 im Standard auch das Datenfeld „Nationalität“ und „Konfession“ übergeben
werden. Datenfelder, denen mit hoher Wahrscheinlichkeit die Rechtsgrundlagen zur Verarbei-
tung in der Logistik fehlen. Hier ist durch gesonderte Maßnahmen in der Berechtigungsver-
waltung sicherzustellen, dass eine zweckentfremdete Nutzung ausgeschlossen wird (vgl. An-
lage zu § 9 Nr. 8 BDSG).
Auch bei anderen Schnittstellen des HCM, z.B. in das Controlling oder zur Arbeitszeiterfas-
sung (CATS bzw. CATSXT), ist die Einhaltung der Zweckbindung zu beachten.
PC-Download
SAP bietet die Möglichkeit, die unterschiedlichsten Auswertungen per Download aus der ”ge-
sicherten SAP-Umgebung” auf den PC zu übertragen und dort ohne zusätzliche Kontrollen
weiterzuverarbeiten. Dabei bezieht sich der Download z.B. auf jede Art von Listausgaben, die
auf den PC übertragen werden können.
Menüpfad:
System -> Liste -> Sichern -> Lokale Datei
Um dem Risiko der Übertragbarkeit von personenbezogenen Daten und einem möglichen
Missbrauch bei deren Weiterverarbeitung zu begegnen, stehen im SAP ERP-System ver-
schiedene Berechtigungsobjekte zur Verfügung.
ABAP-Listviewer (ALV)
Über den häufig verwendeten ABAP-Listviewer können angezeigte Daten ohne weitere Be-
rechtigungsprüfung oder Protokollierung per "Kopieren" und "Einfügen" in ein beliebiges an-
deres Programm übernommen werden. Siehe Abschnitt 4.2.1.3.11.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 109
Risiken und zu ergreifende Maßnahmen
Nach jedem Datenexport in Fremdsysteme können innerhalb der SAP-Umgebung Zweckbin-
dung, Löschfristen und andere datenschutzrechtliche Anforderungen nicht mehr gewährleistet
werden.
Bei jeder Form der Schnittstellenverarbeitung liegen die Risiken vorrangig in
der unvollständigen bzw. fehlerhaften Verarbeitung
der Manipulation während der Datenübertragung bzw. des Programmablaufs
der unzulässigen Einsichtnahme in personenbezogene Daten
der unkontrollierten Weitergabe dieser Daten
Diesen Risiken ist durch geeignete Maßnahmen zu begegnen. Als organisatorische Maßnah-
me sollten grundsätzlich alle Schnittstellendateien und die genutzten Verfahren entsprechend
den Anforderungen des BDSG dokumentiert werden (§ 4g BDSG, Stichwort “Überwachung
der ordnungsgemäßen Anwendung”, § 4e BDSG, Stichwort “Beschreibung der Daten oder
Datenkategorien”).
An technischen Maßnahmen stehen im SAP ERP-System verschiedene interne Kontrollstufen
zur Verfügung, bei denen eine ordnungsgemäße Einstellung, insbesondere auch in dem Zu-
sammenspiel der Kontrollen, vorzunehmen und regelmäßig zu überwachen ist. Als zentrale
technische Maßnahmen sind folgende Aspekte zu nennen:
In Bezug auf das Batch-Input-Verfahren kann über das Berechtigungskonzept festgelegt
werden, welche Benutzer Batch-Input-Mappen z.B. erstellen, abspielen und löschen kön-
nen. Die Zugriffe werden über Berechtigungen zu dem Berechtigungsobjekt
S_BDC_MONI (Batch-Input Berechtigungen) bestimmt.
In Bezug auf die Remote Function Call-Technologie (RFC) sind die Sicherheitseinstel-
lungen der RFC-Destinationen (Transaktion RSRSDEST - Ausgabe Systemübersicht für
remote submit) zu beachten. Deren Pflege wird über das Berechtigungsobjekt
S_ADMI_FCD (Systemberechtigungen) gesteuert. Ob bei RFC überhaupt Berechtigungs-
prüfungen erfolgen, ist von der Einstellung des Profilparameters auth/rfc_authority_check
abhängig. Er kann z.B. mittels des Reports RSPARAM überwacht werden. Aus Sicher-
heitsgründen ist die Aktivierung der Berechtigungsprüfung für RFC unbedingt zu empfeh-
len. Ist die grundsätzliche Aktivierung eingestellt, so greifen die Zugriffsschutzkontrollen
durch das Berechtigungsobjekt S_RFC (Berechtigungsprüfung beim RFC-Zugriff).
In Bezug auf Application Link Enabling (ALE) sind das Verteilungsmodell sowie die
ALE-Berechtigungen zu pflegen. Um auf entsprechende Funktionalitäten zugreifen zu
können, kann die Transaktion SALE genutzt werden. Die darin enthaltenen Transaktionen
und Reports sind dann entsprechend zu schützen.
In Bezug auf den PC-Download steht für die Kontrolle zum generischen Listen-Download
das Berechtigungsobjekt S_GUI (Berechtigung für GUI-Aktivitäten) zur Verfügung. Zu-
sätzlich besteht die Möglichkeit ein kundeneigenes Berechtigungsobjekt anzulegen, um
die Downloadsteuerung zu differenzieren. Die Vorgehensweise zur Anlage eines solchen
Berechtigungsobjekt wird im SAP-Hinweis 28777 (PC Download: Protokollierung, Be-
rechtigungsprüfung) beschrieben. Ein solches Objekt bietet etwa die Möglichkeit, den
Download für bestimmte, problematische Transaktionen zu sperren. Um dieses kundenei-
gene Berechtigungsobjekt (z.B.: Z_DOWNLD) einsetzen zu können, wird im SAP-
System der User-Exit „EXIT_SAPLGRAP_001“ bzw. der Include „ ZXFILU01“ verwen-
det.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 110
In Bezug auf den ABAP-Listviewer können in kritischen Programmen die entsprechenden
Oberflächenfunktionen durch Programmergänzung ausgeblendet werden, etwa über den
Parameter IT-EXCLUDE im Funktionsbaustein REUSE_ALV_GRID_DISPLAY. Über
einen User-Exit können als kundeneigene Erweiterung die Downloadberechtigungen auf
die Transaktion oder den Reportnamen differenziert werden.
Weitere SAP-unabhängige Lösungen sind in speziellen CITRIX-Umgebungen realisier-
bar, z.B. die Unterbindung der Cut and Paste Funktion.
4.2.1.9 Auditing und Logging
Es ist zu beachten, dass die Konfiguration und die Auswertung der nachfolgenden Protokolle
neben IT-Security, Revision und Wirtschaftsprüfern auch mit dem Datenschutzbeauftragten
abzustimmen ist und die Mitbestimmungsrechte der Arbeitnehmervertretungen beachtet wer-
den.
Für Auditing und Logging ist ein Einsatzkonzept erforderlich, in dem die Anforderungen der
einzelnen Bereiche bezüglich der Einstellungen, der Einsichtnahme und der Aufbewahrungs-
dauer festzulegen sind. Die benötigten IT-Ressourcen (z.B. zusätzlicher Speicherbedarf) sind
dafür bereitzustellen.
Security Audit Log
Aus Datenschutzsicht ist zu empfehlen, Benutzer mit weit reichenden, kritischen Berechti-
gungen einer Protokollierung mit dem Security Audit Log zu unterwerfen. Da eingerichtete
Notfall-User i.d.R. mit umfassenden Berechtigungen ausgestattet sind, ist es den rechtlichen
Anforderungen entsprechend erforderlich, einen Nachweis der ausgeführten Aktivitäten zu
erbringen.
Die erforderlichen Einstellungen des Security Audit Logs sind vor allem im Rahmen eines be-
trieblichen Sicherheits- und Datenschutzkonzeptes zu betrachten. Dabei sind auch weitere
rechtliche Anforderungen (z.B. GoBS, HGB, Sarbanes-Oxley-Act) zu berücksichtigen.
Das Security Audit Log steht als ‚erweitertes Sicherheitsprotokoll’ in SAP-Systemen zur Ver-
fügung. In mehreren Filtern können in verschiedenen ‚Auditklassen’ unkritische, schwerwie-
gende und kritische Ereignisse für die Protokollierung eingestellt werden.
Über die Transaktion SM19 kann instanzen-, mandanten-, und benutzerbezogen festgelegt
werden, welche Ereignisse protokolliert werden sollen. Auch die Protokollierung von Down-
loads kann vorgenommen werden.
Um das Security Audit Log zu nutzen, ist eine entsprechende Parametrisierung vorzunehmen.
Im SAP Hinweis 539404 werden die häufigsten Fragen zur Konfiguration und Anwendung
des Security Audit Logs beantwortet.
Damit Protokolle aber überhaupt erzeugt werden, muss über die o.g. Einstellungen hinaus in
den Profilparametern der Eintrag rsau/enable auf 1 gesetzt werden.
Mit dem Profilparameter rsau/selection_slots legen Sie fest, wie viele Filter (Slots) Sie bei
der Konfiguration des Security Audit Log zur Verfügung haben. Der Systemdefaultwert ist 2,
seit Release 4.6 sind maximal 10 unterschiedliche Filter konfigurierbar.
In der Transaktion SM19 sind die Felder ‚Benutzer’ und ‚Mandant’ ab SAP NetWeaver 6.40
mit generischen Werten pflegbar. Zur Aktivierung der Funktion wurde der neue Profilparame-
ter rsau/userselection eingeführt, der folgende Werte annehmen kann:
0 = generische Selektion ausgeschaltet
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 111
1 = generische Selektion eingeschaltet.
Es ist empfehlenswert von dieser Option Gebrauch zu machen, wenn Sie z.B. für die Organi-
sation Ihres Notfallbetriebes mehrere Notfallbenutzer einrichten wollen. Sie können damit die
Protokollierung der Benutzer NOTFALL1, NOTFALL2, NOTFALL3 durch die Konfigurati-
on eines gemeinsamen Filters für NOTFALL* erreichen. Gleiches gilt auch für mehrere in-
terne wie externe Basis-Administratoren.
Die Verwendung einer generischen Selektion ist ab SAP NetWeaver 6.40 möglich und für äl-
tere Releasestände steht sie für bestimmte Kernelpatches zur Verfügung. Hierbei sind die
technischen Anweisungen aus den SAP Hinweisen 574914 und 539404 zu beachten.
Die maximale Größe der Security Audit Log-Datei wird im Profilparameter
rsau/max_diskspace/local definiert (Defaultwert = 1 MB).
Das Security Audit Log sichert die Protokolle täglich in eine entsprechende Audit-Datei. SAP
empfiehlt, diese Dateien regelmäßig zu archivieren und die Originaldateien nach Bedarf zu
löschen (Transaktion SM18).
Durch eine höhere Anzahl von Filtern (Slots) kann es zu Problemen mit dem Speicher kom-
men. Siehe hierzu auch den SAP-Hinweis 664058.
Die Transaktion SM20/SM20N ermöglicht eine Auswertung der mit Hilfe des Security Audit
Logs erzeugten Protokolle.
System Log
Das SAP ERP protokolliert in Systemprotokollen (Syslog auf Anwendungsebene) unter-
schiedliche Fehlersituationen, wie z.B.
Anmeldeversuche, die zur Sperrung führen
abgebrochene Verarbeitungen
sonstige Probleme und Warnmeldungen
Nutzung der Replace Funktion im Debugger
Das Syslog ist über die Transaktion SM21 aufrufbar.
Wird das Syslog aufgerufen, kann man mit Hilfe der Suchfunktion v.a. über die Spalte Tcod
(Transaktionscode) nach auffälligen Aktivitäten bzw. Fehlern suchen. Hier sind aus daten-
schutzrechtlicher Sicht v.a. Transaktionen aus dem Bereich PA und PD zu nennen.
Aufgezeichnet werden die Ausführung des Programms RSUSR003: Prüfung der StandartUser
auf Passworte und das Ändern von Daten über die DEBUG-Funktion.
Syslog-Dateien sind in der Länge begrenzt und werden bei Erreichen der Maximallänge über-
schrieben. Das Syslog ist daher nur eingeschränkt anwendbar, um auffällige Systemaktivitä-
ten bzw. durchgeführte Verstöße gegen unterschiedliche Bestimmungen zu prüfen.
Es sollte deshalb eine Organisationsanweisung zur regelmäßigen Kontrolle der aufgeführten
Meldungen vorliegen, oder dem Syslog ein größerer Speicherplatz zugewiesen werden (SAP-
Hinweise 4063 und 548624).
Transaktionsprotokollierung STAD (CCMS)
SAP bietet die Möglichkeit, alle ablaufenden Aktivitäten transaktions- und benutzerabhängig
für die jeweils im Einsatz befindlichen Anwendungsserver über das CCMS (Computing Cen-
ter Management System) zu protokollieren. Für jeden Benutzer können statistische Daten auf
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 112
täglicher, wöchentlicher und monatlicher Basis erzeugt werden (Transaktion STAD bzw. Re-
port RSSTAT26).
Zur Anzeige der statistischen Daten bzgl. der Benutzer sind die SAP-Berechtigungsobjekte
S_TOOLS_EX (Feld AUTH, Wert S_TOOLS_EX_A) und S_ADMI_FCD (Feld
S_ADMI_FCD, Wert ST0R) erforderlich.
Sicherheitsverletzende Ereignisse können im CCMS auf der Rechenzentrumskonsole als
Alerts dargestellt werden.
Die Nutzung der Transaktion STAD und des Systemmonitors ST03N (der die Daten für die
STAD bereit stellt), sollte aus Datenschutzgründen restriktiv geregelt werden.
Workflowprotokollierung
Die Workflowkomponente (SAP Business Workflow) stellt Werkzeuge zur automatischen
Steuerung und Bearbeitung von anwendungsübergreifenden Abläufen bereit. Hierüber wird es
möglich, alle Bearbeitungsschritte der einzelnen Benutzer (Zeit der Ausführung, Dauer etc.)
automatisch zu protokollieren. Hierfür stehen z.B. die Transaktionen SWU9 (Workflow-Trace
anzeigen), SWI2_xxx (Workitem-Analyse) oder SWI5 (Workload-Analyse) zur Verfügung.
Wird die Workflowkomponente genutzt, stehen somit Auswertungsmöglichkeiten hinsichtlich
des Benutzerverhaltens (z.B. Anzahl der bearbeiteten Vorgänge) zur Verfügung. Die Nutzung
dieser Funktionalität und deren Vergabe ist aus Datenschutzgesichtspunkten einer kritischen
Betrachtung zu unterziehen.
Report-Protokollierung im HCM
Um nachgelagerte Kontrollen bzgl. des Starts von “kritischen” Personalwirtschaftsreports zu
implementieren, besteht die Möglichkeit, diese in die Tabelle T599R einzupflegen. Mit der
Transaktion SM30_V_T599R kann überprüft werden, welche Reports als protokollierungs-
pflichtig definiert sind.
Sofern über die vorgenommenen Einstellungen sichergestellt ist, dass Protokolle erzeugt wer-
den, kann eine Auswertung mit dem Report RPUPROTD durchgeführt werden.
Aus Datenschutzsicht empfehlenswert ist mindestens eine Protokollierung der Nutzung von
flexiblen Auswertungen, wie den Reports RPLICO10 und RPLMIT00, sowie die Nutzung der
flexiblen Fehlzeitenauswertungen, die RPTABSxx Reports.
AdHoc-Query Protokollierung zur Kontrolle der Zweckbindung
Das SAP System bietet die Möglichkeit, die Erstellung und die Ausführung von Queries für
ausgewählte InfoSets (Auswahl von Infotypen bzw. Datenfeldern aus der HCM-Datenbank)
protokollieren zu lassen. Die Protokollierung muss im Customizing mit der Transaktion
SPRO ( SAP Referenz-IMG) SAP NetWeaver Application Server SAP Query
Protokollierung Infosets für Protokollierung festlegen) aktiviert werden. An derselben Stel-
le werden die protokollierten Daten gelöscht.
Die Protokollsätze werden in die Tabelle AQPROT geschrieben, die durch entsprechende
Maßnahmen und Berechtigungen vor Manipulation geschützt werden muss.
Die Protokollierungsdaten können über die Benutzergruppe /SAPQUERY/SQ und das InfoSet
/SAPQUERY/QUERY_LOGGING (im globalen Arbeitsbereich) ausgewertet werden. Hilfs-
weise sind die Protokolle auch mit der Tabellenanzeige (SE17) anzeigbar.
Aus datenschutzrechtlicher Sicht empfiehlt sich die Nutzung der Queryprotokollierung, wenn
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 113
die Daten eines betreffenden Infosets von ihrem Charakter die Einhaltung der Zweckbin-
dung fraglich erscheinen lassen (etwa wenn das betreffende Infoset eine große Zahl von
Datenfeldern beinhaltet),
eine große Zahl von Nutzern Zugriff auf die Möglichkeit der Erstellung einer Query zu
dem in Frage stehenden Infoset haben,
datenschutzrechtlich gering qualifizierten Nutzern Zugriff auf die Möglichkeit der Erstel-
lung einer Query zu dem in Frage stehenden Infoset haben und/oder
in dem Infoset Daten besonderer Art gemäß § 3 Abs. 9 BDSG enthalten sind.
In diesen Fällen empfiehlt es sich im Rahmen interner Kontrollen die Einhaltung der Zweck-
bindung laufend zu kontrollieren.
Die Ad-HocQuery-Protokollierung wirkt nicht für die anderen SAP-Query Werkzeuge, näm-
lich SAP-Query und Quick-Viewer. Allerdings lassen sich die SAP-Standard-Queries über
die Funktionen des Ad-Hoc-Query aufrufen und damit protokollieren.
Risiken und zu ergreifende Maßnahmen
Bei den vorgenannten Punkten ist zwischen Auswertungen zu unterscheiden, die nachgelager-
te Kontrollen im Sinne eines Internen Kontroll Systems (IKS) oder aktivitätsbezogene Kon-
trollen und damit Leistungs- und Verhaltenskontrollen ermöglichen.
Wird die Workflowkomponente, z.T. das System Log oder das CCMS (STAD) genutzt, ste-
hen somit Auswertungsmöglichkeiten bzgl. des Benutzerverhaltens (z.B. Anzahl der bearbei-
teten Vorgänge etc.) zur Verfügung. Die Nutzung dieser Auswertungen kann über das Be-
rechtigungskonzept gezielt eingeschränkt werden. Diesbezüglich ist eine Prüfung der im je-
weiligen Unternehmen ausgeprägten Berechtigungen notwendig. Dazu bietet das Audit In-
formation System einen Ansatzpunkt.
Die Nutzung des Security Audit Log halten wir zur Nachvollziehbarkeit der von speziell ein-
gerichteten Notfallusern durchgeführten Aktivitäten zwangsläufig für geboten. Dieses Log
stellt eine aktive Komponente eines umfassenden Sicherheitsmanagements dar. Zu beachten
ist in diesem Zusammenhang, dass über die dargestellten technischen Maßnahmen hinausge-
hend organisatorische Rahmenbedingungen geschaffen werden müssen, über die die Verwal-
tung und die Zurücksetzung der Kennwörter der Notfalluser sowie die Archivierung und Kon-
trolle der erzeugten Protokolle sichergestellt ist.
4.2.1.10 Komplexe Suchhilfe
Im SAP ERP sind komplexe Suchwerkzeuge an verschiedenen Stellen verfügbar. In vielen
Modulen, wie z.B. dem HCM, stellen sie eigene Informationssysteme dar. Die angebotenen
Suchhilfen können über Customizingfunktionen eingeschränkt werden. Die Definition der
verwendeten Suchhilfen sollte im Projekt unter Hinzuziehung des DSB und ggf. der Arbeit-
nehmervertretung erfolgen.
TREX (Text Retrieval and Extraction Machine), Knowledge Management (KM) und Search
Engine Services (SES) stellen gemeinsam eine integrierte SAP-Suchtechnologie für die un-
ternehmensweite Suche in unstrukturierten wie strukturierten Daten zur Verfügung. Die SAP-
Suchtechnologie kann mit verschiedenen Werkzeugen (TREX-Monitor im KM, TREX-
Admin-Tool und TREX-Alert-Monitor) administriert und überwacht werden.
TREX ermöglich z.B. eine Volltextrecherche über alle Dokumente in einer elektronischen
Personalakte. SAP hat die TREX/SES-Funktionen z.B. in die in der e-Recruiting-Anwendung
(Administration Bewerber etc.) bereitgestellten Funktionen eingebaut. Die Nutzung dieser
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 114
Funktionalität ist aus Datenschutzgesichtspunkten, z.B. dem Grundsatz der Zweckbindung,
unbedingt einer kritischen Betrachtung zu unterziehen.
Freie Suche und Freie Abgrenzungen
SAP stellt bei der Administration von Infotypen eine „Freie Suche“ zur Verfügung, die auf al-
le Datenfelder aller Infotypen zugreifen kann aber keiner Protokollierung unterliegt.
Ebenfalls erlaubt die Funktion „Freie Abgrenzungen“ bei der Report-Selektion einen Zugriff
auf die Datenfelder aller Infotypen und stellt das Ergebnis, nämlich die ausgewählten Perso-
nalnummern für den Report bereit. Auch hier kann keine Protokollierung erfolgen.
Die Funktionen „Freie Suche“ und „Freie Abgrenzungen“ können abgeschaltet bzw. durch
Änderung des Suchknotens eingeschränkt und den betrieblichen Erforderlichkeiten angepasst
werden.
4.2.1.11 Zusammenfassung zentraler Risiken
Nachfolgend werden als Übersicht die in der Praxis am häufigsten auftretenden Risiken dar-
gestellt. Diese sind u.a.:
Fehlende Prüfbarkeit und Nachvollziehbarkeit durch
mangelnde Dokumentation der kundenspezifischen Anpassungen und Ausprägung des SAP-
Systems (Customizing, Tabellenpflege, Anwendungsentwicklung etc.),
vergessene Report-Berechtigungsgruppenpflege
nachlässige Handhabung des Berechtigungskonzeptes
nicht eingehaltene Empfehlungen (z.B. ausgeschaltetes Tabellenprotokoll, zugelassene Pro-
grammierung im Produktivsystem)
Umgehung des Zugriffschutzes des SAP ERP-Systems mittels der Programmiermöglich-
keiten (insbesondere Umgehung des Authority-Checks)
Umgehung des Zugriffschutzes des SAP ERP-Systems mittels RFC-fähiger Funktions-
bausteine, die aus einem ungeschützten SAP ERP-System oder von externen Programmen
heraus aufgerufen werden
Zweckentfremdung der Daten über Download und/oder XXL-Listviewer und anschlie-
ßende Verarbeitung zu datenschutzrechtlich nicht zulässigen Zwecken sowie unter unzu-
lässigen Bedingungen (wie etwa mangelnder Prüfbarkeit)
Verletzung der Datenschutzanforderungen durch ein nicht angepasstes Berechtigungskon-
zept
- Verletzung der Datenschutzanforderungen durch zusätzliche Auswertungsprogramme,
z.B.:
- nicht vereinbarte Nutzung eines flexiblen Auswertungssystems, ABAP Reports oder
Queries, d.h. Verarbeitung von Daten ohne Rechtsgrundlage
- Ändern/Erweitern des Funktionsumfangs von ursprünglich genehmigten Programmen
/ ABAPs/ Queries
- Zugriff der Programmierabteilung auf Echtdaten des Personalwesens
- die Programmierung eigener Auswertungen außerhalb einer datenschutzrechtlich ge-
prüften SAP-Anwendung, die auf SAP Daten zugreifen können (z.B. mittels Daten-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 115
bank-Tools, d.h. also auch unter Umgehung der Empfehlungen der SAP Sicherheits-
leitfäden)
Veränderung des Systemzustandes, z.B.:
- Vergabe von Zugriffsberechtigungen an einen unberechtigten Benutzer oder für unzu-
lässige Programme
- Einrichtung nicht vereinbarter Dateien, Datenfelder oder Werteverzeichnissen
- Aufbau unkontrollierter Schnittstellen der Personaldatenbanken zu anderen Systemen
(z.B. Controlling)
- Unsachgemäße Festlegung des Produktivsystem (z.B. Status „Änderbar“)
Missbrauch von Datenträgern, z.B.:
- Datenträger mit Personaldaten auf einer anderen SAP-Installation (z.B. einem Service-
rechenzentrum) oder auf anderen PCs auswerten
- Zweckentfremdung von Sicherheitskopien
- Vertuschen von Verstößen durch Änderung der Systemparameter, z.B. durch:
- Verfälschen der Protokolldateien, z.B. durch zeitweiliges Ausschalten der Tabellen-
protokollierung. Dies erfordert aber Zugriff auf die Profilparameter, die Tabellenakti-
vierungsberechtigung oder die Entwicklerberechtigung
- Umgehung von Zugriffsberechtigungsprüfung durch Ausschaltung der Berechtigungs-
prüfung
Umgehung von Zugriffsberechtigungsprüfung und Protokollierungssystemen durch PC-
Download und Auswertung außerhalb funktionierender Sicherheitsmechanismen.
4.3 Zusammenfassung der Prüfungshandlungen
Neben den oben angesprochenen SAP-Themen sind im Folgenden weitergehende Prüfungen
genannt, die allgemeiner die Thematik der Datenschutzanforderungen betreffen. Solche An-
forderungen sind in der allgemeinen Literatur (vgl. hierzu das Literaturverzeichnis im An-
hang) nachzulesen.
Die Umsetzung der erforderlichen organisatorisch-technischen Maßnahmen zur Gewährleis-
tung der Anforderungen des Datenschutzes sowie die Prüfbarkeit der Installation sind zwin-
gende Zulässigkeitsvoraussetzungen bei der Verarbeitung personenbezogener Daten. Die Prü-
fung, welche organisatorisch-technischen Maßnahmen jedoch erforderlich sind, muss indivi-
duell von jedem Anwenderbetrieb für jede Verarbeitungsform und jeden Verarbeitungszweck
bei der Planung eines Systems geprüft werden (vgl. hierzu die Ausführungen im Kapitel 1
dieses Leitfadens).
So vielfältig die Fragen einer Prüfung auch erscheinen mögen, es gibt einige Prüfungsfragen,
die an dieser Stelle nicht aufgegriffen worden sind. Hierzu zählt etwa die Prüfung des Prin-
zips der Datenvermeidung, der Datensparsamkeit, der Anonymisierung, der Pseudonymisie-
rung oder eine Prüfung der Zulässigkeit der Verarbeitung, z.B. der Übermittlung personenbe-
zogener Daten ins Ausland. Solche Fragen sollten in der Regel im Rahmen der Vorabkontrol-
le, also einer einmaligen Prüfung vor Inbetriebnahme eines betreffenden Systems erfolgen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 116
Zusammengefasst bedeutet dies: Was im Einzelfall erforderlich oder angemessen ist, damit
auch die Frage nach der Zulässigkeit bestimmter Verarbeitungsformen, ist in allen nachfol-
gend genannten Punkten von Fall zu Fall zu prüfen.
In diesem Kontext ist die folgende Checkliste nicht als Instrument für eine abschließende und
vollständige Prüfung, sondern als Orientierung zu verstehen. Die Verantwortung bleibt voll-
umfänglich bei der verantwortlichen Stelle.
In der Checkliste sind die verschiedenen Prüfungsfelder aus diesem Kapitel in drei Katego-
rien unterteilt, nämlich nach
Anforderungen an die Prüfbarkeit
gegebenenfalls gesonderten technisch-organisatorischen Anforderungen aus vorrangigen
Rechtsvorschriften z.B. aus Betriebs- oder Dienstvereinbarungen
Anforderungen der Datenschutzmaßnahmen gemäß § 9 BDSG und der Anlage zu § 9
BDSG
Die Fragen wurden so beschrieben, dass sich der gelegentliche Benutzer am System die ge-
wünschten Einsichten in das System verschaffen kann. Hierbei verweist die Darstellung
mehrfach auf das Audit Information System und seine Funktionen. Aus diesem Grund wird
empfohlen, sich die Dokumentation des Systemaudits bei der Vorbereitung der Prüfungen er-
gänzend zur Hilfe zu nehmen
4.3.1 Anforderungen an die Prüfbarkeit
4.3.1.1 JAVA-Stack aktiv ?
Prüfen sie mit den Reports RSPARAM bzw. RSPFPAR oder mit den Transaktionen RZ10
bzw. TU02 den Instanzparameter rdisp/j2ee_start:
Bei Wert: 0 ist der JAVA-Stack nicht aktiv und bedarf keiner weiteren Beachtung.
Bei Wert:1 ist der JAVA-Stack aktiv und die JAVA-Engine kann von entsprechenden Pro-
grammen gestartet und genutzt werden. In diesem Fall sind weitere Prüfungen erforderlich,
um das geforderte Datenschutz- und Sicherheitsniveau des Netweaver JAVA-Stacks sicherzu-
stellen. (Diese Prüfungen sind nicht Gegenstand dieser Checkliste bzw. des Datenschutzleit-
fadens SAP ERP 6.0 30.5.2008. )
Betrachten sie mit TU02 auch die Historie der Aktivierungs-Einstellung des JAVA-Stacks.
4.3.1.2 Hardware
Ist jeweils aktuell dokumentiert,
auf welchen Rechnern (Applikationsservern/Arbeitsstationen/Terminals usw.) SAP relevante
Datenverarbeitung (einschließlich der Daten die von SAP-Systemen abgegeben werden bzw.
für SAP-Systeme bereitgestellt werden z.B. Zeiterfassungssysteme) erfolgt?
auf welchen Rechnern die SAP Entwicklungs-, Qualitätssicherungs- und Produktivsysteme
laufen?
Stimmen diese Angaben mit dem SYSTEM --> STATUS und den Tabellen TSYST (Anzeige
über SM31, bzw. SE16) überein? / T000 und T001
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 117
mit welchem Betriebssystem diese Rechner betrieben werden?
vgl. SYSTEM --> STATUS in den verschiedenen Systemen.
um welche Rechnersysteme es sich handelt (ob etwa Windows-, UNIX-, IBM iSeries-
Rechner als Server verwendet werden, welche Client-Rechner in Betrieb sind)?
welche Netzwerkkomponenten (z.B. Router) eingesetzt werden?
wer für die Aufrechterhaltung des Rechnerbetriebs zuständig ist?
bestehen Service Level Agreements (SLA)? Mit welchen Vereinbarungen zum Themenbe-
reich Datenschutz wurden diese abgeschlossen?
Liegt eine aktuelle Netzübersicht in grafischer und/oder schriftlicher Form vor?
Liegt dafür eine aktuelle Konfigurationsübersicht und/oder eine Netzbeschreibung vor?
4.3.1.3 Betriebssystem und systemnahe Software
Ist dokumentiert,
welche Betriebssysteme (mit Angabe der Versionsnummer) eingesetzt werden? Vgl. mit ".ys"
im OK-Code oder SYSTEM --> STATUS in den verschiedenen Systemen
welche Datenbanksysteme oder Datenverwaltungssysteme (Angabe des Release-Standes) ge-
nutzt werden? Vgl. mit SYSTEM --> STATUS in den verschiedenen Systemen.
welches Netzwerkbetriebssystem gefahren wird?
welche Netzwerkdienste in der Server-Domain aktiv sind und welche deaktiviert wurden?
welche Router und Firewall-Systeme die SAP-Server Domain und das SAP-Netz von anderen
Netzen (insbesondere externen Netzen) abschotten?
Wird Netzwerkverschlüsselung eingesetzt und auf welchen Strecken? Wenn ja,
zwischen Applikationsservern
zwischen Applikationsservern und Clients
zwischen Applikationsservern und Druckern
welche Wartungszugänge, insbesondere für Fernwartung (Hard- oder Softwarewartung) vor-
gesehen sind?
werden bzw. welche SAP Verschlüsselungstechniken werden eingesetzt (SNC/SSF)? (SNC =
Secure Network Communication / SSF = Secure Store & Forward )
werden digitale Signaturen genutzt?
Welche Zugriffrechte sind (für wen) auf der SAP ERP Datenbank eingerichtet?
Besteht für die vergebenen Zugriffsrechte auf der Ebene der Betriebssysteme und der Netzwerk-
ebenen der betroffenen Server ein Benutzer- und Berechtigungskonzept in Bezug auf SAP-
Objekte?
Besteht außer für die Systemverwalter Zugriff auf die SAP ERP Tabellen und die SAP ERP Da-
tenbank von der Betriebssystemebene aus?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 118
Ist eine Datenbank-Query-Sprache auf der SAP ERP Datenbank im Einsatz?
Wenn ja, gefährden die Zwecke die Integrität und die Prüfbarkeit des SAP-Systems?
Wird diese Query-Sprache uneingeschränkt genutzt (z.B. auch für die Veränderung der Datenba-
sis)?
4.3.1.4 Programmiertechnik
Existieren verbindliche Programmrichtlinien?
Ist festgelegt,
1. welche Programmiersprachen außerhalb SAP verwendet werden und deren Programme auf
SAP zugreifen dürfen (z.B. SQL, JAVA...)?
2. welche Programmgeneratoren oder sonstige Software-Engineering-Werkzeuge in den SAP-
Systemen eingesetzt werden (ABAP Query, Report Writer, etc.)?
In welchen Systemen/Mandanten darf/kann programmiert / entwickelt werden?
1. Überprüfe die Einstellungen der Systemänderbarkeit (inkl.Aufzeichnungspflichtigkeit) in
Tabelle T000 der in Frage kommenden Systeme
2. Überprüfe die Einstellungen der Mandantenänderbarkeit (inkl.Aufzeichnungspflichtigkeit) in
Tabelle T000 der in Frage kommenden Systeme
3. Prüfe die vergebenen Berechtigungen für das Objekt S_DEVELOP mit Aktivität 01 (anle-
gen) und Aktivität 02 (ändern) sowie Objekttyp PROG
4. Überprüfe die vergebenen Entwicklerschlüssel für die in Frage kommenden Systeme / Man-
danten in der Tabelle DEVACCESS
In welchen Systemen/Mandanten dürfen/können Customizing-Einstellungen geändert werden?
1. Überprüfe die Mandanteneinstellungen in der Tabelle T000 in den in Frage kommenden Sys-
temen.
2. Prüfe die vergebenen Berechtigungen für das Objekt S_TABU_DIS Aktivität 02;
S_TABU_CLI „X“.
Ist das Verfahren für Änderung in den Produktivsystemen schriftlich festgelegt?
Wer hat welche Berechtigungen im Change and Transporting System (CTS)? Analysiere die
vergebenen Berechtigungen zum Berechtigungsobjekt S_TRANSPRT mit dem Benutzerinfor-
mationssystem SUIM Benutzer nach Berechtigungswert.
Gibt es Customizing-Aufträge und Programme ohne ausreichende Dokumentation und Bezeich-
nung?
Wird bei allen wesentlichen Änderungen und bei Releasewechsel auf die Vollständigkeit der
Dokumentation und die Revisionsfähigkeit geachtet?
Analysiere insbesondere mit dem CTS Informationssystem (Transaktion SE03) die transportier-
ten eigenen Objekte auf eine ausreichende und verständliche Dokumentation.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 119
Werden geschützte personenbezogene Daten aus dem produktiven SAP ERP-System in ein Data
Warehouse ((SAP Business Warehouse) SAP NetWeaver Business Intelligence) zur allgemeinen
Auswertung übertragen?
Programmtest und Test von Customizing-Einstellungen
Werden für das Qualitätssicherungssystem eigene Testdaten erstellt (z.B. mit Anonymisie-
rungstools)?
Werden Testläufe mit den eigens dafür erstellten Testdaten oder mit Produktivdaten durchge-
führt?
Analysiere die Daten stichprobenartig (z.B. durch Aufruf der entsprechenden Stamm- und Be-
wegungsdaten in den betroffenen Modulen) im Qualitätssicherungssystem / -mandanten im Qua-
litätssicherungssystem.
Ist sichergestellt, dass ein Testlauf mit echten Daten grundsätzlich nur in folgenden Fällen
durchgeführt wird:
mit den Berechtigungen die die Tester auch im Produktivsystem haben? Analysiere die Be-
rechtigungen im Qualitätssicherungs(test-)system mit dem Benutzerinformationssystem
(Aufruf über die Transaktion: SUIM).
im Rahmen des 4-Augenprinzips, sofern über die Rolle der Testenden (Programmierer, Qua-
litätssicherer, Fachabteilung) hinaus weitergehende Rechte auf die Daten vergeben werden
(z.B. alle Rechte für den Personalchef)?
unter der Beteiligung der Fachabteilung, die Eigner der Daten ist?
Ist eine sichere Vernichtung des nicht anonymisierten Testmaterials mit Ausnahme der zu do-
kumentierenden Testdaten gewährleistet?
Werden Testhilfen (etwa die SAP eigenen Computer-Aided Test-Tools (CATT)) eingesetzt und
von wem?
Analysiere die Benutzerstammsätze mit dem Benutzerinformationssystem (Aufruf über die
Transaktion: SUIM).
Ist festgelegt,
welche Daten für den Programmtest und welche für den Abschlusstest in den der Produktion
vorgelagerten Systemen und Mandanten verwendet werden dürfen? Prüfe die SOLL-
Vorgaben (eines notwendigen Testkonzeptes) auf Übereinstimmung mit den durchgeführten
Transporten ins Qualitätssicherungssystem (Testsystem) und dessen Mandanten (Transaktion
SE03 oder mit der AIS-Funktion Report RSWBO040).
wer geeignete Testdaten zur Verfügung stellt?
welche Anonymisierungsverfahren verwendet werden?
ob anonymisierte Testdaten verwendet werden müssen?
welche Stelle für die Formulierung des Programmier- und Änderungsauftrages zuständig ist?
Wird beim Programmtest und für die Programmpflege Fremdpersonal eingesetzt?
Gibt es spezielle Vorgaben einzuhaltender Sicherheitsmaßnahmen (etwa zum Schutz der Doku-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 120
mentation vor Überschreiben bei Mandantenkopien)?
Untersuche insbesondere die Belieferungs- und Transportwege und die vergebenen Berechtigun-
gen in den zu Tests verwendeten Mandanten.
Programmdokumentation
Wird die maschinell unterstützte Dokumentation bei der Entwicklung eigener Objekte genutzt?
Inspiziere mit der Transaktion SA38 (SPRINGEN --> DOKUMENTATION) oder ggf. mit SE38
die Z- und Y-Reports sowie mit der SE11 die Tabellendokumentation der T9-, Z- und Y-
Tabellen.
Beschreibt die Dokumentation,
welches Programm welche anderen Programme aufruft
welche Tabellen verarbeitet werden
welche Berechtigungsprüfungen vorgesehen sind
welche zulässigen Eingabewerte es gibt
aus welchen weiteren Komponenten das Objekt besteht?
Ist sichergestellt, dass durch restriktive Vergabe der Berechtigungen (Objekt S_TRANSPRT)
und durch entsprechende Einstellungen der Systeme und Mandanten alle Programmänderungen
und Änderungen an programmsteuernden Tabellen aufgezeichnet werden?
Ist durch eine entsprechende Rechtevergabe sichergestellt, dass die Dokumentation geschützt ist?
Welche Personen haben Entwicklerrechte (z.B.: S_CTS_DEVELO), wer Verwalterrechte
(z.B.:das Profil S_CTS_ALL) und wer Projektleiterrechte (z.B. das Profil S_CTS_PROJEC)
bzw. vergleichbare Rechte? Untersuche das Berechtigungsobjekt S_TRANSPRT mit SUIM
(Standardberechtigungen).
Oder kann ggf. jede/r auf Grund von Generalberechtigungen (etwa mit dem Profil SAP_ALL) al-
le Transporte freigeben und durchführen?
Werden die Dateien des CTS auf Betriebssystemebene ausreichend geschützt?
Prüfe die Zugriffsberechtigungen zu den SAP-Transportdateien im Verzeichnis \usr\sap\trans auf
Betriebssystemebene.
Ist für jedes Programm eine Programmdokumentation erstellt worden, die zumindest folgende
Teile enthalten sollte?
Anwendungsbereiche des Programms
Programmgliederung und -beschreibung
Prozessbeschreibungen (soweit erforderlich)
Datenflussplan
Beschreibung der Prüftabellen, bzw. des View-Aufbaus
Beschreibung der Integrationsbeziehungen
Dynpros, verwendete Formulare
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 121
Programmliste der neuesten Fassung
Protokoll des Abschlusstests und Unterzeichnung des Abnahmeprotokolls
verwendete Testdaten
Bedienungsanleitung für die Arbeitsvorbereitung und -nachbehandlung
Rufe dazu die Onlinedokumentation (SE38 ANZEIGE Dokumentation) auf, bzw. untersuche die
Programmakten der selbst entwickelten Programme.
Gibt es ein Bedienungshandbuch, das alle für die Benutzung des angepassten SAP ERP-Systems
notwendigen Hinweise enthält und die Bedeutung der geforderten Eingabedaten ausreichend er-
klärt?
Prüfe die Benutzer-, bzw. Anwender- und Schulungshandbücher.
Sind die Systeme (Tabelle TSYST) und Mandanten (Tabelle T000) und die Belieferungswege
(Tabellen TASYS), Konsolidierungswege (Tabelle TWSYS) sowie Transportschichten (Tabelle
DEVL) ausreichend dokumentiert und ist deren Einhaltung durch Systemeinstellungen (z.B. Sys-
temänderbarkeit in Tabelle T000) gewährleistet?
Sind die RFC-Schnittstellen ausreichend dokumentiert und gesichert?
Welche Berechtigungen sind für das Objekt S_RFC vergeben, und welche Benutzer haben
diese Berechtigungen?
Prüfe mit dem Report RSPARAM die entsprechend relevanten Systemparameter.
Systemparameter: auth/rfc_authority_check = 1 oder 2,
Systemparameter: snc/accept_insecure_r3int_rfc = ungleich 1
Systemparameter: snc/accept_insecure_rfc = 0
Analysiere das RFC-Protokoll mit Transaktion SM58 auf undokumentierte RFC-Aufrufe
Sind die ALE-Schnittstellen ausreichend dokumentiert und gesichert?
Welche Berechtigungen sind für die Objekte B_ALE* vergeben, und welche Benutzer haben
diese Berechtigungen?
Sind alle ALE-Benutzer als CPIC-Benutzer deklariert?
Sind die Batch-Input-Schnittstellen ausreichend dokumentiert und gesichert?
Welche Batch-Input Benutzer sind für welche Aufgaben angelegt?
Untersuche die Benutzerstämme mit SUIM auf unbekannte Batch-Input Benutzer
Freigabeverfahren
Ist zur Freigabe von neuen oder geänderten Funktionen zur Verarbeitung geschützter personen-
bezogener Daten ein organisatorisches Verfahren entwickelt und durch entsprechende Zugriffs-
rechte im CTS abgesichert worden? Sind die Belange der Datensicherung und des Datenschutzes
dabei ausreichend berücksichtigt worden? Prüfe, ob organisatorische Regelungen durch die ent-
sprechende Vergabe der Berechtigungen zum Objekt S_TRANSPRT umgesetzt wurden.
Ist dokumentiert,
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 122
wer für die datenschutzrechtliche Programmfreigabe, und hier insbesondere für die Prüfung
der Rechtsgrundlagen, die notwendigen technisch-organisatorischen Maßnahmen (speziell
Berechtigungsprüfungen) und die Dokumentation, verantwortlich ist?
Prüfe dies gegen die Vergabe der Berechtigungen zum Objekt S_TRANSPRT.
wer die Daten für den Programmablauf zur Verfügung stellt?
Wird ein Freigabeprotokoll angefertigt?
Prüfe die dokumentierenden Texte zu Aufträgen mit Transaktion SE03, Report RSWBOSSR.
Ist die Übernahme freigegebener Objekte in den Produktionsmandanten festgelegt?
Prüfe die Vergabe der Berechtigungen zum Objekt S_TRANSPRT: Wer kann entsprechende
Transporte durchführen?
Sind die Testroutinen und -abläufe für die Überprüfung der ordnungsgemäßen Verfahrensinstal-
lation und des fehlerfreien Programmablaufs ausreichend dokumentiert?
Anwendungsentwicklung
Ist dokumentiert,
welche Personen für die ABAP/Query/Ad hoc Query -Entwicklung zuständig sind?
welche Personen für die Releasewechsel und Wartung des SAP-Verfahrens zuständig sind?
welche Teile des Verfahrens mit eigenem Personal und welche im Auftrag von einem Soft-
warehaus entwickelt wurden?
Ist ausreichend dokumentiert,
seit wann sich die einzelnen SAP-Verfahren im Produktionseinsatz befinden?
wann das Verfahren wesentliche Änderungen erfahren hat, wann neue Module, Funktionen
und Anwendungen hinzugekommen sind?
wer für die Anordnung von Verfahrensänderungen zuständig ist?
wie solche Änderungen im Regelfall und wie im Notfall abzulaufen haben?
Liegt eine Zusammenstellung und Kurzbeschreibung der zu unterschiedlichen Zeitpunkten ein-
gesetzten SAP-Verfahren vor?
Benutzerservice/Systemadministration
Ist festgelegt,
wer für den Rechnerbetrieb verantwortlich ist (Systemverwaltung)?
wer für die Verfahrensadministration verantwortlich ist?
Prüfe die Angaben gegen die Benutzerberechtigungen über das Benutzerinformationssystem
(Transaktion SUIM).
Werden die Aktionen der Systemverwaltung ausreichend protokolliert?
Ist festgelegt, wer wann dieses Protokoll zu welchen Zwecken auswerten soll/darf?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 123
Prüfe die Verwendung und Auswertung der Protokolle.
Werden alle Verfahrensänderungen ausreichend (im CTS und durch Änderungsprotokolle) ma-
schinell protokolliert?
Prüfe insbesondere die Aufzeichnungspflichtigkeit in den betreffenden Mandanten (Tabelle
T000) sowie die Vollständigkeit der Protokollierung im CTS mit SE03.
Sind diese Protokolle ausreichend manipulationssicher aufbewahrt?
Prüfe die vergebenen Zugriffsrechte auf die Dateien des CTS, wer die Protokolle auf SAP- und
auf Betriebssystemebene (SCD0 Aktion 06) archivieren und/oder löschen kann.
Ist außerhalb des SAP ERP-Systems dokumentiert,
welche Personen die Berechtigungsverwaltung (Angabe der Personen) einschließt?
auf welche Daten der Benutzerservice Zugriff hat, bzw. wer einen Trace (Transaktion
ST01) durchführen kann?
welche Daten bei solchen Zugriffen protokolliert werden?
Überprüfe diese Angaben über das Benutzerinformationssystem (Transaktion SUIM)..
Werden Störungen und entsprechende Maßnahmen zu deren Behebung in einem Störungslog-
buch außerhalb des SAP ERP Systems revisionsfähig (Datum, Uhrzeit) dokumentiert?
Ist der Ablauf der Benutzer- und Berechtigungsverwaltung (Einrichten, Kennwortvergabe, Rech-
tevergabe, Löschen/Ändern bei Versetzung oder Ausscheiden) ausreichend dokumentiert und
ausreichend zeitnah organisiert?
Werden hierfür die Möglichkeiten des SAP ERP HCM (Personaladministration und Organisati-
onsmanagement) genutzt?
Rechenzentrumsbetrieb
Ist die Systemkonsole in einem gesicherten Bereich untergebracht und gegen missbräuchliche
Benutzung gesichert?
Kann das Tagesdatum geändert werden?
Gibt es Zwangsprotokollierungen für alle Änderungen am DV-System und an den Systempro-
grammen, auf denen die SAP-Software läuft?
Wird das Systemverwalterkennwort für die betreffenden Systeme regelmäßig geändert und in
geeigneter Weise geheim gehalten?
Ist Accounting
im SAP ERP-System im Einsatz?
außerhalb von SAP ERP im Einsatz?
Ist das Verfahren der Auswertung geregelt?
Gibt es ein RZ-Berichtswesen zur Kontrolle der festgestellten Sicherheitsverstöße?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 124
Werden diese Berichte von der Revision und/oder dem Datenschutzbeauftragten regelmäßig
ausgewertet?
Liegen Operatoranweisungen vor, wie auf Systemmeldungen zu reagieren ist (Bedienungsanlei-
tung)?
Findet eine Schichtprotokollierung statt und gibt es Regelungen für
Führung?
Auswertung?
Aufbewahrung?
Gibt es Aufbewahrungs- und Löschungsfristen für die RZ-Dokumentationen (Protokolle,
Schichtpläne u.ä.)?
Liegen Dokumentationen für den Notfall vor?
Sind für etwaige Benutzung einer Ausweichanlage die Abläufe geklärt?
Ist die Vergabe von Benutzerberechtigungen für die etwaige Benutzung einer Ausweichanlage
geregelt?
Sind im Rechnerraum in der Regel zwei Mitarbeiter je Schicht anwesend?
Gibt es in sensiblen Bereichen eine Funktionssteuerung?
4.3.1.5 Verfahrensanwendung
Prüfe zusätzlich die Maßnahmen zur Datensicherung gemäß § 9 BDSG im Abschnitt 3 der
Checklisten.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 125
4.3.2 Prüfung spezieller Regelungen aus vorrangigen
Rechtsvorschriften (z.B. aus geltenden Betriebsvereinbarungen zu
organisatorisch-technischen Maßnahmen)
Anhang zu Benutzerberechtigungen
Ist der Anhang aktuell geführt?
Wird der Anhang manuell oder mit Hilfe des Systems geführt?
Bei maschineller Erzeugung Kontrolle durch die entsprechende Funktion:
mit dem Report RSUSR002 Übersicht über die Benutzer und die zugeordneten Profile
mit dem Report RSUSR002 Auswertung für ein bestimmtes Objekt, wenn nur Benutzer mit
Zugriff auf bestimmte Berechtigungsobjekte gesucht werden
mit dem Report RSUSR003 Prüfung der Standardbenutzer
mit dem Report RSUSR008, RSUSR009 und RSUSR008_009_NEW Prüfung der Benutzer
mit kritischen Berechtigungen.
Vergleiche - abhängig von der Form der Anlage - die Auflistung mit dem aktuellen Stand der
Tabellen (mittels SA38 und den entsprechenden RSUSR* Reports).
Vergleiche ggf. den SOLL- und den IST-Stand der Anhänge in Form von PC-Dateien im .dbf
oder .xls Format durch eine entsprechende MS Query SQL Abfrage.
Vergleiche auch die weitergehenden Prüfungen zum Zugriffsschutz unter der Rubrik 'Prüfung
von Datenschutz- und Datensicherungsmaßnahmen gem. § 9 BDSG'.
4.3.3 Prüfung der Datenschutzmaßnahmen gemäß § 9 BDSG und der
Anlage
Bei der Prüfung der getroffenen technischen und organisatorischen Maßnahmen nach § 9
BDSG und seiner Anlage folgt die Darstellung der Systematik der Anlagennummerierung -
auch wenn dies im Einzelfall zur doppelten Nennung einzelner Prüfungspunkte führt. Es wer-
den auch hier wieder nur die Punkte weiter ausgeführt, die einen Bezug zu der SAP-Software
haben. Hierbei fallen allen voran die Punkte “Zutrittskontrolle", “Auftragskontrolle" und
“Verfügbarkeitskontrolle” ins Auge, die Themenkomplexe ansprechen, die mit anderen tech-
nischen oder organisatorischen Mitteln außerhalb des SAP ERP-Systems gelöst werden müs-
sen. Soweit es sinnvoll erschien, sind hier auch für solche Fälle einige Prüfungen aufgenom-
men.
4.3.3.1 Nummer 1: Zutrittskontrolle
Laut Nummer 1 ist 'Unbefugten der Zutritt zu Datenverarbeitungssystemen, mit denen perso-
nenbezogene Daten verarbeitet oder genutzt werden, zu verwehren (Zutrittskontrolle)'.
Diese Anforderung ist innerhalb SAP ERP nicht einschlägig.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 126
4.3.3.2 Nummer 2: Zugangskontrolle
Bei Nummer 2 der Anlage zu § 9 BDSG ist 'zu verhindern, dass Datenverarbeitungsanlagen
durch Unbefugte genutzt werden können (Zugangskontrolle)'
Authentifizierung
Ist gewährleistet, dass jeder SAP-Benutzer über einen eigenen Benutzerstammsatz verfügt?
Prüfe stichprobenartig, ob alle Anwender in den betroffenen Abteilungen in der Liste der zu-
gelassenen Benutzer (Report RSUSR002) stehen.
Untersuche weiter mit RSUSR002 die Liste der Benutzer auf ggf. angelegte personenunab-
hängige Benutzer (z.B. 'Lager' oder 'Personalsachbearbeiter' oder ähnliche)
Existieren Vorgaben für sichere Kennwörter? Sind die verbotenen Kennwörter in der Ta-
belle USR40 ausreichend gepflegt?
Welche Einstellungen zur Mindestkennwortlänge gibt es?
Untersuche mit RSPARAM den Systemparameter login/min_password_lng
Welche Einstellungen zum Aufbau von Kennwörtern gibt es?
Untersuche mit RSPARAM die Systemparameter:
- Minimale Anzahl von Zahlen - login/min_password_digits
- Minimale Anzahl von Buchstaben - login/min_password_letters
- Minimale Anzahl von Sonderzeichen - login/min_password_specials
Wird der Kennwortwechsel maschinell erzwungen?
Welche Einstellungen zum Kennwortwechsel gibt es? (Empfehlung 60 oder 90 Tage). Un-
tersuche mit RSPARAM den Systemparameter login/password_expiration_time
Erfolgt ein Abbruch der Verbindung nach einer bestimmten Anzahl von Fehlversuchen
(3)?
Untersuche mit RSPARAM den Systemparameter login/fail_to_session_end und log-
in/fail_to_user_lock
Ist das automatische Anlegen des Benutzers SAP* ausgeschaltet?
Untersuche mit RSPARAM den Systemparameter login/no_automatic_user_sapstar
(Wert sollte bei abgeschaltetem Benutzer 1 sein).
Werden inaktive Benutzer automatisch abgemeldet?
Untersuche mit RSPARAM den Systemparameter rdisp/gui_auto_logout (Achtung! Ge-
tätigte Eingaben werden nicht gespeichert, daher ist der Einsatz eines Bildschirmschoners
mit automatischer Aktivierung nach Zeitlimit und Kennwortschutz zu bevorzugen)
Wurden die Standardbenutzer SAP*, DDIC, SAPCPIC und EARLYWATCH ausreichend
geschützt?
Prüfe mit dem Report RSUSR003 den Status der Benutzerstammsätze (Kennwortände-
rung, -qualität / Sperrung)
Prüfe mit dem Report RSUSR200 inaktive User mit Initialkennworten.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 127
Erfolgt eine Authentifikation am Frontend-Rechner durch andere Mittel, z.B. Chipkarte, wenn
der Rechner in mehr oder weniger öffentlich zugänglichen Räumen steht?
Kann der Benutzer seinen Bildschirm, ohne sich abzumelden, über die Software sperren?
(Einsatz Bildschirmschoner)
Ist der Kennwortschutz (für Bildschirmschoner) insbesondere an Arbeitsplätzen mit Publi-
kumsverkehr, auf der Ebene des PC-Betriebssystems aktiviert?
Erfolgt eine Dunkelschaltung des Bildschirms bei längerer Inaktivität? Nach wie vielen Minu-
ten?
Prüfe insbesondere öffentlich zugängliche Rechner.
Wird für die Gewährleistung der Datensicherheit auf den PCs eine spezielle Sicherheitssoft-
ware eingesetzt?
Wird von der Verschlüsselung der SAP-Daten mittels Secure Store & Forward (SSF) oder
Secure Network Communications (SNC - data privacy protection) Gebrauch gemacht und
in Bezug auf welche Daten?
Ist sichergestellt, dass geschützte Daten aus dem SAP ERP-System nicht per Download
und/oder Mail auf ungeschützte Systeme abfließen können?
Prüfe die vergebenen Berechtigungen zu dem Objekt S_GUI.
Prüfe den Zugang zu Programmen mit XXL-Listviewer-Funktionen.
Ist sichergestellt, dass zur Fernwartung (im Mandant 066) nur zugegriffen werden kann, wenn
die Fernwartung ausdrücklich angefordert wird?
Sind die eingerichteten Benutzerstammsätze für den Rest der Zeit gesperrt?
Wird während der Fernwartung die Protokollierung aktiviert (Transaktion SM19, Security
Audit Log)?
Wird das Protokoll anschließend ausgewertet?
Wer besitzt Berechtigungen zum Anlegen von RFC Verbindungen (SM59) um sich über den
Mandanten 066 hinaus Zugang zu Daten zu ermöglichen?
4.3.3.3 Nummer 3: Zugriffskontrolle
Es ist 3. zu gewährleisten, dass die zur Benutzung eines Datenverarbeitungssystems Berech-
tigten ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen kön-
nen, und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speiche-
rung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können (Zugriffskon-
trolle).
Zugriffsschutz
Ist eine Zuordnung Benutzer/Funktionen/Befugnisse vorhanden?
Gibt es neben der Benutzerübersicht im Report RSUSR002 eine Tabelle, die auf aktuellem Stand
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 128
Benutzer und Berechtigungen ausweist?
Ist die Benutzergruppe im Berechtigungsstammsatz differenziert, d.h. abteilungsweise oder kos-
tenstellenbezogen gepflegt?
Analysiere mit RSUSR002 Anzeige aller Benutzer 'Andere Sicht' die Benutzergruppen.
Sind die umfassenden Generalberechtigungen (wie das Profil SAP_ALL) auf besonders geschütz-
te (und zwangsprotokollierte) Notfallbenutzer beschränkt?
Bestehen für diese umfassenden Generalberechtigungen ergänzende Schutzmassnahmen (z.B.
durch organisatorische Regelungen)
Prüfe mit dem Benutzerinformationssystem (Transaktion SUIM), wer das Profil SAP_ALL und
vergleichbar umfassende Berechtigungen besitzt.
Prüfe, ob die Zwangsprotokollierung für diese Benutzer in der Produktivumgebung über das
Security Audit Log eingeschaltet ist (mit Transaktion SM19).
Untersuche die Protokolle in der Produktivumgebung auf Zuteilung und Nutzung der weitgehen-
den Berechtigungen (z.B. SAP_ALL)
Sind die sensiblen Tabellen durch Tabellenberechtigungen ausreichend geschützt?
Analysiere die Tabellenklassen in der Tabelle TDDAT für das Berechtigungsobjekt
S_TABU_DIS.
Prüfe anschließend mit dem Benutzerinformationssystem (Transaktion SUIM) --> Benutzer nach
komplexen Selektionskriterien für das Berechtigungsobjekt S_TABU_DIS, welche Benutzer auf
diese Tabellenklassen Zugriff haben.
Sind die sensiblen Programme durch Reportklassen ausreichend geschützt?
Analysiere die zugeordneten Reportklassen mit dem Report RSCSAUTH für die zu schützenden
Reports.
Sind alternativ für den Endbenutzer nur Reportbäume zugänglich?
Analysiere, ob die Benutzung der Transaktion SA38 geschützt ist.
Sind alle zu schützenden Transaktionen entweder gesperrt (Ansicht mit dem Report RSAU-
DITC) oder mit einer Berechtigungsprüfung gegen das Objekt S_TCODE versehen?
Analysiere die Tabelle TSTC oder benutze die Transaktion SE93.
Ist gegebenenfalls die Berechtigungsprüfung in kritischen Transaktionen vom Umfang verrin-
gert?
Prüfe den Systemparameter auth/no_check_in_some_cases.
Hat er den Wert Y, prüfe, welche Prüfungen mit SU24 ausgeschaltet/verändert wurden.
Ist das 4-Augenprinzip bei der Pflege und Aktivierung von Berechtigungen und Profilen sowie
bei der Benutzerpflege gewährleistet?
Prüfe die Organisation und die Einstellungen zu den Objekten:
S_USER_GRP (hier insbesondere: Wer kann welche Benutzergruppen pflegen?)
S_USER_PRO
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 129
S_USER_AUT
S_USER_ADM
S_USER_SAS
Ist die Betriebssystemebene für die Anwender gesperrt?
Untersuche den Systemparameter rdisp/call_system mit dem Report RSPARAM.
Wenn der Wert nicht 0 ist, kann aus SAP ERP heraus auf das Betriebssystem zugegriffen werden.
Besteht eine organisatorische Trennung zwischen Anwendungsentwicklung, Arbeitsvorbereitung
und -nachhandlung, Dateneingabe, Operating und Archivverwaltung? Analysiere insbesondere
die Vergabe der Berechtigungen zum Objekt S_TRANSPRT.
War der Programmschalter ORGPD zur Nutzung der strukturellen Berechtigung jederzeit ent-
sprechend der Festlegungen eingestellt?
Prüfe die Nutzung des Programmschalters für strukturelle Berechtigungen ORGPD im Modul
HCM in Tabelle T77S0 (Berechtigungshauptschalter HR).
Prüfe die Nutzung der Programmschalters für kontextsensitive BerechtigungenINCON und
XXCON im Modul HCM in Tabelle T77S0 (Berechtigungshauptschalter HR) Gruppe AUTSW.
Ist das Berechtigungskonzept vor der Inbetriebnahme ausreichend getestet worden?
Bedieneroberfläche
Werden die Benutzer durch einen entsprechenden Eintrag im Benutzerstammsatz gezielt auf das
für sie einschlägige Untermenü durchgeschaltet?
Rufe den Report RSUSR002 auf, erzeuge eine Liste aller in Frage kommenden Benutzer, drücke
zweimal den Knopf 'andere Sicht' und untersuche die Spalte 'Startmenü'.
Ist durch das Customizing gewährleistet, dass der Anwender nur Zugriff auf solche Daten hat, die
er zur Erfüllung seiner Aufgaben benötigt?
Prüfe die Masken (DYNPROs) im Zugriff einzelner Benutzer z.B. Mit PA20 in der Personalwirt-
schaft.
Prüfe die Customizing-Einstellungen zu dem Stichwort: "Anpassung der Oberflächen".
Protokollierung
Werden auf Betriebssystemebene die Benutzerdaten protokolliert, so dass erkennbar ist, wer
wann außerhalb von SAP ERP mit welchen Ressourcen wie auf welche SAP ERP-Daten zu-
gegriffen hat?
Ist im Rahmen des Security Audit Log die Protokollierung des Downloads eingeschaltet?
Wird die Protokollierung des Downloads mit der SM20 unter Datenschutzgesichtspunkten regel-
mäßig ausgewertet?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 130
4.3.3.4 Nummer 4: Weitergabekontrolle
Es ist 4. zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung
oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen,
kopiert, verändert oder entfernt werden können, und dass überprüft und festgestellt werden
kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur
Datenübertragung vorgesehen ist (Weitergabekontrolle).
Zugriffsschutz
Ist eine Zuordnung
im Berechtigungsstammsatz differenziert, d.h. abteilungsweise oder kostenstellenbezogen Benut-
zer/Funktionen/Befugnisse vorhanden?
Gibt es neben der Benutzerübersicht im RSUSR002 eine Tabelle, die auf aktuellem Stand Benut-
zer und Berechtigungen ausweist?
Ist die Benutzergruppe gepflegt? Analysiere mit RSUSR002 >Anzeige aller Benutzer> 'Andere
Sicht' die Benutzergruppen.
Datenübermittlung
Wird eine Übersicht/Liste über diejenigen Stellen geführt, an die Datenübermittlungen pro-
grammgesteuert stattfinden können?
Prüfe über das Audit Information System in SYSTEM AUDIT: SYSTEM KONFIGURATION
SYSTEM und KOMMUNIKATIONSARTEN R/3 für RFC, CPIC und ALE Verbindungen.
Prüfe ggf. auch Zugriffsberechtigungen von rechtlich Dritten (z.B. externe Beratungsunterneh-
men/System-Wartung)
Das System Audit ist ein Bestandteil der SAP ERP Basis Component. Damit ist seine Funktionali-
tät auch in mySAP™ Systemen, in denen die Komponente Financials nicht aktiv ist (zum Beispiel
reine Human Capital Management-Systeme), verfügbar.
Informationen über Systemeinstellungen, Berechtigungen sowie über das Tabellenwerk sind we-
sentliche Elemente des Audit Information System - System Audit.
Gibt es eine aktuelle Dokumentation der für die selbsttätige Übermittlung einzusetzenden Pro-
gramme gemäß § 10 Abs. 4 BDSG außerhalb des SAP ERP?
Erfolgt außerhalb von SAP ERP eine revisionssichere Protokollierung der programmgesteuerten
Übermittlungen durch Aufzeichnung von
übermittelnder Benutzer
Empfänger
Daten
Datum
Uhrzeit?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 131
Erfolgt eine Verschlüsselung der Daten durch Secure Network Communicatins (SNC) oder Secure
Store & Forward (SSF) auf den Übertragungsstrecken?
Wenn ja, zwischen welchen Instanzen?
SAP GUI und Applikationsserver
Applikationsserver und Drucker?
etc.
Outputmanagement
Ist dokumentiert, welche Ausgaben auf PCs umgelenkt werden können?
Prüfe die Vergabe der Berechtigungen zum Objekt S_GUI (Aktivität = 61).
Erfolgt die Ausgabe der Druckerzeugnisse bei Personaldatenverarbeitung benutzerbezogen?
Sind die Druckerberechtigungen abteilungs- bzw. benutzerbezogen eingerichtet, oder kann es pas-
sieren, dass Ausdrucke versehentlich in ganz fremden Abteilungen/Standorten/Ländern gemacht
werden?
(arbeitsplatznahes Drucken)
Prüfe die Berechtigungen zum Objekt S_SPO_DEV und deren Zuordnung zu Benutzern über Rol-
len oder Profile
Prüfen Sie die Möglichkeit zum PDF-Drucken und zur Ablage und zum Versand der erzeugten
Dokumente.
4.3.3.5 Nummer 5: Eingabekontrolle
Es ist 5. zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, ob und
von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verändert o-
der entfernt worden sind (Eingabekontrolle).
Protokolleinstellungen
Welche Benutzer werden automatisch protokolliert?
Überprüfe die Definition der Protokollierungsfilter im Security Audit Log über die Transaktion
SM19,
Prüfe mit dem Report RSPARAM ob die Grundeinstellung für die Protokollierung über den
Systemparameter rsau/enable = 1 gegeben ist
Ist die Protokollierung der Tabellenänderungen eingeschaltet?
Prüfe den Systemparameter rec/client mit Report RSPARAM sowie RECCLIENT der TP-
Parameter.
Ist für alle wichtigen Tabellenänderungen (vor allem System- und Schlüsseltabellen) die Proto-
kollierung über die technischen Eigenschaften der Tabellen “eingeschaltet“?
Stelle alle in Frage kommenden Tabellen zusammen und prüfe die Einstellungen (Transaktion
SCU3 oder Anzeige der Tabelle DD09L)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 132
Erfolgt eine revisionssichere Protokollierung der Eingabe in einer Protokolldatei für alle rele-
vanten SAP-Objekte durch Aufzeichnung von
eingebendem Benutzer (Name)
Datum und Uhrzeit der Erfassung
erfassten Daten
Prüfe die eingestellten Änderungsbelege für alle in Frage kommenden Objekte mit Transaktion
SCD0.
Besitzt niemand die Berechtigung zum Löschen der Änderungsbelege?
Prüfe mit dem Benutzerinformationssystem (Transaktion: SUIM), bzw. über den Report
RSUSR002, welcher Benutzer zu dem Objekt S_SCD0 die Aktivität 06 besitzt.
Protokollauswertungen
Welche Protokollierung ist im SAP ERP aktiviert?
Welche Protokollierungsergebnisse des SAP ERP-Systems werden von wem und zu welchen
Zwecken genutzt?
Ist das Security Audit Log aktiviert und wozu? Prüfe Transaktion SM19 und den Parameter
rsau/enable (Wert muss 1 sein) mit dem Report RSPARAM.
Untersuche das Systemlog auf Falschanmeldungen (Transaktion SM21).
Wird ggf. die Tagesstatistik (Transaktion STAD) genutzt? Vgl. den Parameter stat/level = 1.
Welche Anwendungsprotokolle sind eingeschaltet? Vgl. die Konfiguration SLG0 für die
SLG1 (Transaktionen).
Wer kann die Protokollierung der Workflows (der Transaktionen SWI2_xxx und SWI5) nut-
zen und zu welchem Zweck?
Für welche betriebswirtschaftlichen Objekte ist die Protokollierung eingeschaltet? (Transakti-
on SCD0)
Tabellenprotokollierung (Transaktion SCU3)
Untersuche die benutzer-, profil- und berechtigungsbezogenen Änderungsprotokolle (Trans-
aktion SUIM)
4.3.3.6 Nummer 6: Auftragskontrolle
Es ist 6. zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden,
nur entsprechend den Weisungen des Auftraggebers verarbeitet werden können (Auftrags-
kontrolle).
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 133
Zugriffsschutz
Ist eine Zuordnung Benutzer/Funktionen/Befugnisse beim Auftragnehmer vorhanden?
Gibt es neben der Benutzerübersicht im RSUSR002 eine Tabelle, die auf aktuellem Stand Benut-
zer und Berechtigungen beim Auftragnehmer ausweist?
Ist die Benutzergruppe der Benutzer beim Auftragnehmer im Berechtigungsstammsatz differen-
ziert, d.h. abteilungsweise oder funktionsbezogen gepflegt? Analysiere mit RSUSR002 Anzei-
ge aller Benutzer 'Andere Sicht' die Benutzergruppen.
Sind die Berechtigungen der Auftragnehmer auf ein Minimum beschränkt?
Ist sichergestellt, dass ausreichende Kontrollen die Risiken weitgehender Berechtigungen beim
Auftragnehmer abdecken?
4.3.3.7 Nummer 7: Verfügbarkeitskontrolle
Es ist 7. zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung oder
Verlust geschützt sind (Verfügbarkeitskontrolle).
Zugriffsschutz
Sind ausreichend regelmäßige Sicherungsläufe vorgesehen?
Ist auf der Ebene des Betriebssystems sichergestellt, dass keine versehentliche Löschung der
SAP-Dateien erfolgen kann? Sind die Zugriffsrechte auf Betriebssystemebene entsprechend der
SAP-Empfehlungen restriktiv vergeben? Werden die vorhandenen Zugriffsrechte regelmäßig
überprüft?
Ist auf der Ebene des Datenbanksystems sichergestellt, dass keine versehentliche Löschung der
SAP-Dateien erfolgen kann? Sind die Zugriffsrechte auf Datenbankebene entsprechend der SAP-
Empfehlungen restriktiv vergeben? Werden die vorhandenen Zugriffsrechte regelmäßig über-
prüft?
Ist der Zugang zu den archivierten Daten und Datenträgern ausreichend geschützt? Prüfen Sie die
entsprechende Organisation.
Ist sichergestellt, dass die Datenverarbeitungsanlagen und die Datenträger ausreichend gegen
Einwirkungen von Feuer, Wasser, Stromausfall und -schwankungen geschützt sind?
Ist sichergestellt, dass die Datenträger ausreichend gegen Einwirkungen von Materialermüdung
geschützt sind? Prüfen Sie, ob es ausreichende Stichproben gibt.
4.3.3.8 Nummer 8: Gewährleistung der Zweckbindung
Es ist 8. zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verar-
beitet werden können.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 134
Zugriffsschutz
Ist auf der Ebene des Zugriffsschutzes eine ausreichend strikte Zuordnung Benut-
zer/Funktionen/Befugnisse zu zulässigen Zwecken vorhanden?
Prüfe für einzelne Benutzergruppen die Zugänglichkeit
der Programmbibliothek
weiterer Funktionalitäten wie ABAP Query und Ad-hoc Query
der Programmierwerkzeuge
der Administrationsfunktionen
des ABAP-Listviewers in Auswertungsprogrammen für personenbezogene Daten
insbesondere der Protokolle und Änderungsbelege
Sonstige Maßnahmen
Ist auf der Ebene der einzelnen SAP ERP-Systeme, Mandanten und Buchungskreise eine ausrei-
chende Abgrenzung der Benutzer/Berechtigungen nach ihren Funktionen/Befugnisse vorhanden?
Sind die verbleibenden Risiken durch entsprechende Schulung der Benutzer in den Fachabteilun-
gen, der Programmierung und der Systemverwaltung abgedeckt?
4.3.3.9 Sonstige Prüfungen
Der Einleitungssatz der Anlage zu § 9 BDSG fordert weiter, 'die innerbehördliche oder inner-
betriebliche Organisation so zu gestalten, dass sie den besonderen Anforderungen des Daten-
schutzes gerecht wird‘. Diese Anforderung sollte durch folgende Untersuchungen abgeprüft
werden:
Allgemeine Richtlinien
Existieren Richtlinien für die Datensicherheit (allgemein oder speziell für das DV-Verfahren) und
sind diese auf einem aktuellen Stand?
Werden diese Richtlinien allen Beteiligten in geeigneter Weise bekannt gemacht?
Gibt es Auswertungen nach Sicherheitsverstößen?
Welche Protokolle sind von wem?
Ist durch das Verfahren sichergestellt, dass Mängel an den technisch-organisatorischen Maßnah-
men oder Datenschutzverstöße umgehend an den betrieblichen Datenschutzbeauftragten weiter-
geleitet werden und mit diesem zusammen Abhilfe geschaffen wird?
Wurde eine Risiko- und Schwachstellenanalyse durchgeführt?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 135
Zugriffsverwaltung und Protokollauswertungen
Werden die Zugriffsberechtigungen eines ausscheidenden oder zu versetzenden Benutzers sofort
gelöscht? Gibt es ggf. einen automatisch ablaufenden Workflow zum Löschen eines Benutzers?
Ist die maschinelle Verwaltung und Pflege der Benutzerstammsätze, Berechtigungen, Profile und
ggf. Rollen ausreichend und zeitnah geregelt?
Prüfe das Berechtigungsrahmenkonzept und die organisatorische Abwicklung der Benutzeradmi-
nistration sowie die Pflege von Profilen, Berechtigungen und Rollen.
Wird dabei auf die Revisionsfähigkeit der Zugriffsberechtigungen geachtet?
Wird durch das interne Kontrollsystem regelmäßig die Einhaltung des Berechtigungskonzepts
geprüft? Wie häufig finden solche Untersuchungen statt?
Gibt es Sanktionen für erkannte Missbräuche und Missbrauchsversuche?
Wird die Protokollierung der Benutzer nach Anmeldedatum und Kennwortänderung (Report
RSUSR006), regelmäßig überprüft?
Ist die Weitergabe der Druckerausgaben an die Anwender geregelt, sofern diese keinen Arbeits-
platzdrucker haben?
Sind die Berechtigungen, auf Drucker zuzugreifen, ausreichend beschränkt?
Ist das Sicherungsverfahren auf Datenbankebene schriftlich dokumentiert?
Wurde beachtet, dass die Sicherungsdateien zu schützen sind, etwa durch ein Kennwort oder
Freigabedatum?
Werden die eingerichteten Schutzmaßnahmen regelmäßig einem eingehenden Test unterzogen,
um festzustellen, ob sie noch den gewünschten Schutzzweck erfüllen?
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 136
5 Auftragsdatenverarbeitung und
konzerninterner Datenaustausch
Im Kapitel 5 wird auf unterschiedliche Formen der Auftragsdatenverarbeitung eingegangen,
z.B. die Vergabe einfacher oder operativer Aufgaben an ein Shared Service Center (intern o-
der extern), die Schaffung globaler Prozesse mit einer gesellschaftsübergreifenden Verarbei-
tung personenbezogener Daten oder die Nutzung externer Dienstleister (klassisches Outsour-
cing).
Es muss im Konzern/Unternehmensverbund klar definiert sein, wer ‚Herr der Daten’ ist, denn
nach dem BDSG muss jede rechtlich selbständige Einheit (Legal Entity, also jedes selbstän-
dige Unternehmen des Konzerns) als verantwortliche Stelle, beispielsweise bei einem Aus-
kunftsbegehren des Betroffenen Auskunft geben können über den Datenfluss, die -kategorien
und die unterschiedlichen zugriffsberechtigten Personenkreise.
Seit der Novellierung des § 11 BDSG in 2009 hat sich bei einer Auftragsdatenverarbeitung
der Auftraggeber „vor Beginn der Datenverarbeitung und sodann regelmäßig von der Einhal-
tung der beim Auftragnehmer getroffenen technischen und organisatorischen Maßnahmen zu
überzeugen. Das Ergebnis ist zu dokumentieren.“
Die Einhaltung der seitdem stark formalisierten Auftragsgestaltung sowie der Kontrollpflich-
ten sind bußgeldbewährt.
5.1 Abgrenzungen beim Thema Outsourcing und Datenschutz
Grundsätzlich ist zwischen internem und externem Outsourcing zu unterscheiden. Beim inter-
nen Outsourcing wird die Datenverarbeitung von einer rechtlich unselbständigen Abteilung
innerhalb der verantwortlichen Stelle übernommen. Es liegt aus Sicht des BDSG also DV für
eigene Zwecke vor. Beim externen Outsourcing hingegen findet die Erhebung, Verarbeitung
und/oder Nutzung der personenbezogenen Daten des Betroffenen bei einer anderen rechtlich
eigenständigen Stelle statt. Es ist hier anhand des konkreten Einzelfalles zu untersuchen, ob
dies sich noch im Rahmen einer Auftragsdatenverarbeitung im Sinne des § 11 BDSG bewegt
oder ob der Outsourcingnehmer die personenbezogenen Daten des Betroffenen im Rahmen
einer Übermittlung zur eigenständigen Erhebung, Verarbeitung bzw. Nutzung (Funktions-
übertragung) erhält.
Als Beispiele für die Auslagerung von Dienstleistungen sind zu nennen:
Auslagerung der System-/Netzwerkadministration und des Rechnerbetriebs an ein anderes
(Konzern-)Unternehmen im Rahmen eines Service Vertrages
Auslagerung der Systemwartung und –pflege an ein anderes Unternehmen (z.B. (Fern-)
Wartung durch SAP im Rahmen des Softwarepflegevertrags)
Auslagerung von Aufgaben der Systemadministration bzw. des Rechnerbetriebs an ver-
schiedene Unternehmen
Wahrnehmung von Aufgaben zum Umgang mit personenbezogenen Daten durch externe
Dienstleistungszentren (Shared-Service-Center, Call Center)
Übertragung der Bereitstellung von E-Business-/Internet-Diensten an einen Service Pro-
vider
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 137
Verlagerung von Dienstleistungen ins Ausland (EU/EWR/Drittländer)
Cloud-Dienste (z.B. Success Factors)
Zur Abgrenzung der Begriffe Auftragsdatenverarbeitung und Funktionsübertragung:
Die Auftragsdatenverarbeitung ist dadurch gekennzeichnet, dass Auftraggeber und Auftrag-
nehmer - und dies gilt auch für zwei Konzernunternehmen - voneinander rechtlich unabhän-
gige und selbständige Unternehmen sind. Es gilt aber die Privilegierung, dass Auftraggeber
und Auftragnehmer rechtlich einheitlich als eine einzige verantwortliche Stelle gesehen wer-
den (vgl. § 3 Abs. 8 BDSG). Dies resultiert daraus, dass der Auftragnehmer dem Auftragge-
ber lediglich bei der Verlagerung von Verfahren oder Verfahrensschritten weisungsgebunde-
ne Unterstützung leistet. Datenerhebung, -verarbeitung oder -nutzung werden hierbei ledig-
lich in ihrer Hilfsfunktion für die Erfüllung der Aufgaben und Geschäftszwecke der verant-
wortlichen Stelle ausgelagert.
Rechtlich anders behandelt werden soll der Fall, wenn der Auftragnehmer - im Falle des Out-
sourcings als Outsourcingnehmer - mehr als nur weisungsgebundene Funktionen wahrnimmt.
Dies ist dann der Fall, wenn dem Outsourcingnehmer daneben weitere Aufgaben oder Funkti-
onen mit eigenen Entscheidungskompetenzen in Bezug auf die genutzten personenbezogenen
Daten übertragen werden. Durch die Übertragung dieser Aufgaben und Funktionen ändert
sich der Charakter der datenschutzrechtlichen Rechtsbeziehung. Die in diesem Zusammen-
hang verwendeten Daten dienen dann nicht mehr dem Geschäftszweck, diese im Auftrag für
den Outsourcinggeber gemäß seiner Weisungen zu verarbeiten, sondern dazu, dass der Out-
sourcingnehmer eine bestimmte vertraglich geschuldete Leistung in eigener Verantwortlich-
keit erarbeiten und erbringen möchte, zu deren Erfüllung er diese Daten benötigt. In diesem
Fall wird eine ganze Aufgabe an den Outsourcingnehmer übertragen, die er eigenverantwort-
lich wahrnimmt. Es wird also der Auftrag zur Erbringung einer Leistung erteilt, deren Be-
standteil auch die Erhebung, Verarbeitung oder Nutzung personenbezogener Daten ist, die der
Outsourcinggeber zur Verfügung stellt. Man spricht hier von einer so genannten Funktions-
übertragung.32
Die Abgrenzung von Auftragsdatenverarbeitung und Funktionsübertragung ist insbesondere
bei der Verlagerung von Aufgaben in Shared Service Center oder Call Center anhand der
oben genannten Kriterien im Einzelfall vorzunehmen.
Soweit die Shared Service Center oder Call Center nach definierten Weisungen, Checklisten,
Entscheidungsbäumen oder im Bereich einfacher Sachbearbeitungen arbeiten, spricht dies für
die Auftragsdatenverarbeitung. Erhält der Dienstleister allerdings im Rahmen der übernom-
menen Aufgabe eigene Datenherrschaft, z. B. dadurch, dass er eigenständig über die Weiter-
gabe von Daten oder Auswertungen im Konzern entscheiden kann, spricht dies für eine Funk-
tionsübertragung.
Wenn innerhalb eines Konzerns Outsourcing betrieben wird, sind die anzuwendenden
Rechtsvorschriften nicht anders zu interpretieren als bei einem Outsourcing zwischen sonsti-
gen fremden Unternehmen.
32 Zur Differenzierung zwischen „für die Verarbeitung Verantwortlicher“ und „Auftragsverarbeiter“ im
Hinblick auf die EU-Datenschutz-Richtlinie 95/46/EG s. WP 169: „Stellungnahme 1/2010 zu den
Begriffen „für die Verarbeitung Verantwortlicher“ und „Auftragsverarbeiter““ der ARTIKEL-29-
DATENSCHUTZGRUPPE, http://ec.europa.eu/justice/data-protection/article-
29/documentation/opinion-recommendation/index_en.htm#h2-2
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 138
5.2 Vertragsgestaltung zwischen Auftragnehmer und Auftraggeber
Im Folgenden werden - aufgrund der vielfältigen Fragestellungen in diesem Zusammenhang -
ausgewählte, grundsätzliche Punkte, die bei Überlegungen zur Vertragsgestaltung zwischen
Auftraggeber und Auftragnehmer zu beachten sind, behandelt. Ausführliches zu Vertragsge-
staltungen aus datenschutzrechtlicher Sicht kann in Fachbüchern nachgelesen werden (siehe
[Müthlein/Heck]33). Diesem Buch sind auch wesentliche Teile der in diesem Unterkapitel auf-
geführten Texte entnommen.
Mit der Novelle 2009 des § 11 BDSG sind insbesondere folgende Punkte im Auftrag zwi-
schen Auftraggeber und Auftragnehmer verbindlich zu regeln (zu den Änderungen der Novel-
le 2009 s. [GDD]34, zu weiteren Vorschlägen zu Vertragsmustern z. B. [Bitkom]35 und [ LfD
Hessen]36):
1. der Gegenstand und die Dauer des Auftrags,
2. der Umfang, die Art und der Zweck der vorgesehenen Erhebung, Verarbeitung oder Nut-
zung von Daten, die Art der Daten und der Kreis der Betroffenen,
3. die nach § 9 BDSG zu treffenden technischen und organisatorischen Maßnahmen,
4. die Berichtigung, Löschung und Sperrung von Daten,
5. die nach Absatz 4 bestehenden Pflichten des Auftragnehmers, insbesondere die von ihm
vorzunehmenden Kontrollen,
6. die etwaige Berechtigung zur Begründung von Unterauftragsverhältnissen,
7. die Kontrollrechte des Auftraggebers und die entsprechenden Duldungs- und Mitwir-
kungspflichten des Auftragnehmers,
8. mitzuteilende Verstöße des Auftragnehmers oder der bei ihm beschäftigten Personen ge-
gen Vorschriften zum Schutz personenbezogener Daten oder gegen die im Auftrag ge-
troffenen Festlegungen,
9. der Umfang der Weisungsbefugnisse, die sich der Auftraggeber gegenüber dem Auftrag-
nehmer vorbehält,
10. die Rückgabe überlassener Datenträger und die Löschung beim Auftragnehmer gespei-
cherter Daten nach Beendigung des Auftrags.
Dabei ist zu beachten, dass es im öffentlichen Bereich unterschiedliche Anforderungen der
Landesdatenschutzgesetze an die Vertragsgestaltung und Information bei der Auftragsdaten-
verarbeitung (im Sinne des § 11 BDSG) gibt. Die landesspezifischen Anforderungen sind für
öffentliche Stellen unbedingt zu beachten.
33 Th. Müthlein, J. Heck: Outsourcing und Datenschutz. Vertragsgestaltung aus datenschutzrechtlicher
Sicht, 3. neu überarb. Auflage, 2006, Datakontext Fachverlag
34 GDD, Neue Anforderungen an die Auftragsdatenverarbeitung nach § 11 BDSG, Sonderbeilage zu
RDV 5/2009 https://www.gdd.de/nachrichten/news/neues-gdd-muster-zur-
auftragsdatenverarbeitunggemas-a7-11-bdsg
35 http://www.bitkom.org/de/publikationen/38336_45940.aspx
36 http://www.datenschutz.hessen.de/mustervereinbarung_auftrag.html
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 139
Für besonders sensible Bereiche wie z.B. Krankenhäuser und Sozialversicherungsträger gel-
ten weitere, z.T. strengere Regelungen zum Outsourcing.
5.2.1 Pflichten des Auftraggebers und Auftragnehmers
Als „Herr der Daten” ist der Auftraggeber für die Einhaltung der Vorschriften des BDSG und
der anderen Vorschriften über den Datenschutz verantwortlich. Insbesondere ist er verant-
wortlich für die Zulässigkeit der Erhebung/Verarbeitung/Nutzung der Daten, für die Wahrung
der Rechte des Betroffenen, für die Haftung ihm gegenüber und für die Einhaltung der daten-
schutzrechtlichen Kontrolle. Der Auftragnehmer ist unter Prüfung der Eignung der angebote-
nen technischen und organisatorischen Maßnahmen sorgfältig auszuwählen (kaufmännische
Sorgfaltspflicht). Zwingend ist insbesondere37 die schriftliche Festlegung der Datenerhebung/-
verarbeitung/-nutzung, der technischen und organisatorischen Maßnahmen und etwaiger Un-
terauftragsverhältnisse. Es ist zu regeln, dass nur nach den Weisungen des Auftraggebers ver-
fahren wird.
Häufig wird man auf eine ausführliche Beschreibung der Datenerhebung/-verarbeitung/-
nutzung in einer Datenschutzvereinbarung mit dem Dienstleister verzichten können, da diese
Aspekte im Allgemeinen in den Service Level Agreements (SLA) definiert werden. Neben
den eigentlichen Leistungen beinhalten die SLAs häufig auch Sicherheitsaspekte, z. B. zur
Verfügbarkeit, Recovery oder Virenschutz. Insoweit reicht in der Datenschutzvereinbarung
ein Verweis auf die SLAs aus.
Der Auftraggeber hat die Pflicht, sich gemäß § 11 Abs. 1, 2 S. 3 BDSG von der Einhaltung
der technischen und organisatorischen Maßnahmen beim Auftragnehmer zu überzeugen. Die
Pflicht zur Überwachung erstreckt sich auf Betriebsabläufe, DV-Systeme und Räumlichkeiten
und unterliegt der Verschwiegenheitsverpflichtung bezüglich der erlangten Kenntnisse. Das
Ergebnis der Überprüfung, die schon vor Beginn der Datenverarbeitung zu erfolgen hat, ist zu
dokumentieren. Dabei sollte auch der Zeitrahmen für die Folgeuntersuchungen– abhängig von
der Sensitivität der verarbeiteten Daten- festgelegt werden. Zur Vereinfachung eines Nach-
weises sollte diese Unterlage dem Vertrag beigefügt werden.
Der Auftragnehmer muss intern sicherstellen, dass die Datenerhebung, -verarbeitung bzw. -
nutzung nur nach den festgelegten Weisungen erfolgt und die technischen und organisatori-
schen Maßnahmen (gemäß Anlage zu § 9 BDSG) eingehalten werden. Seine Mitarbeiter sind
auf das Datengeheimnis zu verpflichten.
Die Aufnahme der Verfahren, die auf den Auftragnehmer übertragen werden, ist weiterhin im
Verfahrensverzeichnis des Auftraggebers zu führen.
5.2.2 Umfang der Datenverarbeitung / Weisungen
Es ist zu vereinbaren, wie der Leistungsumfang sein soll, welche Datenbestände (Art, Um-
fang) vom Auftragnehmer verwalten und welche Verfahren darauf angewendet werden sollen
(ergibt sich i. d. R. aus dem SLA, s.o.). Da sich die konkrete Ausgestaltung des Auftragsver-
hältnisses ändern kann, ist es sinnvoll, solche Sachverhalte, die sich während der Vertrags-
37 s. im einzelnen Katalog des § 11 Abs. 2 BDSG
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 140
laufzeit ändern können (z. B. Wechsel von Personen) als Anlage zum SLA oder der Daten-
schutzvereinbarung festzulegen. Hierzu gehören z. B.:
Ort, Zeitpunkte und ggf. Reihenfolge der Erhebung, Verarbeitung bzw. Nutzung
Verfahren der Datenübertragung (Datenumfang, Leitungsweg, Verschlüsselung oder an-
dere Sicherungsmaßnahmen)
Berechtigung bzw. Pflicht zum Transport/Versand von Dateien, Datenträgern, Belegen
oder Listen
Sonderanforderungen an den Auftragnehmer (dazu berechtigte Personen des Auftragge-
bers, Ansprechpartner beim Auftragnehmer)
Festlegung der Zuständigkeit für die Archivierung (Aufbewahrungsfristen) und Löschung
(siehe auch Kapitel 2.3.4.5)
Die vertraglichen Vereinbarungen können daneben durch Weisungen im Einzelfall ergänzt
werden, z. B. in Form eines Auftragsscheins. Die Weisungen können dabei aber nicht über die
in den Verträgen festgelegten Rechte der Parteien hinausgehen und erlauben keine einseitige
Vertragsänderung.
Der Weisungsvorbehalt des BDSG bezieht sich auf den Umgang mit den Daten. Hierüber zu
bestimmen ist allein das Recht des Auftraggebers als „Herr der Daten“. Möchte der Auftrag-
geber weitergehende Weisungsrechte, sind diese gesondert auszuhandeln und vertraglich fest-
zulegen. Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 1 (Gegenstand und die Dauer
des Auftrags) und Nr. 2 BDSG (Umfang, die Art und der Zweck der vorgesehenen Erhebung,
Verarbeitung oder Nutzung von Daten, die Art der Daten und der Kreis der Betroffenen) gibt
das Bayerische Landesamt für Datenschutzaufsicht38 folgende Hinweise:
1. der Gegenstand und die Dauer des Auftrags,
Erläuterungen:
a) Gegenstand:
Wie Lohnberechnung, Adressenverarbeitung, Datenerhebung, DV-System-Betreuung,
Wartung/Fernwartung, Datenträgerentsorgung, usw.
b) Dauer:
einmalig, befristet bis ..., unbefristet mit Kündigungsmöglichkeit ab ...
2. der Umfang, die Art und der Zweck der vorgesehenen Erhebung, Verarbeitung oder Nut-
zung von Daten, die Art der Daten und der Kreis der Betroffenen,
Erläuterungen:
a) Umfang, Art, Zweck
Welche Leistungen sind im Einzelnen zu erbringen (Leistungsverzeichnis, Pflich-
tenheft).
Auftragsdatenverarbeitung nur im Inland, auch im EU-/EWR-Bereich oder auch in
Drittstaaten.
38 Auftragsdatenverarbeitung nach § 11 BDSG - Gesetzestext mit Erläuterungen; Stand: Mai 2013,
http://www.lda.bayern.de/lda/datenschutzaufsicht/lda_daten/auftragsdatenverarbeitung.pdf
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 141
Welche Leistungsphasen sollen außer Haus gegeben werden.
Vorübergehende oder dauernde Speicherung von Daten beim Dienstleister.
Welche Menge an Daten, Datensätzen, Datenträgern.
Umfang und Dauer einer Videoüberwachung.
b) Art der Daten
Personaldaten, Vertragsdaten/Bestelldaten, Werbedaten, Werbewidersprüche, Befra-
gungsergebnisse, Gesundheitsdaten, Videoaufzeichnungsdaten, Nutzungsdaten aus Te-
lemediendiensten oder Telekommunikationsdiensten, Telefongesprächsaufzeichnun-
gen, DV-Protokollierungsdaten,
c) Kreis der Betroffenen
Mitarbeiter, Stellenbewerber, Kunden, Interessenten, Lieferanten, Werbekontakte, Be-
sucher/Gäste, Passanten, Systemnutzer usw..
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 9 BDSG (der Umfang der Weisungsbe-
fugnisse, die sich der Auftraggeber gegenüber dem Auftragnehmer vorbehält) gibt das Baye-
rische Landesamt für Datenschutzaufsicht folgende Hinweise:
Erläuterungen:
Einzelweisungen zur Auftragserledigung, zu (zusätzlichen) Sicherheitsmaßnahmen,
zum Vorgehen bei Datenschutzverstößen
Weisungen zur Gestaltung bzw. Beendigung von Subunternehmerverhältnissen
Wer erteilt die Weisungen von Seiten des Auftraggebers und an wen sind die Weisun-
gen beim Dienstleister zu richten, in welcher Form erfolgen die Weisungen
usw..
5.2.3 Wer erteilt die Weisungen von Seiten des Auftraggebers und an
wen sind die Weisungen beim Dienstleister zu richten, in welcher
Form erfolgen die Technische und organisatorische Maßnahmen
Die technischen und organisatorischen Maßnahmen gemäß Anlage zu § 9 BDSG sind zur
Konkretisierung der Auswahlkriterien im schriftlichen Vertrag zu fixieren. Dadurch wird die
Transparenz der Erhebung, Verarbeitung bzw. Nutzung erhöht und eine Kontrolle erleichtert.
Eine solche Beschreibung dient auch dem Auftraggeber bei der Wahrnehmung seiner Kon-
trollrechte im Rahmen der Auftragskontrolle nach Nr. 6 der Anlage zu § 9 BDSG gegenüber
dem Auftragnehmer. Außerdem ist sie für den Auftraggeber im Falle der Beweisführung bei
der Haftung gegenüber dem Betroffenen hilfreich.
Die Maßnahmen sollten möglichst detailliert beschrieben werden, eine bloße Wiederholung
der Anlage zu § 9 BDSG reicht in keinem Fall aus. Es empfiehlt sich, diese Maßnahmen in
einer separaten Beschreibung zu dokumentieren, auf die im Vertrag hingewiesen wird. Dies
hat den Vorteil, dass bei Anpassungen der Maßnahmen an den neusten technischen Standard
nur die Anlage zum Vertrag geändert werden muss. Sicherheitsmaßnahmen, die bereits in den
SLAs beschrieben oder Gegenstand anerkannter gültiger Zertifikate wie ISO 2700x sind,
müssen hier nicht mehr wiederholt werden. Hier kann ein Verweis auf diese ausreichen.
Bei einem Outsourcing im Konzern mit bestehenden, festgeschriebenen Sicherheitsstandards
kann der Verweis auf diese ausreichen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 142
Für Details wird auf gesonderte Kapitel des Datenschutzleitfadens verwiesen.
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 3 BDSG (nach § 9 BDSG zu treffenden
technischen und organisatorischen Maßnahmen) gibt das Bayerische Landesamt für Daten-
schutzaufsicht folgende Hinweise:
Erläuterungen:
Vgl. im Einzelnen die Anlage zu § 9 Abs. 1 BDSG, wobei die Maßnahmen konkret sach-
verhaltsbezogen anzusprechen sind, z. B.
Festlegung der Transportwege und -verfahren für die Daten (manuell, elektronisch)
mit den dabei zu treffenden Sicherheitsmaßnahmen
Technische Vorsorgemaßnahmen zur Ausfallsicherheit (Ersatzrechenzentrum, Notfal-
leinrichtungen)
Verfahrensweise zur Trennung der Daten verschiedener Auftraggeber
Festlegungen zu Protokollierungen der Verarbeitungen beim Dienstleister und zu Si-
cherheits-speicherungen/Backup, sichere Lagerung solcher Datenträger
Festlegungen zur Aufbewahrung der zu entsorgenden Datenträger und der Sicher-
heitsstufe für die Löschung/Vernichtung
Regelungen zum Technik-Einsatz in Callcentern zum Schutz vor Datenunterschlagun-
gen.
5.2.4 Wahrung der Rechte der Betroffenen
Die Rechte des Betroffenen sind gegenüber dem Auftraggeber geltend zu machen. Das bedeu-
tet für das Auftragsverhältnis, dass der Auftraggeber auch alle notwendigen Informationen
und Mittel zur Wahrung dieser Rechte auf Benachrichtigung, Auskunft, Sperrung und Lö-
schung durch den Auftragnehmer erhalten muss. Es ist insoweit eine Unterstützungspflicht
vorzusehen.
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 4 BDSG (Berichtigung, Löschung und
Sperrung von Daten) gibt das Bayerische Landesamt für Datenschutzaufsicht in der Regie-
rung von Mittelfranken folgende Hinweise:
Erläuterungen:
Sperrung oder Löschung von Daten nach Abarbeitung von Einzel-Dienstleistungen,
sichere Löschverfahren
Mitwirkung des Dienstleisters bei Anträgen von Betroffenen an den Auftraggeber nach
§ 34 oder § 35 BDSG
5.2.5 Pflichten des Auftragnehmers nach § 11 Abs. 4 BDSG,
insbesondere die von ihm vorzunehmenden Kontrollen
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 5 BDSG (Pflichten des Auftragnehmers
nach § 11 Abs. 4 BDSG, insbesondere die von ihm vorzunehmenden Kontrollen) gibt das
Bayerische Landesamt für Datenschutzaufsicht folgende Hinweise:
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 143
Erläuterungen:
Aus § 11 Abs. 4 BDSG sind insoweit folgende Vorschriften relevant:
§ 5 BDSG – Datengeheimnis
§ 9 BDSG – Datensicherheit
§ 4f, § 4g BDSG – Datenschutzbeauftragter
Beispiele:
Verpflichtung der Beschäftigten des Dienstleisters auf das Datengeheimnis (ein-
schließlich entsprechender Belehrung) und Bestellung eines Datenschutzbeauftragten
beim Dienstleister, Name und Kontaktdaten des Datenschutzbeauftragten
Kontrollmaßnahmen beim Dienstleister (dessen Revision, dessen Datenschutzbeauf-
tragter, externe Auditierungen) zur Einhaltung des Datenschutzes und der Datensi-
cherheit, Prüfungsberichte
Kontrolle der Arbeitsergebnisse durch den Dienstleister
Kontrollen des Dienstleisters bei Subunternehmen
Datengeheimnis
Für die beim Auftragnehmer beschäftigten Personen gilt das Datengeheimnis gemäß § 5
BDSG, sofern sie bei der Erhebung, Verarbeitung bzw. Nutzung personenbezogener Daten in
einer der Phasen der Datenverarbeitung (Speicherung, Übermittlung, Veränderung, Löschung
oder Sperrung) oder bei der Nutzung tätig sind. Insbesondere die gesetzliche Verpflichtung
der sorgfältigen Auswahl des Auftragnehmers erfordert es, diesen Punkt sowie zusätzlich die
Regelung über die Wahrung von Geschäftsgeheimnissen im Vertrag zu regeln.
Datenschutzbeauftragter des Auftragnehmers
Um sich eines kompetenten Ansprechpartners für Datenschutzfragen im Unternehmen des
Auftragnehmers versichern zu können und hiermit ein Mittel zu haben, der Verantwortung als
”Herr der Daten” effektiv nachkommen zu können, sollte sich der Auftraggeber den Daten-
schutzbeauftragten des Auftragnehmers benennen lassen und sich das Recht über die Informa-
tion bei einem Wechsel des Datenschutzbeauftragten des Auftragnehmers zusichern lassen.
5.2.6 Kontrollen durch den Auftraggeber
Der Auftraggeber sollte sich zur Wahrnehmung seiner Kontrollpflichten vertraglich zusichern
lassen, welche Kontrollen er beim Auftragnehmer durchführen darf und mit welchem zeitli-
chen Vorlauf er solche Prüfungen anmelden muss. Außerdem sollte er sich – soweit erforder-
lich – vertraglich ein besonderes Einsichtsrecht beim Auftragnehmer durch eigene Mitarbeiter
(z.B. betrieblicher Datenschutzbeauftragter) oder beauftragte Dritte vorbehalten. Zu beachten
ist dabei, dass die Unterlassung der Prüfung vor Beginn der Verarbeitung bußgeldbewährt ist.
Zur Durchführung von Kontrollen kann sich der Auftraggeber auch Prüfberichte / Zertifikate
anderer Institutionen (z. B. durch Wirtschaftsprüfer / Aufsichtsbehörden / BSI) zu Eigen ma-
chen, soweit hierdurch sein Auftrag abgedeckt wird. Im Rahmen der Kontrolle sind Daten-
schutz- / Geheimhaltungsbedürfnisse des Auftragnehmers selbst und seiner anderen Kunden
zu beachten.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 144
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 7 BDSG (Kontrollrechte des Auftragge-
bers und die entsprechenden Duldungs- und Mitwirkungspflichten des Auftragnehmers) gibt
das Bayerische Landesamt für Datenschutzaufsicht folgende Hinweise:
Erläuterungen:
Umfang der Kontrollrechte, mit bzw. ohne Vorankündigung
Insoweit vom Dienstleister einzuräumende Duldungs- und Mitwirkungspflichten
Kontrollen vor Ort beim Dienstleister und auch bei eventuellen Subunternehmen
Wer führt welche Kontrollen von Seiten des Auftraggebers durch (Fachbereiche, Revi-
sion, Datenschutzbeauftragter, externe Sachverständige) und wer wirkt beim Dienst-
leister mit (Ansprechpartner)
Einsichtsrechte des Auftraggebers in DV-Protokolle, in Berichte der Revision und des
Datenschutzbeauftragten des Dienstleisters, in externe Audits für den Dienstleister
Mitlesen am Kontrollbildschirm bei Fernwartung
Kontrolle des Opt-In bei Werbemaßnahmen
Zutrittsrechte in Privatwohnungen bei Telearbeit/Heimarbeit
usw.
5.2.7 Unterauftragnehmer
Für einzelne Tätigkeitsbereiche der Erhebung, Verarbeitung bzw. Nutzung kann es notwendig
sein, Unterauftragnehmer einzuschalten (z. B. für den Transport, die Vernichtung, die Erfas-
sung oder Archivierung von Daten, die Delegation von Arbeiten auf Ausweichrechenzentren
in Fällen von Überkapazitäten oder Zusammenbrüchen). Auch hier sind die gleichen Voraus-
setzungen zu beachten wie für das Vertragsverhältnis im Falle der Auftragsdatenverarbeitung.
Im Vertrag zwischen Auftraggeber und Auftragnehmer sind die Unterauftragsverhältnisse
festzulegen, die entsprechenden Unterauftragnehmer genau zu bezeichnen und ihre Verant-
wortlichkeiten gegenüber denen des Auftragnehmers abzugrenzen.
Daneben sollte geregelt werden, ob dem Auftragnehmer grundsätzlich das Recht zugespro-
chen werden soll, künftige Unterauftragsverhältnisse abzuschließen. Sollte dies bejaht wer-
den, ist ein Verfahren zu bestimmen, dass den Bestimmungen des § 11 BDSG gerecht wird
und der Beteiligung des Auftraggebers unterliegt. Dazu ist festzulegen, dass der Vertrag mit
dem Unterauftragnehmer nach entsprechender Zustimmung auch Vertragsinhalt des Vertrages
zwischen Auftraggeber und Auftragnehmer wird. Ein Beispiel zur Einbindung von Unterauf-
tragnehmern bietet der EU Standardvertrag Controller – Prozessor. Hiernach kann ein Unter-
auftragnehmer durch Zeichnung des Vertrags zwischen Auftraggeber und Auftragnehmer die-
sem beitreten.39
39 BESCHLUSS DER KOMMISSION vom 5. Februar 2010 über Standardvertragsklauseln für die
Übermittlung personenbezogener Daten an Auftragsverarbeiter in Drittländern nach der Richtlinie 95/46/EG
des Europäischen Parlaments und des Rates (Bekannt gegeben unter Aktenzeichen K(2010) 593) im
Amtsblatt der Europäischen Union L 39/5 vom 12.02.2010 (de) s. dort im Vertragsmuster Klausel 11 Abs. 1
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 145
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 6 BDSG (etwaige Berechtigung zur Be-
gründung von Unterauftragsverhältnissen) gibt das Bayerische Landesamt für Datenschutz-
aufsicht folgende Hinweise:
Erläuterungen:
Subunternehmerbeauftragungen unzulässig bzw. unter welchen Bedingungen und nach
vorheriger Genehmigung durch den Auftraggeber zulässig, Namhaftmachung der
Subunternehmer
Subunternehmer nur aus dem Inland, auch aus dem EU-/EWR-Raum oder auch aus
Drittstaaten
Subunternehmer für welche Zwecke, in welchem Fall, in welchem Umfang, auch Sub-
Subunternehmer
5.2.8 Mitzuteilende Verstöße des Auftragnehmers
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 8 BDSG (mitzuteilende Verstöße des
Auftragnehmers oder der bei ihm beschäftigten Personen gegen Vorschriften zum Schutz per-
sonenbezogener Daten oder gegen die im Auftrag getroffenen Festlegungen) gibt das Bayeri-
sche Landesamt für Datenschutzaufsicht folgende Hinweise:
Erläuterungen:
Unterrichtung des Auftraggebers wegen dessen Verpflichtung aus § 42a BDSG (Informa-
tionspflicht bei unrechtmäßiger Kenntniserlangung von Daten).
Beispiele:
Welche Art, welcher Grad von Verstößen ist mitzuteilen (Fehlversendungen, verloren-
gegangene Datenträger, unterschlagene Daten, Datenhacking, Zugangsberechti-
gungs-/Passwortoffenlegungen usw.)
Nicht nur Verstöße des Auftragnehmers und seiner Beschäftigten, sondern auch
rechtswidrige Handlungen von Dritten (Subunternehmer, Hacker, Einbrecher)
5.2.9 Rückgabe überlassener Datenträger
Zu den Regelungsaspekten nach § 11 Abs. 2 S. 1 Nr. 10 BDSG (Rückgabe überlassener Da-
tenträger und die Löschung beim Auftragnehmer gespeicherter Daten nach Beendigung des
Auftrags) gibt das Bayerische Landesamt für Datenschutzaufsicht folgende Hinweise:
Erläuterungen:
Was ist wann zurückzugeben und was ist wie zu löschen bzw. zu vernichten (elektroni-
sche Datenträger, Papierunterlagen)
Weitere Verwendung von elektronischen Datenträgern
usw.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 146
5.2.10 Verarbeitung im Ausland
Bei einer Auftragsvergabe innerhalb der Europäischen Union (EU) / des Europäischen Wirt-
schaftsraums (EWR) wird hinsichtlich des Auftragnehmers keine Unterscheidung getroffen
zwischen einer Datenverarbeitung in Deutschland oder in einem Staat innerhalb der EU / des
EWR. Das heißt, hier sind die jeweiligen nationalen Regelungen des Auftraggebers für die
Beauftragung zu Grunde zu legen, also z. B. für einen deutschen Auftraggeber ein Auftrag
nach § 11 BDSG abzuschließen.
Bei der Vergabe in ein Drittland (also außerhalb der EU / des EWR) soll nach bisheriger Auf-
fassung, die bei der Novellierung des BDSG 2001 nicht neuerlich diskutiert wurde, immer der
Tatbestand der Datenübermittlung gegeben sein. Diese Auffassung wird jedoch weder durch
die EU-Datenschutzrichtlinie gefordert, noch durch nachfolgende Äußerungen der EU-
Kommission, z. B. durch Äußerungen in den FAQ zu Safe Harbor oder die Standardvertrags-
klauseln zur Auftragsdatenverarbeitung in Drittländern gestützt. Insofern ist auch eine Auf-
tragsdatenverarbeitung in Drittländern möglich (vgl. auch [Müthlein/Heck], S. 69 ff.; so auch
im Ergebnis die Aufsichtsbehörden für den Datenschutz, wenn auch mit einschränkenden
Anmerkungen, Beschluss der obersten Aufsichtsbehörden für den nicht-öffentlichen Bereich
am 19./20.4. 2007 in Hamburg, Hillenbrand-Beck in RDV 2007, S. 231 ff.).
Allerdings ist bei einer Auftragsvergabe an einen Dienstleister in einem Drittland neben einer
Vereinbarung nach § 11 BDSG unstreitig sicher zu stellen, dass sich durch die Verarbeitung
im Drittland das Datenschutzniveau für den Betroffenen nicht verschlechtert (s. § 4b, § 4c
BDSG).
Daher sind für eine entsprechende Auftragsvergabe u. a. folgende Punkte zu prüfen:
Es ist zu prüfen, ob eine positive oder negative Entscheidung der EU-Kommission in Be-
zug auf ein angemessenes Schutzniveau in diesem Drittland existiert. Dies gilt beispiels-
weise für die CH- Schweiz, CA- Kanada (Sonderfall Passenger Name Records = PNR-
Daten), AU- Australien (Sonderfall PNR-Daten) und AR- Argentinien. Weitere gelistete
Drittländer sind AD- Andorra, FO- Faeroe Islands, GG- Guernsey, IL- State of Israel, IM-
Isle of Man, JE- Jerseey, US- United States (Sonderfall PNR-Daten), NZ- New Zealand,
US- United States (Safe Harbor) und UY- Eastern Republic of Uruguay. Ggf. sind die
EU-Standard-Vertragsklauseln zugrunde zu legen.40
Durch individuelle Vertragsklauseln, genehmigt durch die Aufsichtsbehörde, können aus-
reichende Garantien festgelegt werden.
In § 4c BDSG sind Ausnahmen genannt, in denen Übertragungen in Drittländer auch dann
zulässig sind, wenn ein angemessenes Datenschutz-Niveau nicht gewährleistet ist. Bei-
spiele: Wenn der Betroffene eingewilligt hat oder ein Vertrag mit dem Betroffenen vor-
liegt. Der Hinweis auf die Zweckbindung ist auf jeden Fall zu geben.
In den USA können sich Unternehmen zur Beachtung der Safe-Harbor-Erklärung verpflich-
ten. Diese US-Firmen wollen durch Einhaltung dieser Vorschriften ein angemessenes Daten-
schutz-Niveau gewährleisten (www.export.gov/safeharbor). Dabei ist jedoch zu beachten,
dass durch den Beitritt des jeweiligen Auftragnehmers in den USA zum Safe Harbor-
40 BESCHLUSS DER KOMMISSION vom 5. Februar 2010 über Standardvertragsklauseln für die
Übermittlung personenbezogener Daten an Auftragsverarbeiter in Drittländern nach der Richtlinie
95/46/EG des Europäischen Parlaments und des Rates (Bekannt gegeben unter Aktenzeichen K(2010)
593) im Amtsblatt der Europäischen Union L 39/5 vom 12.02.2010 (de)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 147
Abkommen die Frage des angemessenen Schutzniveaus geklärt ist. Dennoch besteht weiter-
hin die Verpflichtung zum Abschluss einer Vereinbarung nach § 11 BDSG. Auch wenn dies
in der Praxis von US-Auftragnehmern häufig bestritten wird, ergibt sich dies nicht zu Letzt
aus FAQ 10 zu Safe Harbor41:
„FAQ 10 – Datenverarbeitung im Auftrag (Artikel 17 der Datenschutzrichtlinie)
F: Wenn Daten aus der EU in den USA im Auftrag verarbeitet werden sollen, muss
dafür ein Vertrag geschlossen werden unabhängig davon, ob der Auftragsverar-
beiter der Vereinbarung zum sicheren Hafen beigetreten ist oder nicht?
A: Ja. Werden Daten lediglich zur Verarbeitung im Auftrag übermittelt, muss der in
Europa für die Verarbeitung Verantwortliche darüber stets einen Vertrag
schließen, gleich ob die Verarbeitung in oder außerhalb der EU stattfindet. Der
Vertrag soll die Interessen des für die Verarbeitung Verantwortlichen schützen,
also der natürlichen oder juristischen Person, die Mittel und Zweck der Verar-
beitung bestimmt und die gegenüber der (den) betroffenen Person(en) voll ver-
antwortlich bleibt. Im Vertrag wird festgehalten, welche Arbeiten genau auszu-
führen sind und mit welchen Vorkehrungen für die Sicherheit der Daten zu sor-
gen ist.
Eine amerikanische Organisation, die der Vereinbarung zum „sicheren Hafen“
beigetreten ist und personenbezogene Daten aus der EU zur Verarbeitung im
Auftrag übermittelt bekommt, braucht bei diesen Daten die Grundsätze nicht an-
zuwenden, denn die Verantwortung dafür gegenüber der betroffenen Person
liegt nach den geltenden EU-Rechtsvorschriften (die strenger sein können als
die Grundsätze des „sicheren Hafens“) weiterhin bei dem für die Verarbeitung
Verantwortlichen.
Da die dem „sicheren Hafen“ angehörenden Organisationen einen angemesse-
nen Schutz gewähren, ist bei reinen Verarbeitungsverträgen mit dem „sicheren
Hafen“ angehörenden Organisationen keine vorherige Genehmigung erforder-
lich (oder die Genehmigung wird von dem jeweiligen Mitgliedstaat automatisch
erteilt), wie sie bei Verträgen mit Empfängern, die sich nicht auf die Grundsätze
des sicheren Hafens verpflichtet haben bzw. nicht auf andere Weise einen ange-
messenen Schutz bieten, erforderlich wäre.“
Die Regelung in § 11 Abs. 2 BDSG besagt, dass der Auftraggeber sich auch bei einem Auf-
tragnehmer im Ausland von der Einhaltung der getroffenen technischen und organisatorischen
Maßnahmen zu überzeugen hat.
Aufgrund der Besonderheiten des BDSG sind bei Nutzung von Vertragsmustern zur Auf-
tragsdatenverarbeitung insbesondere hinsichtlich der Benennung des Datenschutzbeauftragten
des Auftragnehmers und der Verpflichtung auf das Datengeheimnis nach § 5 BDSG Anpas-
sungen erforderlich. Statt des Datenschutzbeauftragten sollte der Auftragnehmer einen von
ihm zu bestimmenden Datenschutzverantwortlichen benennen.
41 Amtsblatt der Europäischen Gemeinschaften L 215/7 (de) vom 25.08.2000 ENTSCHEIDUNG DER
KOMMISSION vom 26. Juli 2000 gemäß der Richtlinie 95/46/EG des Europäischen Parlaments und
des Rates über die Angemessenheit des von den Grundsätzen des „sicheren Hafens“ und der
diesbezüglichen „Häufig gestellten Fragen“ (FAQ) gewährleisteten Schutzes, vorgelegt vom
Handelsministerium der USA (Bekannt gegeben unter Aktenzeichen K(2000) 2441)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 148
Die Verpflichtung nach § 5 BDSG kann durch eine vom BDSG losgelöste wortgleiche indivi-
duelle Verpflichtung der Mitarbeiter des Auftragnehmers ersetzt werden.
Als internationales Standardvertragsmuster für Auftragsverhältnisse außerhalb der EU/EWR
bietet sich die Verwendung des EU-Standardvertrags Controller-Processor42 an, der, wie eine
Aufstellung der Datenschutz-Aufsichtsbehörden zeigt43, auch die die erforderlichen Inhalte
einer Vereinbarung nach § 11 BDSG weitgehend abdeckt.
5.2.11 Wartung und Pflege
Per Definition sind gemäß § 11 Abs. 5 BDSG auf die Erbringung von Wartungsarbeiten oder
von vergleichbaren Unterstützungsdienstleitungen die Regelungen der Auftragsdatenverarbei-
tung im Sinne des Bundesdatenschutzgesetzes entsprechend anzuwenden, wenn dabei ein Zu-
griff auf personenbezogene Daten nicht ausgeschlossen werden kann.
Die Wartung und Pflege von Systemen kann beispielsweise folgende Tätigkeiten beinhalten:
Installation und Pflege von Netzwerken, Hardware und Software u.a. (Betriebssysteme,
Middleware, Anwendungen)
Parametrisieren von Software
Programmentwicklungen/-anpassungen/-umstellungen
Durchführung von Migrationen im Produktivsystem
Wartungsmaßnahmen können direkt vor Ort oder per Fernwartung durchgeführt werden.
Die Wartungsmaßnahmen beim Einsatz von SAP-Systemen können alle Ebenen des DV-
Einsatzes betreffen (z. B. Hardware, Betriebssystem- und Datenbankebene, Netzwerk). Dabei
können System- oder Anwendungsdaten betroffen sein, wobei personenbezogene Daten nur
bei letzteren von Bedeutung sind.
Dementsprechend ist für die Anwendung des BDSG bei Wartungstätigkeiten zu differenzie-
ren. Sie kommt regelmäßig nur dann in Betracht, wenn sich die Wartung auf Anwendungsda-
ten mit Personenbezug erstreckt.
In allen Fällen obliegt es dem Auftraggeber der Wartung selbst, die Tätigkeiten dem Einzel-
fall entsprechend freizugeben und zu kontrollieren.
Im Hinblick auf den Schutz personenbezogener Daten gegenüber unautorisierter Kenntnis-
nahme und/oder Weiterverwendung durch externe Systembetreuer/ Wartungspersonal sind
geeignete Sicherheitsmaßnahmen einzurichten:
Art und Umfang der Wartung sind schriftlich zu vereinbaren.
Das Wartungspersonal ist durch den Auftragnehmer schriftlich zur Verschwiegenheit zu
verpflichten (“Datengeheimnis”). Dieses gilt auch für Fernwartungsarbeiten (“Remote
Access”).
Personenbezogene Daten des Produktivsystems dürfen nicht auf andere Systeme herun-
tergeladen werden.
42 S.o.
43 http://www.lda.bayern.de/lda/datenschutzaufsicht/lda_daten/Abgleich_Standardvertragsklauseln-11.pdf
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 149
Bei Fernwartungsmaßnahmen via Remote Access ist das Prinzip der geringsten Rechte-
vergabe zu beachten. Zugriffe auf produktive Rechnersystem und Anwendungen sind im
Einzelfall zu autorisieren.
Entsprechende systemseitige Protokollierungen der durchgeführten Wartungsmaßnahmen
an Programmen und Datenbeständen sind vom Systemadministrator unverzüglich und in
zeitlicher Nähe zur Durchführung der Wartung sachgerecht vorzunehmen.
Personenbezogene Daten sind vor direkten Zugriffen des Wartungspersonals zu schützen
(z.B. über separate Partitionen); soweit im Notfall Zugriffe auf personenbezogene Daten
notwendig werden, hat der Systemadministrator geeignete Maßnahmen zur Überwachung
des (Fern-)Wartungspersonals zu veranlassen, letztlich bis hin zur persönlichen Anwesen-
heit.
Im Rahmen regelmäßiger, systematischer Wartungszugriffe über Remote Access, die häufig –
wie im Fall SAP – dazu dienen, Systemumgebungen zu aktualisieren, sind von der Sys-
temadministration des Auftraggebers Zugriffsrechte nur auf besondere Anfrage des Auftrag-
nehmers zu erteilen.
Die SAP hat ihre Abläufe in der Wartung von externen Auditoren beurteilen und zertifizieren
lassen. Kunden der SAP können die aktuellen Zertifikate und zusätzliche Informationen auf
dem SAP Service Marketplace abrufen:www.service.sap.com/certificates-> Security Certifi-
cates -> Datenschutz Managementsystem.
5.3 SAP-Fakten
5.3.1 Ausgangssituation
Die Verlagerung von DV-Funktionen an Dritte (sog. Auftragsdatenverarbeitung i.S.d. § 11
BDSG) ist ein - auch und gerade beim Einsatz von SAP - häufig anzutreffender Sonderfall
des BDSG. Im Sinne des BDSG werden Auftraggeber und Auftragnehmer zusammen als ver-
antwortliche Stelle betrachtet. Dabei ist der Auftragnehmer gegenüber dem Auftraggeber im
Hinblick auf die Erhebung, Verarbeitung und Nutzung der Daten weisungsgebunden. Die
technisch organisatorischen Maßnahmen dagegen unterliegen der vertraglichen Regelung.
Umgekehrt hat der Auftragnehmer den Auftraggeber darauf aufmerksam zu machen, wenn
dessen Weisungen nicht mit den Anforderungen des BDSG im Einklang stehen.
Bei SAP ERP handelt es sich um ein mandantenfähiges System mit mandanten- und bu-
chungskreisübergreifenden Funktionen, mit dessen Hilfe sowohl komplexe Konzernstrukturen
als auch mehrere, voneinander unabhängige Unternehmen in einem SAP-System nebeneinan-
der abgebildet werden.
Soweit die Unternehmen voneinander unabhängig sind und keinerlei Konsolidierungsbedarf
besteht, empfiehlt sich die Nutzung getrennter Systeme bzw. zumindest unterschiedlicher
Mandanten. Im letzten Fall ist darauf zu achten, dass Mitarbeiter der Auftraggeber keine
mandantenübergreifenden Berechtigungen (z. B. keine mandantenunabhängige Tabellenzu-
griffe, keine Systemberechtigungen). Bei besonders sensiblen Daten ist eine solche Trennung
ggf. ebenfalls geboten.
Eine Trennung in Buchungskreise bietet sich im Konzernverbund an. Hier ist darauf zu ach-
ten, dass die Zugriffsrechte die gesellschaftsrechtlichen Abgrenzungen abbilden. Abweichun-
gen hiervon sind durch die beteiligten Gesellschaften selbst untereinander datenschutzkon-
form zu regeln und dem Auftragnehmer vorzugeben.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 150
Eine weitere Trennung in Werke und/oder Personalbereiche ist datenschutzrechtlich nicht
zwingend vorgegeben. Sie resultiert eher aus unterschiedlichen Tarif- und Arbeitszeitregelun-
gen.
Im Hinblick auf die Vertraulichkeit von Personaldaten empfiehlt sich dann eine entsprechen-
de Einschränkung der Berechtigungen.
Da das BDSG keine speziellen Regelungen für Konzerne kennt, ist unter Datenschutzaspek-
ten auch innerhalb eines Mandanten das Augenmerk auf die sichere Datenverarbeitung je Bu-
chungskreis als kleinste bilanzierungsfähige bzw. rechtlich selbständige Einheit zu legen.
Der Umfang der an den Auftragnehmer übertragenen DV-Aufgaben wird naturgemäß je nach
Auftrag variieren. Beispielsweise kann der Auftraggeber zusätzlich zum Rechnerbetrieb (Be-
reitstellung von SAP-Systemen) die unternehmensspezifische Pflege der SAP-Anwendungen,
des Basissystems und der Betriebssystemkomponenten mehr oder weniger auf den Auftrag-
nehmer verlagern.
Aufgrund der Tatsache, dass Dienstleistungsrechenzentren i.d.R. für verschiedene Auftragge-
ber tätig sind, hat der Auftragnehmer hinsichtlich der realisierten Zugriffsschutzmechanismen
besondere Sorgfalt walten zu lassen, um personenbezogene Daten unterschiedlicher Anwen-
der zu trennen bzw. vertraulich zu behandeln.
5.3.2 SAP-Administration
Die Kontrolle der Berechtigungsadministration (Festlegung,. wer darf mit welchen Daten und
welchen Funktionen was machen) muss beim Auftraggeber bleiben.
Dagegen ist die Systemadministration Aufgabe des Auftragnehmers (Ausnahmen hiervon
sind beispielsweise bei der Nutzung eines Systems mit einem produktiven Mandanten mög-
lich). Allerdings ist der Zugriff auf personenbezogene Daten des Auftraggebers durch die
Administratoren im Rahmen des Auftrags restriktiv zu regeln.
SAP-spezifische Aufgaben, Zuständigkeiten und Verantwortlichkeiten (z.B. SAP-Benutzer-,
Berechtigungs-, Aktivierungsadministrator, SAP-Systemadministrator etc.) sollten daher in
einer Anlage zum Vertrag eindeutig festgelegt werden. Die Berechtigungsobjekte
„Benutzerstammpflege: Benutzergruppen“ (S_USER_GRP)
„Benutzerstammpflege: Berechtigungen“ (S_USER_AUTH)
„Benutzerstammpflege: Berechtigungsprofil“ (S_USER_PRO)
sind entsprechend den Vereinbarungen bei Auftragnehmer bzw. Auftraggeber einzurichten.
Analoges gilt für den Aufbau einer technischen sowie fachlichen Betreiberorganisation (wei-
tere Informationen zu Berechtigungsobjekten und -profilen s. Kap. 4).
5.3.3 SAP-spezifische Maßnahmen
Im Falle der Auftragsdatenverarbeitung kommt den technischen und organisatorischen Maß-
nahmen i.S.d. § 9 BDSG und deren SAP-spezifischen Ausprägungen (vgl. Kapitel 4 Umset-
zung der Anforderungen aus § 9 BDSG und Anlage: Technisch-organisatorische Maßnah-
men) besondere Bedeutung zu, da sie u.U. voneinander getrennte Zuständigkeitsbereiche be-
treffen.
Besonders hervorzuheben sind die nachfolgenden Punkte:
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 151
5.3.3.1 Systemadministration
Es ist sorgfältig zu prüfen, in welchem Umfang umfassende bzw. weitreichende Berechtigun-
gen bzw. Rollen an Benutzer des oder der Auftraggeber vergeben werden, da auf diese Weise
mandanten- und buchungskreisübergreifende Funktionen wahrgenommen werden können.
Beispielsweise können u.U. personenbezogene Daten des Buchungskreises "xxxx" Benutzern
des Buchungskreises "yyyy" zugänglich sein.
Auf der anderen Seite ist sorgfältig zu prüfen, inwiefern Administratoren des Auftragnehmers
Zugriffsrechte auf personenbezogene Daten des Auftraggebers erhalten.
Systemadministratoren sollen auf den produktiven Mandanten des Auftraggebers über keiner-
lei Berechtigungen verfügen (Ausnahme: Mandant 000 und ggf. 066). Für Notfälle ist ein
spezieller Notfalluser durch den Auftraggeber zu definieren und temporär freizuschalten.
5.3.3.2 Change and Transport Organizer (CTO/CTS)
Falls die SAP-Anwendungsentwicklung bzw. die Berechtigung zum Ändern von Entwick-
lungsobjekten auf den Auftragnehmer verlagert wird, ist bei diesem sicherzustellen, dass
Testdaten (häufig handelt es sich um Originaldaten des Produktivsystems für Integrations-
tests) nur den jeweiligen rechtlich selbständigen Einheiten (Buchungskreisen) als "Datenei-
gentümer" bzw. beauftragten Dritten zur Verfügung stehen.
Grundsätzlich dürfen zur Erhaltung der Sicherheit der Datenbestände, zum Schutz vor unbe-
rechtigter Kenntnisnahme von personenbezogenen Daten und zur Nachvollziehbarkeit der
Buchführung die Berechtigung zur Anwendungsentwicklung in einem produktiven SAP-
System nicht vergeben werden. Wenn Notfall-User mit diesen Berechtigungen existieren,
muss organisatorisch sichergestellt werden, dass alle Tätigkeiten dieser Benutzer inhaltlich
dokumentiert werden.
5.3.3.3 Fernwartung und Services
Wartungs- und Pflegeaktivitäten via Datenleitung erfolgen bei SAP-Systemen z. B über
SAP-EarlyWatch Check
Going-Live-Check
SAP Upgrade Assessment
Da auch bei einem Zugriff der SAP oder auch anderer Dienstleister im Rahmen von Service-
leistungen diese der Auftragsdatenverarbeitung gleichgestellt sind, sollten entsprechende Re-
gelungen über Art, Umfang und Zulässigkeit der Pflegemaßnahmen getroffen werden. Die
SAP stellt ihren Kunden hierzu auf Anforderung das Dokument „Security and Data Protection
at SAP“ zur Verfügung.
Der User Earlywatch ist der Dialogbenutzer für den SAP-EarlyWatch Check im Mandanten
066. Er wird nur für den Performance Monitor benötigt. I.d.R. wird dies lediglich auf Anfor-
derungen der entsprechenden Gesellschaft durchgeführt. Grundsätzlich sollte dieser Benutzer
nicht über das Profil SAP_ALL verfügen, da ansonsten u. a. auch die Pflege von mandanten-
übergreifenden Tabellen möglich ist. Somit sind auch hier aktivitätsbezogene Rollen zu er-
stellen.
Zum Schutz dieser Benutzer vor unberechtigtem Zugriff sind die Initial-Kennwörter zu än-
dern. Weiterhin sollten auch hier technische und organisatorische Maßnahmen ergriffen wer-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 152
den, über die sichergestellt ist, dass ausschließlich Funktionen ausgeführt werden, die für die
Nutzung eines solchen Benutzers vorgesehen sind.
Zur Kontrolle der von der SAP durchgeführten Maßnahmen des Benutzers Earlywatch kann
bspw. das Security Audit Log genutzt werden. Weiterhin ist zu empfehlen, dass dieser Benut-
zer nur gemäß einem beschriebenen Verfahren temporär entsperrt wird.
5.3.3.4 RFC und ALE
Der Remote Function Call (RFC) dient der Kommunikation zwischen verteilten Programmen
in einer Netweaver basierten-Systemlandschaft. Mit Hilfe von RFC können Funktionsbaustei-
ne in einem fremden Netweaver basierten -System aufgerufen werden und die Ergebnisse an
das aufrufende Netweaver basierten -System zurückgegeben werden.
Die Technik von RFC bildet auch die Grundlage für weitere Netweaver basierte/spezifische
Schnittstellenmethoden wie Application Link Enabling (ALE) und Business Application Pro-
gramming Interface (BAPI).
Wenn externe Systeme angebunden werden oder eine Wartung/ Pflege über RFC erfolgt, sind
die ausgeführten Funktionalitäten, da es sich hier ggf. wiederum um Datenverarbeitung im
Auftrag durch fremde Dritte handelt, anforderungsgerecht zu definieren. Zusätzlich sind tech-
nische sowie organisatorische Maßnahmen zu ergreifen, über die sichergestellt wird, dass ein
dem BDSG entsprechendes Datenschutzniveau aufrechterhalten wird.
5.3.3.5 Job-Abwicklung
Zwischen Auftraggeber und Auftragnehmer sind die Verantwortlichkeiten bezüglich Job-
Auftrag, Job-Durchführung und Job-Überwachung klar schriftlich zu definieren (z.B. Perso-
nalabrechnungslauf, Mahnlauf). Diese Verfahrensanweisungen sollten sowohl den Fachabtei-
lungen des Auftraggebers als auch den EDV-Zuständigen des Auftragnehmers vorliegen.
Die im SAP-System generierten Job-Protokolle weisen nach, mit welchen Parametern ein Job
gelaufen ist. Sie sind daher entsprechend zu schützen. I.d.R. wird für die Aufbewahrung der
Job-Protokolle der Auftragnehmer zuständig sein.
Die handelsrechtlichen Aufbewahrungsfristen für die Job-Dokumentation betragen mindes-
tens 10 Jahre. Sie muss innerhalb dieses Zeitraums also auch für den DSB verfügbar sein.
Die vertrauliche Handhabung der für die jeweiligen rechtlich selbständigen Einheiten ausge-
druckten Listen, die personenbezogene Daten enthalten, ist sicherzustellen.
5.3.3.6 PC-Download
Die Übertragung von SAP-Daten aus der "gesicherten SAP-Umgebung" per PC-Download ist
seit 4.0 über das Berechtigungsobjekt „Berechtigung für GUI-Aktivitäten“ (S_GUI) zu schüt-
zen.
In Releases ab 3.0C kann über Download-Funktionsbausteine der Download unterbunden
bzw. protokolliert werden (siehe hierzu SAP-Hinweis 28777 „PC Download: Protokollierung,
Berechtigungsprüfung“).
Auf einem PC hat der Benutzer die Möglichkeit durch Bildschirmabgriff (Cut and Paste) Da-
ten von der Anzeige zu kopieren. Hierfür müssen beim Auftragnehmer geeignete organisato-
rische Rahmenbedingungen geschaffen werden, die verhindern, dass personenbezogene Daten
ohne Wissen des Auftraggebers beim Auftragnehmer anderweitig nutzbar gemacht werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 153
5.3.3.7 Datenbank- und LAN-Umgebung
Seitens der SAP werden im SAP NetWeaver Security Guide grundsätzliche Empfehlungen
zur Installation in Bezug auf die Datenbank und das Netzwerk gegeben.
Bei einer Auftragsdatenverarbeitung ist zu prüfen, ob je Auftraggeber eigene Mandanten oder
Systeme eingesetzt werden sollen.
5.3.3.8 Mandantenübergreifende Funktionen
Beim Kopieren von Mandanten zwischen zwei Systemen, z.B. mit den Transaktionen SCC1
(über Transportauftrag), SCC9 (remote) bzw. SCCL (lokal), ist vom Auftragnehmer entspre-
chende Sorgfalt anzuwenden. Gegebenenfalls sind entsprechende Weisungen von dem oder
den Auftraggebern einzuholen.
Dieses gilt selbstverständlich auch für die Transaktion SCC5 Mandanten löschen
5.3.3.9 SAP-Protokolle
Unter Datenschutz- und Haftungsaspekten hat der Auftragnehmer archivierte SAP-Protokolle
als Nachweis für die Ausführung der Datenverarbeitung i.S.d. vertraglichen Vereinbarungen
und möglichen Nachkontrollen aufzubewahren. Die Auftragskontrolle kann Job-Protokolle,
Terminpläne, Sonderarbeitennachweise, Customizing-Aufträge, Transportaufträge etc. umfas-
sen.
Die Aufbewahrungsfristen könnten an die handels- und steuerrechtlichen Vorschriften ange-
lehnt werden.
Zu beachten ist, dass Protokolle zum Teil keine auftraggeberspezifische Auswertung erlau-
ben. Dies gilt insbesondere für Logdateien, sofern die Daten mehrerer Auftraggeber auf dem-
selben System, in demselben Mandanten, oder in denselben Organisationsstrukturen (Bu-
chungskreis, Werk/Personalbereich etc.) verarbeitet werden.
Zur eindeutigen Zuordnung bedarf es ggf. zusätzlich implementierter Filter für die Auswer-
tung der Protokolle, die im SAP-Standard nicht vorhanden sind. Ein solcher Filter kann z.B.
anhand der Benutzerkennungen des Auftraggebers erfolgen.
5.4 Risiken
Werden personenbezogenen Daten im Auftrag durch eine andere datenverarbeitende Stelle
verarbeitet oder genutzt, besteht die Gefahr, dass der Auftragnehmer der DV-Dienstleistung
datenschutzrechtliche Anforderungen oder vertragliche Vereinbarungen nicht hinreichend be-
achtet.
Letztlich ist jedoch die Unternehmensleitung des Auftraggebers gegenüber den Betroffenen
und den Aufsichtsbehörden verantwortlich.
Aufgrund dieses Sachverhalts resultiert die Verpflichtung des Auftraggebers, sich von der
sachgerechten Einhaltung der datenschutzrechtlichen und vertraglichen Vorgaben zu über-
zeugen.
Gleichzeitig ist der Auftragnehmer verpflichtet, unter Beachtung des Datenschutzes die sorg-
fältige Handhabung personenbezogener Daten verschiedener Auftraggeber (SAP-Anwender)
zu gewährleisten und die unautorisierte Übermittlung solcher Daten zu verhindern.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 154
Der Auftragnehmer ist insofern für die angemessene organisatorische Einbindung der für die
Verarbeitung personenbezogener Daten eingesetzten SAP-Systeme in das eigene interne Kon-
trollsystem verantwortlich.
Im Rahmen der Auftragsdatenverarbeitung sind folgende in der Verantwortung des Auftrag-
gebers liegende Tatbestände bußgeldbewährt (§ 43 Abs. 1 Nr. 2b BDSG):
wer vorsätzlich oder fahrlässig …
entgegen § 11 Absatz 2 Satz 2 einen Auftrag nicht richtig, nicht vollständig oder nicht
in der vorgeschriebenen Weise erteilt oder
entgegen § 11 Absatz 2 Satz 4 sich nicht vor Beginn der Datenverarbeitung von der
Einhaltung der beim Auftragnehmer getroffenen technischen und organisatorischen
Maßnahmen überzeugt, …
Zertifizierungen können den Prüfaufwand sowohl auf Seiten des Auftraggebers wie des Auf-
tragnehmers erheblich, aber in der Regel nicht vollkommen auf Null, reduzieren. Der Auf-
traggeber hat nicht abstrakt den Status der IT-Sicherheit beim Auftragnehmer zu überprüfen
sondern die ordnungsmäßige Ausführung des – individuell – vereinbarten Auftrags. Daher
muss ein vom Auftragnehmer vorgelegtes „… Testat … die verantwortliche Stelle in den
Stand versetzen können, selbst zu beurteilen, ob der Auftrag ordnungsgemäß durchgeführt
wird.“44. Erst ein hierauf ausgerichteter Abgleich mit den Anforderungen des Auftrags kann
das Haftungsrisiko des Auftraggebers hinsichtlich seiner Kontrollpflicht reduzieren.
44 Bayerisches Landesamt für Datenschutzaufsicht, Tätigkeitsbericht 2009/2010, S. 36 ff
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 155
6 Besondere Themen
6.1 Datenschutzkonformes Löschen mit dem SAP NetWeaver Information Lifecycle Management (ILM)
Das SAP NetWeaver Information Lifecycle Management (ILM) ist die grundlegende Anwen-
dung für das datenschutzkonforme Löschen von personenbezogenen Daten in SAP-Systemen.
Mit Hilfe des ILM können anhand von Regeln die Daten identifiziert werden, die aus der
SAP-Datenbank gelöscht werden sollen.
Das SAP NetWeaver Information Lifecycle Management bietet die folgenden Funktionen:
Definition von Regeln für die Aufbewahrungsfristen der personenbezogenen Daten.
Einplanen automatischer Abläufe, um die Datensätze, die anhand der definierten Aufbe-
wahrungsregeln ermittelt wurden, zu. vernichten.
Sie müssen das SAP NetWeaver Information Lifecycle Management aktivieren, um die Ar-
chivierungs- und Datenvernichtungsfunktionen des SAP NetWeaver ILM nutzen zu können.
Damit steht Ihnen das in das ILM integrierte Information Retention Management (IRM), zur
Verfügung, das eine Erweiterung zur Archivadministration (Transaktion SARA) ist.
Mit dem Retention Management (Transaktion IRMPOL) legen Sie die Aufbewahrungsregeln
für die personenbezogenen Daten fest. Wenn Sie einen Datenvernichtungslauf für ein durch
ILM erweitertes Archivierungsobjekt starten, prüft das System für alle Datenobjekte des Ar-
chivierungsobjekts die vorhandenen Aufbewahrungsregeln und bestimmt so, ob die Aufbe-
wahrungsfrist der Geschäftsdaten abgelaufen ist.
Das Retention Management erfordert im Customizing grundlegende mandantenübergreifende
Einstellungen. Die ILM-Regelwerke, die Sie im IRM in Abhängigkeit von den geltenden ge-
setzlichen Aufbewahrungsfristen definieren, sind dagegen mandantenspezifisch (siehe hierzu
auch die Ausführungen im Abschnitt 6.1.1 dieses Leitfadens).
Zusätzlich können Sie je nach Archivierungsobjekt über Reportselektionen in der Archivad-
ministration (Transaktion SARA) bestimmen, für welche Daten des Archivierungsobjekts die
Regeln angewandt werden sollen (z.B. durch Angabe eines Selektionsdatums). Mit diesen
Einstellungen können Sie dann automatisch in regelmäßigen Abständen die Daten vernichten,
indem Sie entsprechende Jobs einplanen.
Für bestimmte Daten kann optional eine Archivierung durchgeführt werden. In diesem Fall
wird der weitere Lebenszyklus der Daten über das ILM verwaltet. Sollen Archivdaten ver-
nichtet werden, entspricht dies dem zweiten Schritt der direkten Datenvernichtung, es gibt al-
so keinen zweistufigen Prozess.
6.1.1 Datenschutzkonformes Löschen in der Personalwirtschaft (SAP
HCM)
In allen Anwendungen der Personalwirtschaft stehen Ihnen Archivierungsobjekte zur Verfü-
gung, mit denen Sie die personenbezogenen Anwendungsdaten nach Ablauf einer dafür fest-
gelegten Aufbewahrungsdauer vernichten können. Wir haben uns im HCM dafür entschieden
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 156
für das datenschutzkonforme Löschen den Begriff Vernichtung zu benutzen um Verwechs-
lungen mit dem Löschen in der Stammdatenpflege, bzw. dem Schritt Löschen in der Archi-
vierung zu vermeiden.
Eine Übersicht über die im SAP HCM verfügbaren Archivierungsobjekte finden Sie im SAP
Help Portal unter Archivierung und Datenvernichtung in der Personalwirtschaft und im Hin-
weis 1559133 Datenschutzkonformes Löschen personenbezogener Daten im HCM (ein-
schließlich der darin referenzierten Hinweise)
Prozess der Datenvernichtung
Die Datenvernichtung umfasst folgende Prozessschritte:
Vorlauf (optional)
Archivierungsobjekte, für die ein Vernichtungsbeleg oder eine Anlegesperre für den Ver-
nichtungszeitraum erforderlich ist, verfügen über ein Vorlaufprogramm. Dies ist bei-
spielsweise bei Archivierungsobjekten für die Vernichtung von abrechnungsrelevanten
Daten (z.B. Abwesenheiten) der Fall.
In der Vorlaufphase finden die vorbereitenden Schritte zur Datenvernichtung wie Durch-
führung der erforderlichen Prüfungen, Vorselektion der zu vernichtenden Datensätze und
das Anlegen von Vernichtungsbelegen statt.
In der Vorlaufphase werden nur zusätzliche Information in der Datenbank gespeichert.
Die Daten selber werden nicht verändert.
Nach dem Schritt Vorlauf ist aber eine Änderung der Daten nicht mehr möglich.
Schreiben
Wenn ein Vorlauf stattgefunden hat, übernimmt das Schreibprogramm die Selektion der
Daten über eine ID in Selektionsbild aus dem Vorlaufprogramm: Ansonsten erfolgt die
Selektion der Daten hier analog zum Vorlaufprogramm.
In beiden Fällen erstellt das System danach aus den selektierten Datensätzen eine tempo-
räre Archivdatei mit allen zu vernichtenden Datensätzen.
In der Schreibphase werden keine Änderungen auf der Datenbank vorgenommen.
Löschen
Das Löschprogramm liest die temporäre Archivdatei. Jeder Satz, der in der Archivdatei
enthalten ist, wird aus der Datenbank gelöscht. Am Ende wird zusätzlich noch die Ar-
chivdatei selber aus dem Filesystem gelöscht. Sofern ein Vernichtungsbeleg geschrieben
wurde, erhält dieser jetzt den Status Vernichtet.
Da der Prozess der Datenvernichtung irreversibel ist, erfolgt dieser im Standard in zwei
Schritten.
Bei Archivierungsobjekten mit Vorlaufprogramm erfolgt in einem ersten Schritt der Vor-
lauf. In einem zweiten Schritt starten Sie die Schreibphase, auf die automatisch die
Löschphase folgt.
Bei Archivierungsobjekten ohne Vorlaufprogramm erfolgt zunächst die Schreibphase und
anschließend die Löschphase. Das Löschprogramm muss immer manuell gestartet wer-
den.
Diese Gliederung in einen zweistufigen Prozess ermöglicht Ihnen eine zwischenzeitlich Prü-
fung der zu vernichtenden Daten und die Unterstützung eines 4-Augen Prinzips.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 157
Das SAP HCM stellt Ihnen für die Datenvernichtung folgende zusätzliche Funktionen zur
Verfügung:
Vernichtungsbeleg
Für vernichtete personenbezogene Daten aus Infotypen der Personalwirtschaft können au-
tomatisch Vernichtungsbelege erzeugt werden. Vernichtungsbelege werden im Vorlauf-
programm eines Archivierungsobjekts geschrieben. Nach dem Vorlauf hat dieser Vernich-
tungsbeleg (Infotyp Archivierung/Datenvernichtung 0283) den Status Vorbereitet zur Da-
tenvernichtung. Nach dem Löschen erhält der Vernichtungsbeleg automatisch den Status
Vernichtet.
Vernichtungssperre
Auf Grund von nicht abgeschlossenen rechtlichen Vorgängen kann es sein, dass Daten für
einzelne Mitarbeiter länger aufbewahrt werden müssen, auch wenn deren Aufbewahrungs-
frist bereits abgelaufen ist und die Daten aus Datenschutzgründen vernichtet werden
müssten. Durch das Anlegen einer Vernichtungssperre (Infotyp Vernichtungssperre 3246)
können Sie sicherstellen, dass die für einen Rechtsfall relevanten Daten nicht vernichtet
werden können. Wenn der Rechtsfall entschieden ist, können die Daten wieder normal
vernichtet werden, sobald die Vernichtungssperre entfernt wurde.
Archivierungsteilobjekte
In einigen Archivierungsobjekten kann es kundenindividuell nötig sein die Datenobjekte
zu gruppieren. Dies erfolgt über die Archivierungsteilobjekte, dies können neue Gruppie-
rungen sein (z.B. bei Abwesenheiten), bzw. bestehende (Subtypen von Infotypen). Falls
hierzu ergänzenden Customizing nötig ist, erfolgt dies über den IMG.
Vernichtung von Abrechnungsdaten
Die Komponenten Personalzeitwirtschaft, Reisemanagement und Personalabrechnung
können integriert eingesetzt werden. Dabei fließen die Abrechnungsdaten aus dem Reise-
management und der Personalzeitwirtschaft in die Personalabrechnung ein. Um zu ge-
währleisten, dass keine Daten vernichtet werden, die noch für die Personalabrechnung be-
nötigt werden und um Dateninkonsistenzen zu vermeiden, müssen die Abhängigkeiten der
Datenobjekte der Archivierungsobjekte dieser drei Komponenten gemeinsam festgelegt
werden.
Mit Hilfe von Archivierungsgruppen können Archivierungsobjekte und Personalnummern
zusammengefasst werden, deren Abrechnungsdaten gemeinsam archiviert oder vernichtet
werden sollen. Die Transkation PU22 dient hierbei als gemeinsames Vorprogramm für al-
le drei Archivierungsobjekte.
Die eigentliche Vernichtung von Abrechnungsdaten erfolgt dann auch über Schreib- und
Löschprogramme individuell pro Archivierungsobjekt.
Zurücknehmen eines Vorlaufs zur Datenvernichtung
Wenn Sie nach erfolgter Vorlaufphase für ein Archivierungsobjekt (für Infotypen) fest-
stellen, dass eine Aufbewahrungsregel geändert werden soll oder bestimmte länderspezifi-
sche Daten oder die Daten einer oder mehrerer Personalnummern weiterhin aufbewahrt
werden sollen, können Sie diesen Vorlauf rückgängig machen. Mit dem Report Rücknah-
me Vorlauf zur Datenvernichtung (RP_PA_ROLLBACK) werden alle in der Vorlaufpha-
se für ein Archivierungsobjekt durchgeführte Änderungen zurückgenommen.
Die Lizenz zur Nutzung von SAP NetWaver ILM ist in Ihrer HCM bzw. E-Recruiting Lizenz
enthalten, solange sie das ILM nur zur Datenvernichtung einsetzen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 158
6.2 Read Access Logging
Um sensitive Daten zu schützen und den Verstoß gegen Sicherheitsrichtlinien zu erkennen hat
SAP mit dem SAP Netweaver Application Server (AS) ABAP 7.40 Read Access Logging
(RAL) eingeführt. Read Access Logging wird ebenfalls mit SAP Netweaver Application
Server (AS) ABAP 7.31 SP9 ausgeliefert.
Kunden können mittels Read Access Logging identifizieren und verfolgen wer zu welchem
Zeitpunkt Zugriff auf welche sensitiven Informationen hatte. Daten können von Kunden nach
ihren Richtlinien als sensitiv deklariert werden.
Beispiele für Fragestellungen, die durch Einsatz von Read Access Logging beantwortet wer-
den können sind unter anderem:
Wer hatte Zugang zu einer Geschäftseinheit, beispielsweise einem Bankkonto?
Wer hatte Zugang zu Adressdaten, zum Beispiel eines Geschäftspartners?
Wer hatte Zugang zu persönlichen Informationen, beispielsweise Religionszugehörigkeit
eines Mitarbeiters?
Technisch bedeutet dies, dass Remote APIs und Benutzerschnittstellen, die Zugriff auf solche
sensitiven Daten erlauben, protokolliert werden müssen.
RAL erlaubt zurzeit das Protokollieren folgender Kanäle:
NW 740 SP0: Web Services
NW 740 SP2: Remote Function Calls (sRFC, aRFC, tRFC, qRFC, bgFRC)
NW 740 SP2: Web Dynpro
NW 740 SP4: ABAP Dynpro
Mit der Transaktion SRALMANAGER startet man eine Web Dynpro Anwendung im Brow-
ser, die es erlaubt sowohl Verwaltungsfunktionen aufzurufen als auch erfasste Vorgänge ein-
zusehen. Um RAL nutzen zu können muss man zuerst Konfigurationen anlegen.
RAL Konfigurationen legen fest welche Form von Zugang unter welchen Bedingungen für
welchen Zweck aufgezeichnet werden muss.
Eine Konfiguration benötigt einen Verwendungszweck (Logging Purpose), der den Grund der
Aufzeichnung beschreibt. Dies könnte beispielsweise der Zugriff auf Gehaltsdaten von Vor-
ständen sein.
Des Weiteren wird es empfohlen Log-Domains zu verwenden, die die semantische Bedeutung
der aufgezeichneten Daten definieren. Log Domains erlauben es dem Kunden für semantisch
gleiche oder verbundene Felder eine einheitliche Beschreibung festzulegen. Zum Beispiel
können Finanzkontodaten in den verschiedenen anderen Schnittstellen in unterschiedlicher
Repräsentation, als Integer oder Text, etc., vorkommen. Diese Beschreibung erleichtert den
Auditoren das spätere Verständnis der Aufzeichnungen.
Um Informationen aufzuzeichnen die in einer Benutzerschnittstelle (UI) angezeigt werden,
muss man die gewünschten Felder in einer Aufnahme markieren. Dazu startet man einen Re-
corder über den Administration Tab im SRALMANAGER. Je nach UI Technologie wählt
man einen entsprechenden Aufnahmekanal, beispielsweise Web Dynpro, aus. Nach Eingabe
eines Namens und einer optionalen Beschreibung startet man die Aufnahme. Nun kann man
das aufzunehmende UI starten und über das Kontextmenü jedes gewünschte Feld zu der Auf-
nahme hinzufügen.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 159
Nach dem Aufzeichnen kann man die Felder bei der eigentlichen Log Konfiguration auswäh-
len und den davor definierten Log Domains zuordnen.
Mit Hilfe des Verwendungszwecks, der Log Domain, sowie der Felderaufnahme, kann nun
eine Konfiguration angelegt werden, die den Lesezugriff, in dem zuvor ausgewählten Kanal
und der entsprechenden UI Technologie, spezifiziert.
Schlussendlich, wenn die Konfiguration abgeschlossen ist, kann das Read Access Logging
aktiviert werden.
Die gesamten Konfigurationsdateien können unter Zuhilfenahme des integrierten Transport
Managers (Transaktion SRAL_TRANS) in die verschiedenen, zu beobachtenden Systeme
transportiert werden. Dort können die Konfigurationen pro Mandant aktiviert oder deaktiviert
werden.
Es besteht die Möglichkeit spezielle Benutzer, zum Beispiel technische Benutzer, vom Proto-
kollieren auszunehmen.
Es besteht weiterhin die Möglichkeit Daten die mit Read Access Logging erfasst wurden mit-
tels des Information LifeCycle Management (ILM) zu archivieren oder zu löschen.
Die Log Ergebnisse können über die Monitorfunktionalität in der Transaktion SRALMANA-
GER von den Administratoren betrachtet werden. Es ist möglich Logeinträge nach Kanal,
Zeit, Benutzer und anderen Parametern zu durchsuchen. Eine detaillierte Beschreibung und
Best Practices können in folgendem SAP Insider Artikel zu Read Access Logging nachgele-
sen werden:
http://scn.sap.com/docs/DOC-44006.
6.3 Auditwerkzeuge: Audit Information System und Benutzerinformationssystem
6.3.1 Audit Information System (AIS)
Das AIS ist als Arbeitsmittel für die Auditierung des SAP-Systems konzipiert und richtet sich
vor allem an Systemauditoren, Revisoren und Wirtschaftsprüfer. Es wird im Standardumfang
des SAP ERP mitgeliefert und führt laut Dokumentation zu „einer Verbesserung der Prü-
fungsqualität und einer Rationalisierung des Prüfungsablaufes“. Das AIS beinhaltet eine
Sammlung, Strukturierung und Voreinstellung von Prüfungsfunktionen inklusive Dokumenta-
tion, Prüfungsauswertungen und Download von Prüfungsdaten. Es ermöglicht die Protokollie-
rung der Auditaktivitäten und unterstützt das Reporting über erstellte Auditprotokolle.
Grundsätzlich gliedert sich das AIS in die Bereiche kaufmännisches Audit und System Audit.
Das kaufmännische Audit beinhaltet neben organisatorischen Übersichten auch bilanzorien-
tierte und prozessorientierte Funktionen. Damit lassen sich zum Beispiel Informationen über
Kunden, Lieferanten, die Finanzbuchhaltung und Steuerbelange gewinnen.
Das System Audit des AIS ist in verschiedene Bereiche unterteilt: u. a. allgemeine Sys-
temprüfungen, Analyse der Benutzer und Berechtigungen sowie die Prüfung des Repository
und der Tabellen. Damit bietet es einem Auditor umfangreiche Funktionen zur Überprüfung
des Systemzustandes, wie z.B. von Systemparametern oder dem Transportwesen.
Für die Analyse eines SAP-Berechtigungskonzeptes kann unter anderem das "Infosystem Be-
nutzer & Berechtigungen" verwendet werden, mit dem z. B. verschiedene Auswertungen über
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 160
Benutzer, Rollen oder Änderungsbelege (Protokollierung der Benutzer-/Rollenverwaltung)
erstellt werden können.
Das AIS bietet aber auch dem Datenschutzbeauftragten Hilfestellungen bei seinen Aufgaben-
stellungen. Dieser kann das AIS insbesondere nutzen für
Datenschutzprüfungen (siehe Kapitel 2.1 und 4.3)
Auskunftsersuchen von Betroffenen (siehe Kapitel 3.1)
das Erstellen von Übersichten (siehe Kapitel 2.3).
Folgende Auswertungen bietet das AIS für die Erstellung der Übersichten gemäß § 4 BDSG
(Dateiregister) an:
Verwendungsnachweis von Domänen zu nicht leeren DB-Tabellen
Dateiregister für Mitarbeiterdaten
Dateiregister für Bewerberdaten
Dateiregister für Lieferantendaten
Dateiregister für Kundendaten
Dateiregister für Partnerdaten
Dateiregister für Sachbearbeiterdaten
Dateiregister für Verkäufergruppendaten
Dateiregister für Patientendaten
Dateiregister für R/3 Benutzer.
Ab dem SAP Basis Release 7.02 SP 14 wurde das AIS wieder auf themenbezogene Audi-
tstrukturen auf Basis von Bereichsmenus umgestellt, dass „AIS-Cockpit“ (Transaktion SAIS).
Damit können Sie die Auditstrukturen wieder direkt benutzen und individuell erweitern. Dies
erfolgt durch die Erstellung eines Bereichsmenus mit der SE43, die auch die Einbindung von
(externen) Dokumenten ermöglicht.
Die Protokollierung des Audits erfolgt zu jeder Prüfungsaktivität, dabei werden im Proto-
kollmodus der Applikation das Ausführungsdatum, der Durchführende, ein Prüfstatus sowie
einen Beschreibung der Prüfungshandlung (Textfeld) gespeichert. Diese Informationen lassen
sich später jederzeit wieder anzeigen und es besteht die Möglichkeit einen fortlaufenden
Kopftext je Auditstruktur zu pflegen.
Die von Ihnen definierten Auditstrukturen dienen dann als Vorlage für Rollen mit lokalen
Vorschlagswerten, dazu importieren Sie das Bereichsmenu in das Menu der Rolle und gene-
rieren die Berechtigungen aus den Vorschlagswerten. Zusätzlich können Sie über das Berech-
tigungsobjekt S_SAIS die Auditstrukturen und Prüfnummern abgrenzen.
Details zum „AIS-Cockpit“ finden Sie im Hinweis 1856125 (FAQ Optimale Nutzung des
Audit Information System), Details zur Auslieferung stehen im Hinweis 1763089. Das „AIS-
Cockpit“ befindet sich zurzeit noch in der Pilotauslieferung ohne SAP-Default-
Auditstrukturen, sobald diese verfügbar sind werden sie im Hinweis 1856125 referenziert.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 161
Damit wurde die einhellige Forderung nach einer Menu Struktur in AIS von SAP wieder um-
gesetzt. Allerdings sind einige Anforderungen zur Verbesserung des AIS45 , die bereits im
September 2005 von Mitgliedern der AG Datenschutz formuliert wurden, weiterhin offen:
Die bisherige Funktion zum ‚Dateiregister’ muss dem Sprachgebrauch des BDSG ange-
passt und um weitere Domänen mit Personenbezug erweitert werden (z.B. EKGRP).
Es sollten Funktionalitäten zur Anzeige von Daten besonderer Art (SAP Standard und
kundeneigene Infotypen) für die Unterstützung einer Vorabkontrolle angeboten werden.
Der ‚Lebenszyklus von (personenbezogenen) Daten’ sollte angezeigt werden können, um
z.B. die Dauer der Speicherung zu bewerten oder einen Wegfall der Zweckbestimmung
beurteilen zu können.
Es sollte eine Reportingfunktion über die Verpflichtung auf das Datengeheimnis (Infotyp
Belehrungen) geben.
Diese Verbesserungsvorschläge beziehen sich neben dem Datenschutz auch auf die Funktio-
nalitäten zur Personalwirtschaft (HCM), auf die Analyse von Berechtigungskonzepten und
des Systemzustandes sowie auf die Protokollierungsmöglichkeiten im SAP ERP.
Eine Übersicht über die für den Datenschutzbeauftragten relevanten AIS-Standardrollen der
rollenbasierten Pflegeumgebung ab Release 4.6C findet sich am Anfang des Kapitels 2 (Auf-
gaben des Datenschutzbeauftragten). Hier werden auch Empfehlungen zur Rollenvergabe an
den DSB sowie weiterführende Literaturhinweise gegeben.
Weitere Informationen zum rollenbasierten AIS ab Release 4.6C entnehmen Sie bitte der Do-
kumentation des Audit Information System bzw. den SAP Hinweisen 754273 und 451960.
6.3.2 Benutzerinformationssystem (SUIM)
Das Benutzerinformationssystem (Transaktion SUIM) kann als Analyseinstrument für das
Berechtigungskonzept eines SAP ERP-Systems verwendet werden. Es hilft dem Auditor, ei-
nen Überblick über die Benutzerverwaltung zu erlangen, z.B. über
die Benutzer und ihre Zugriffsberechtigungen
die im System vorhandenen Rollen, Profile und Berechtigungen
die von SAP definierten Berechtigungsobjekte sowie
alle Änderungsbelege (Protokolle) zu Benutzern, Rollen, Profilen etc. 46
Mit dem Benutzerinformationssystem kann allerdings bisher nur das Berechtigungskonzept
der ‚klassischen ABAP-Welt’ analysiert werden. Die im Rahmen der Java-Umgebung verge-
benen Berechtigungen (z.B. für Portale) und die so genannten ‚strukturellen Berechtigungen’
können nicht mit dem Benutzerinformationssystem überprüft werden. In speziellen SAP Sys-
temen, wie z.B. SAP CRM für das Kundenbeziehungsmanagement, kommen ggf. weitere In-
45 I. Carlberg / G. Siebert / G. Voogd: Anforderungen an die Veränderung des Audit Info Systems (AIS):
SAP R/3 Enterprise, Version 4.7, WEB AS 6.20, Patch-Level 44; Stand: 26.9.2005
46 Zur Anwendung des Benutzerinformationssystems vergleiche die einschlägigen SAP-Hinweise sowie
Abschnitt 4.2.1.4.5 (Rollen mit kritischen Berechtigungen): „Abhängig von der Pflegequalität der
Rollen kann die SUIM irreführend sein.“
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 162
strumente für die Berechtigungsverwaltung hinzu (vgl. ‚Leitfaden Datenschutz für mySAP
CRM’, Abschnitt 2.5.2).
Es wäre wünschenswert, dass SAP derartige Funktionalitäten in das Benutzerinformationssys-
tem integriert und die bestehenden ‚Anwendungslücken’ dokumentiert.
6.4 SOS-Report ( Security Optimization Service )
SAP stellt remote und jetzt auch für den Kunden automatisiert und kostenfrei einen Service
zur Verfügung (ST14: Anwendungsanalyse, > Security Optimization), der die Sicherheitsein-
stellungen für den ABAP-Stack analysiert und eine Bewertung nach Risiken in Ampelform
vornimmt. Er ist ähnlich dem EWA-Dienst (Early Watch Alert) angelegt und gibt hohe, mitt-
lere und geringe Risiken (nach Definition der SAP) für einen sicheren Systembetrieb aus.
Der SOS-Report wird auf dem aktiven System erzeugt und dem in den Systemverbund einge-
bundenen Solution-Manager (SM)-System zur Aufbereitung und Sichtung sowie Bearbeitung
zur Verfügung gestellt (SM-Transaktion: Solution_Manager). Er kann auch periodisch vom
SM-System angefordert und bereitgestellt werden.
Der Report liefert nach dem bekannten Muster des SAP_Reports zu den kritischen Berechti-
gungen aus dem Benutzerinformationssystem eine Vielzahl von Auswertungen zu allen Ge-
bieten der üblichen Sicherheitseinstellungen z.B. zur System- und Mandanteneinstellung, zur
Benutzeradministration, zum Login, zum Security Audit Log und zu bestimmten HCM-
Berechtigungen.
SAP-Administratoren oder Benutzer mit hohen fachlich-spezialisierten Administrationsrech-
ten können in einem Fragefilter (Questionnaire) angegeben und so von der Listung und risi-
komäßiger Bewertung ausgenommen werden.
Der SOS-Report liefert einen guten Überblick zu den einzelnen Sicherheitseinstellungen des
ABAP-Stacks und ist gleichzeitig ein Maßstab für eine Zuständigkeits- und Arbeitsteilung bei
sicherheitskritischen Aufgaben und den damit verbunden benötigten sicherheitskritischen Be-
rechtigungen. Z.B. wird der betriebliche Umgang mit dem SAP_ALL Profil aufgezeigt und in
Frage gestellt. Die Problematik der wirklich benötigten und der tatsächlich vorhanden Berech-
tigungen wird sehr deutlich angesprochen.
Der Security Optimization Service liefert eine Orientierung über den Sicherheitsstatus des
SAP-Betriebes und sollte in jedem Falle ein Methode der Überprüfung sein, ob das sich aus
der betrieblichen Sicherheits- und Risikoanalyse ergebende Schutzniveau bezüglich der tech-
nischen Maßnahmen umgesetzt und eingehalten wird.
Der Dienst steht nur in englischer Sprache zur Verfügung. Weiteres kann im SAP-
Marketplace nachgelesen werden (http://service.sap.com/sos)
6.5 SAP GRC (Governance, Risk and Compliance)
Die SAP GRC Suite umfasst Lösungen zum Risikomanagement, zur Dokumentation des In-
ternen Kontrollsystems, zur Zugriffs- und Berechtigungssteuerung sowie für den globalen
Handel und den Umwelt-, Gesundheits- und Arbeitsschutz.
Mit diesen Anwendungen für Governance, Risk und Compliance können wichtige Vorschrif-
ten eingehalten, Governance-Aspekte berücksichtigt und Transparenz über die unterneh-
mensweiten Risiken hergestellt werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 163
Technologische Grundlage für den Einsatz der GRC-Lösungen ist die Integrations- und Ap-
plikationsplattform SAP NetWeaver.
Im Sinne des vorliegenden Konzeptes, ist die SAP GRC Suite die umfassende Lösung, um
den Anforderungen des Datenschutzes wirksam, nachhaltig und vor allem effizient nachzu-
kommen.
Die GRC Suite besteht unter anderem aus:
SAP GRC Access Control, Zugriffs- und Berechtigungssteuerung,
SAP GRC Process Control, Lösung zur Dokumentation des internes Kontrollsystems
SAP GRC Risk Management, Risikoidentifikation und -analyse
Darüber hinaus sorgen weitere GRC-Lösungen für die Einhaltung von Bestimmungen in zahl-
reichen Branchen.
Die Anwendungen der SAP GRC Suite sind zusätzliche Software die im Standard nicht ver-
fügbar ist. Daher ist ihr Einsatz mit weiteren Lizenzkosten verbunden.
6.5.1 SAP GRC Access Control
Das SAP GRC Access Control dient der Zugriffs- und Berechtigungssteuerung in SAP-
Systemen, es besteht aus den folgenden Komponenten:
Access Risk Analysis, (ARA) zur Analyse von kritischen Berechtigungen und deren
Kombinationen in Rollen, Profilen und Benutzern
Business Role Management (BRM), für die zentralisierte Verwaltung von Berechtigungs-
rollen
Emergency Access Management (EAM), für temporären Zugriff mit erweiterten Berech-
tigungen
User Access Management (UAM), für ein automatisiertes Antragsverfahren über Work-
flow mit anschließender Zuordnung der Berechtigungen
Access Control besteht aus einem zentralen System, welches seit der Version 10.0 auf ABAP
basiert. Die an das Access Control angeschlossenen Systeme benötigen ein PlugIn, damit die
Analyse von Risiken, die Verwaltung von Rollen, der Notfallbenutzerzugriff und die Zuord-
Business Process Platform
SAP Solutions for GRC
Cross-Industry GRC
Access Control Process Control Trade
Global Trade EH&S
Risk Management
Industry-Specific GRC
Business Applications
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 164
nung von Berechtigungen aus dem Antragsverfahren aus dem zentralen Access Control Sys-
tem erfolgen kann.
6.5.1.1 Access Risk Analysis
Access Risk Analysis ermöglicht es kritische Transaktionen und Konflikte in Bezug auf die
Funktionstrennung innerhalb von Rollen oder Profilen aufzudecken. Ein Regelwerk mit Re-
geln für die Funktionstrennung in den ERP-Systemen von SAP, Oracle und PeopleSoft, JD
Edwards und Hyperion wird in Echtzeit mit den vorhandenen Berechtigungen verglichen.
Access Risk Analysis erkennt damit automatisch vorhandene und entstehende Risiken der
Zugriffskontrolle. Außerdem ist es möglich selbst Regeln zu definieren oder kritische Trans-
aktionen zu identifizieren.
In der Anwendung werden Reports zur Auswertung der Risiken nach Benutzern, Benutzer-
gruppen, Rollen, Profilen und kritischen Transaktionen bereitgestellt.
Mithilfe von Access Risk Analysis wird
bestimmt, ob eine Sammlung von Berechtigungen und Aktivitäten eines Benutzers, einer
Rolle oder eines Profils Risiken beinhaltet,
bestimmt, ob Risiken entstehen, indem einem Benutzer weitere Aktivitäten, Rollen oder
Profile zugeordnet werden (Simulation),
ein Alert generiert, falls eine kritische Transaktion ausgeführt wird.
Ein signifikanter Bestandteil des Datenschutzes ist die Kontrolle des Zugriffs auf Daten, in
Bezug auf SAP ERP die Nutzung bestimmbarer Transaktionen mit bestimmbaren Berechti-
gungen, im HR die Nutzung bestimmbarer Transaktionen mit bestimmbaren Infotypen und
Subtypen. Durch die präzise Definition des Zugriffsrisikos, werden die Risiken rollen- und
benutzerbezogen auswertbar. Fallweise kann man einstellen, dass Access Risk Analysis eine
Warnung ausgibt, sofern die kritischen Berechtigungen oder Kombinationen von Berechti-
gungen vergeben wurden.
6.5.1.2 Business Role Management
Business Role Management zentralisiert und standardisiert die Anlage und Verwaltung von
Rollen im Unternehmen. Führungskräfte können funktionsabhängige Rollen festlegen, wäh-
rend IT-Verantwortliche die entsprechenden technischen Berechtigungen definieren. Durch
eine flexible Prozessabbildung und eine automatisierte hierarchische Rollengenerierung ist es
einfach Rollen anzulegen und zu pflegen.
Die Anwendung reduziert damit die Gefahr von Fehlern und erleichtert die einheitliche Reali-
sierung bewährter Verfahren.
Business Role Management ist in den Profilgenerator integriert, daher können einmal defi-
nierte Rollen automatisch im SAP-System erzeugt werden.
6.5.1.3 Emergency Access Management
Emergency Access Management ermöglicht es Benutzern, außerhalb ihrer sonstigen Rollen in
einer kontrollierten und für die Revision transparenten Umgebung (Notfall-) Maßnahmen
durchzuführen. Dem Benutzer wird ein temporäres Benutzerprofil (Superuser-ID) zugeordnet.
Dieses bietet Zugriff auf z.B. kritische Transaktionen, oder sogar einen umfassenden System-
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 165
zugriff. Dabei beobachtet, überwacht und protokolliert die Anwendung jede Aktivität und
Verwendung der Superuser-ID. Die verantwortlichen Personen erhalten eine automatische
Meldung über den Einsatz der Superuser-ID und die entsprechenden Protokolldateien. Im Vo-
raus wird festgelegt, welche Benutzer einer Superuser-ID zugeordnet werden. Daher gibt es
keine Verzögerungen im Notfall.
6.5.1.4 User Access Management
User Access Management ermöglicht eine ordnungsgemäße Erteilung von Zugriffsrechten.
Dynamische Workflows automatisieren die Genehmigungsprozesse indem jede Anfrage an
die verantwortlichen Personen (z.B. per Email) weitergeleitet wird. Diese werden über bereits
vorhandene Berechtigungen des Antragstellers (und ggf. entstehende Risiken durch eine Er-
weiterung) informiert und können dann zustimmen oder ablehnen. Falls eine Zustimmung er-
teilt ist, wird die Rolle automatisch dem Benutzer zugeordnet.
Außerdem wird es den Benutzern mit User Access Management ermöglicht ihre Passwörter
selbstständig zurückzusetzen.
6.5.2 SAP GRC Process Control
Die Anwendung SAP GRC Process Control dient zur Dokumentation des internen Kontroll-
systems. Process Control unterstützt die Durchführung und Überwachung von Kontrollen in
Bezug auf Geschäftsprozesse und die unternehmensweite IT-Infrastruktur. Dabei wird die
Dokumentation, das Bewerten und Testen der Kontrollen sowie die Steuerung und Überwa-
chung der Behebung von Kontrollschwächen unterstützt.
So wird gewährleistet, dass Vorschriften zur Rechnungslegung wie z.B. der Sarbanes-Oxley
Act eingehalten werden.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 166
Die Struktur des Unternehmens kann in einer Organisationshierarchie abgebildet werden.
Für das ganze Unternehmen werden Prozesse und Subprozesse definiert. Einem Pro-
zess/Subprozess können Kontrollen zugeordnet werden, die Risiken abdecken.
Die Kontrollen können regelmäßig über geplante Testläufe ausgewertet werden. Dabei unter-
scheidet man in Process Control zwischen automatischen, semi-automatischen und manuellen
Kontrollen. SAP liefert vordefinierte automatische Kontrollen mit Process Control aus, zu-
sätzlich haben Kunden die Möglichkeit mit Hilfe eines Rahmenwerks eigene automatische
Kontrollen zu konfigurieren. Diese automatischen Tests sind regelbasierte Prüfungen der
Kontrollwirksamkeit.
In der Applikation besteht zusätzlich die Möglichkeit eigene manuelle und semi-automatische
Kontrollen zu den Prozessen zu definieren. Dazu können z.B. Queries erstellt oder Reports
(SAP Standardreports und Kundenreports) eingeplant werden, die Process Control automa-
tisch auf dem ERP-System startet. Die Ergebnisse werden dann per Workflow an den zustän-
digen Benutzer zur Auswertung weitergeleitet.
Es ist möglich den Status der Process Control Stammdaten zu einem bestimmten Zeitpunkt zu
betrachten und Unterschiede zwischen verschiedenen Zeitpunkten zu erkennen.
Im Rahmen des Datenschutzes kann Process Control z.B. eingesetzt werden, um Datenverar-
beitungsprozesse zu definieren und zu dokumentieren. Außerdem kann die Bereitstellung von
detaillierten Anleitungen und genehmigten Vorlagen Mitarbeitern die manuellen Prüfungs-
aufgaben erleichtern.
Regelmäßige Kontrollen können sicherstellen, dass z.B.
die Mitarbeiter ihre persönlichen Daten bestätigen/korrigieren (Recht auf Berichtigung),
die Einhaltung der Löschfristen kontrolliert wird und Datenbankreorganisationen gestartet
werden,
die Auftragsdatenverarbeitung den rechtlichen und vertraglichen Vorgaben entsprechend
durchgeführt wird (Dokumentation/Kontrolle der Anforderungen) die seit der Novellie-
rung des BDSG (01.09.2009) bestehenden Kontrollpflichten des Auftraggebers bei der
Auftragsdatenverarbeitung können ebenfalls eingeplant und dokumentiert werden. Dies
gilt natürlich auch für die Auftragnehmer Seite
Falls bei den Kontrollen Unstimmigkeiten auftauchen oder sich Prozesse verändern, kann au-
tomatisch der Datenschutzbeauftragte (bzw. der zuständige Mitarbeiter) benachrichtigt wer-
den (Workflow).
6.6 SAP TDMS (Test Data Migration Server)
Der SAP Test Data Migration Server dient der Übernahme von relevanten Anwendungsdaten
aus dem SAP Produktivsystem in andere Systeme der Systemlandschaft, wie dem Entwick-
lungs-, Test-, Qualitätssicherungs- oder Schulungssystem. Dies ermöglicht nicht nur ein
schlankes, konsistentes nicht produktives System, sondern auch die Möglichkeit sensible Da-
ten vor der Datenmigration zu verschlüsseln. Dazu wird der mit dem TDMS bereitgestellte
Anonymisierungs-Content verwendet oder kundeneigene Scrambling-Regeln erstellt. Wäh-
rend der Nutzung des TDMS wird der Anwender über die Datenschutzproblematik informiert
und auf die Details des Daten-Scramblings hingewiesen. Sollte der Anwender die Daten ohne
Scrambling transferieren wollen, erhält er zusätzlich noch eine Warnung.
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 167
Bei der Übernahme von Daten wird nach Zeit, Organisationseinheit oder Geschäftsprozess
ausgewählt und festgelegt, ob alle vorhandenen Anwendungsdaten in einem Mandanten er-
setzt werden sollen, oder die Daten in einem bestehenden Mandanten um weitere Daten er-
gänzt werden. Das SAP TDMS bietet u.a. die folgenden Migrationslösungen:
Zeitbasiert werden alle mandantenabhängigen Anwendungsdaten innerhalb einer angege-
benen Zeitscheibe übernommen, dies kann zusätzlich auf Buchungskreise eingeschränkt
werden.
Übernahme der Stammdaten und des Customizings, aber keine Bewegungsdaten.
Ergänzung der geschäftsprozessspezifische Daten (z.B. Kundenaufträge) aus dem ERP-
Produktivmandanten
Übernahme von Daten für HCM, die anhand von Kriterien herausgefiltert wurden.
Kopiert Repository-Informationen und mandantenübergreifendes Customizing aus dem
Produktivsystem ohne Anwendungsdaten.
Verschlüsselung sensibler Daten in einem nicht produktiven System ohne systemübergrei-
fende Datenübernahme.
SAP TDMS ist für die folgenden Anwendungen verfügbar:
SAP ERP Central Component
SAP Business Warehouse
SAP Business Suite: SAP HCM, SAP CRM, SAP SCM und SAP SRM
SAP-Branchenlösungen: Utilities, Banking, Retail, Apparel and Footwear, Discrete Indus-
tries and Mill Products, Oil and Gas (Downstream) und Healthcare
Die Anwendungen von TDMS sind zusätzliche Softwarekomponenten, daher ist ihr Einsatz
mit weiteren Lizenzkosten verbunden. SAP TDMS ist ein wesentliche Bestandteil der Build-
und Testphase des SAP Application Lifecycle Management (ALM).
Die TDMS Lösung ist zertifiziert im EuroPriSe Verfahren: EuroPriSe ist eine von der EU ge-
förderte Initiative des ULD, die unter Beteiligung von acht weiteren europäischen Partnern
ein europäisches Datenschutz-Gütesiegel entwickelt hat. Das Vertrauens-Siegel wird von ei-
ner unabhängigen Stelle verliehen. Einem IT-Produkt oder einer IT-basierten Dienstleistung
wird bestätigt, dass es die strengen Vorgaben der europäischen Datenschutz-Richtlinien vor-
bildlich erfüllt. (https://www.european-privacy-seal.eu/about-europrise/fact-
sheet/EuroPriSe%20Fact%20Sheet-de-20100826.pdf)
Leitfaden Datenschutz Stand Autor Seite
für SAP-ERP 31.12.2013 AG Datenschutz 168
7 Glossar
http://help.sap.com/
http://www.sap.info/de/glossary/A.html
http://www.sap.info/en/glossary/A.html