Schwarz/Pahlke, AO § 29c Verarbeitung personenbezogener ... / 2.4 Weiterverarbeitung zur Entwicklung und Evaluierung von automatisierten Verfahren (Abs. 1 S. 1 Nr. 4 und S. 2)

Rz. 28

Die steuerlichen IT-Verfahren sind aus unterschiedlichen Gründen einem ständigen Wandel unterworfen. Zum einen hat sich das Besteuerungsverfahren dem Zeitgeist anzupassen und hierzu niederschwellige, medienbruchfreie, aber zugleich sichere Kommunikationswege mit einer Vielzahl von am Besteuerungsverfahren Beteiligten bereitzustellen. Die Anzahl der stetig wachsenden Daten aus dem In- und Ausland muss zugeordnet und in ein geordnetes und dokumentiertes Deklarations- und Verifikationsverfahren eingepasst werden. Zuletzt ist das Steuerrecht einer durch Einflüsse aus Politik und Justiz sehr hohen Dynamik ausgesetzt, die sehr zeitnah in den IT-Verfahren Niederschlag finden muss, damit Rechtsstreitigkeiten und Schadensersatzforderungen gegen den Fiskus verhindert werden können.

In diesem Umfeld besteht ein ständiger und sehr hoher Bedarf, die eingesetzten IT-Verfahren fortzuentwickeln, bzw. in eine geänderte IT-Peripherie einzupassen. Angesichts der stetig steigenden Komplexität der IT-Architektur und der Anzahl der im Einsatz befindlichen Software-Produkte sind Verarbeitungs- und Testergebnisse, die in einer "künstlichen" Testumgebung erzielt werden, immer weniger aussagekräftig. Der Druck, Tests auch unter echten Bedingungen vorzunehmen, um Fehler oder IT-Ausfälle weitgehend ausschließen zu können, ist in den letzten Jahren erheblich gestiegen.

§ 29c Abs. 1 S. 1 Nr. 4 AO wiederholt den generell bei der Weiterverarbeitung von Daten in Art. 23 Abs. 1 DSGVO enthaltenen Verhältnismäßigkeitsgrundsatz durch den Hinweis, dass hiernach die Verwendung von "Echtdaten", also nicht pseudonymisierten oder anonymisierten Daten, nur dann zulässig ist, wenn die Verwendung erforderlich ist.

Rz. 29

Im Rahmen des Gesetzgebungsverfahrens wurde diese Regelung wegen des unverhältnismäßigen Eingriffs in das Recht auf informelle Selbstbestimmung kritisiert. Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit forderte, dass für die Entwicklung automatisierte Testfälle (sog. Dummy-Datensätze) geschaffen werden müssen. Dies umfasse auch die Entwicklung und den Test übergreifender, also mit anderen Verfahren vernetzter Verfahren.^[1] Hiernach dürften "Ist-Daten" (gemeint sind wohl Echtdaten) nur nachrangig genutzt werden, wenn eine pseudonymisierte Verarbeitung nicht in Betracht kommt. Der hiermit verbundene Aufwand für den Aufbau dieser Testumgebung sei hinzunehmen. Dieser sehr engen Auffassung wurde entgegengehalten, dass eine Pseudonymisierung aufgrund von Eigenarten im Steuerfall (z. B. der einzige Großkonzern im FA-Bezirk) nicht immer zielführend sei. Überdies seien die zu testenden Lebenssachverhalte nicht selten sehr viel komplexer als ein automatisierter Testfall es je sein könnte, so dass die Kritik der datenschutzrechtlichen Seite als unberechtigt zurückgewiesen wird.^[2]

Spätestens in Anbracht der Weiterentwicklung des Risikomanagementsystems (RMS)^[3] erscheint klar, dass eine Weiterentwicklung diesbzgl. automatisierter Verfahren weder nur ausnahmsweise, noch unter zusätzlichen Schutzvorkehrungen, sondern regelhaft erfolgen muss und darf. Ob die Einbeziehung von personenbezogenen Daten in dieses System eine Profiling-Maßnahme darstellt, die ggf. nach Art. 4 Abs. 4, 22 DSGVO zu rechtfertigen wäre, sei dahingestellt.^[4]

Wäre das Ergebnis der Datenverarbeitung die Risikoklassifizierung eines jeden Stpfl., so wäre dies näher zu untersuchen. Das Risikomanagement stellt aber eher abstrakte und anhand von Echtfällen abgeleitete Plausibilitätsregeln auf, die im Falle eines Verstoßes zu einer personellen Nachprüfung führen können.

Rz. 30

Die Verarbeitung personenbezogener Daten wird in Fällen des § 29c Abs. 1 S. 1 Nr. 4 Buchst. a) AO dann zuzulassen sein, wenn nicht sichergestellt werden kann, dass "künstliche" Testfälle ein weitgehend ebenso zuverlässiges Weiterentwicklungs- und Testergebnis ergeben, wie "Echtdaten". In aller Regel wird man dies wohl nicht annehmen können, sodass die Praxis der IT-Abteilungen, Echtdaten aus der Produktionsumgebung zu Weiterentwicklungs- und Testzwecken auf entsprechende Testserver zu spiegeln, nicht zu beanstanden sein dürfte. Für die laufende Fehlerbehebung im Falle eines Anwenderfehlers oder einer technischen Fehlfunktion müssen die personenbezogenen Daten sichtbar gemacht werden, da anderenfalls der Fehler nicht sichtbar gemacht bzw. nicht nachgestellt werden kann.

Allerdings kann diese Sicht nicht dazu führen, dass die so gewonnenen "Testdaten" für eine unbestimmte Anzahl von Entwicklungs- und Testanlässen genutzt und so für eine unbestimmte Dauer bereitgehalten werden. Hier ist zu fordern, dass diese Daten in regelmäßigen Abständen durch neue "Echtdaten" überschrieben werden mit der Folge, dass die alten Daten gelöscht werden. Keinesfalls dürfen diese Daten – vorbehaltlich des § 29c Abs. 1 S. 1 Nr. 6 AO – zu Schulungszwecken sichtbar gemacht oder gar genutzt werden. Mit der datenschutzrechtlichen Kritik ist hierfür mindestens die Pseudonymisierung der Daten zu fordern.

Rz. 31

§ 29c ...