Lost in Translation : Fehler in Software durch fehlerbehaftete Kommunikation
Neben dem „ganz normalen Wahnsinn“ können Probleme bei der Software-Entwicklung auch durch fehlerbehaftete Kommunikation zwischen Menschen und Maschinen oder Menschen untereinander entstehen. Sprachbarrieren beim Outsourcing sowie der Einsatz künstlicher Intelligenz (KI) fördern solche Fehlerquellen erheblich.
Von Franz Ammann und Aleksandra Sowa, Bonn
„Softwarefehler“, gab der Landeswahlleiter als Erklärung bekannt, nachdem am 1. September 2024 nach den Landtagswahlen in Sachsen eine Korrektur der Sitzverteilung notwendig geworden war. Dieser zunächst nicht näher spezifizierte „Softwarefehler“ in der Wahlsoftware hatte zu einer fehlerhaften Verteilung der Mandate geführt – nach der Korrektur erhielten zwei Parteien jeweils ein Mandat weniger als ursprünglich berechnet / bekannt gegeben.
Der „Softwarefehler“ rief zudem Spekulationen über eventuelle bewusste Manipulationen hervor. Es wurde auch die Möglichkeit diskutiert, dass in der Wahlsoftware – offenbar ein Produkt eines externen IT-Dienstleisters – die kurz zuvor vom Landtag beschlossene Änderung des Berechnungsverfahrens vom D’Hondt-Verfahren auf das Sainte-Laguë-Verfahren nicht berücksichtigt wurde. Der Chaos Computer Club (CCC) forderte vom Landeswahlleiter sofort Transparenz über die eingesetzte Software, die Gewährleistung der Prüfbarkeit als Mittel demokratischer Kontrolle sowie generell den Einsatz von Open-Source- Software, die solche Anforderungen „per definitionem“ erfüllen würde [1]. Schließlich ergaben Recherchen von Correctiv [2], dass der „Softwarefehler“ vielmehr auf eine fehlerhafte Eingabe und ein Datenverarbeitungsproblem zurückzuführen war, was zu einer falschen Berechnung führte. Correctiv stellte klar, dass es sich dabei um technische und menschliche Fehler handelte, die anschließend transparent korrigiert wurden.
Einen Einblick in die Wahlsoftware gewährte der Wahlleiter aus Gründen der Informationssicherheit dennoch nicht – auch der für die Programmierung verantwortliche IT-Dienstleister wurde nicht benannt. Der Vorfall verdeutlichte jedoch noch ganz andere aktuelle Herausforderungen und Risiken für die IT-Sicherheit: Jeder Softwarefehler von heute ist eine potenzielle Sicherheitslücke von morgen. Dies zeigt, wie stark Softwarequalität und Softwaresicherheit zusammenhängen.
Das Vertrauen, dass eine Software das tut, was sie tun soll, bildet die Grundlage für die Entscheidung über ihren Einsatz. Das ist unabhängig davon, ob es sich um eine Excel-Tabelle zur Umrechnung von Wählerstimmen in Mandate oder eine komplexe Software wie künstliche Intelligenz (KI) handelt, die künftig womöglich über die Bearbeitung von Bürgergeld-Anträgen oder den Einsatz von Waffensystemen entscheidet. Eine „Malfunction“ birgt Sicherheitsrisiken: angefangen beim angeknacksten Vertrauen in die Demokratie bis hin zur Gefahr für das Leben von Menschen. Je leistungsfähiger technische Systeme werden, desto näher rückt der Punkt, an dem ein einfacher Fehler verheerend genug sein könnte, um die avisierten Vorteile zunichtezumachen.
Fehlerquellen: KI und Outsourcing
Die Auswirkungen von Softwarefehlern auf die Sicherheit wurden jüngst hauptsächlich durch zwei Trends verstärkt: zum einen durch Outsourcing, allem voran das Offshore-Outsourcing von IT-Entwicklungen, und zum anderen durch die Bemühungen, die Softwareentwicklung oder zumindest das Coding an generative KI (genAI) zu delegieren. Bei beiden Trends geht es vor allem darum, Programmcode schneller und kostengünstiger zu entwickeln als hierzulande beziehungsweise durch menschliche Fachkräfte.
Laut Analysten von Statista Market Insights hat „Deutschland […] eine starke IT-Industrie, die viele qualifizierte Fachkräfte hervorbringt. Viele Unternehmen suchen jedoch nach Möglichkeiten, ihre IT-Kosten zu senken, indem sie auf externe Dienstleister zurückgreifen“ [3]. Der Umsatz im IT-Outsourcing-Markt wächst seit dem Jahr 2016 kontinuierlich und soll 2024 etwa 28,01 Milliarden Euro erreichen. Davon entfallen 6,17 Milliarden Euro auf den Bereich „Software-Application“ (die größten Umsatzanteile haben „Web Hosting“ und sonstiges IT-Outsourcing, der kleinste Anteil entfällt auf „Administration-Outsourcing“ – Tendenz steigend).
„Während die Technik immer leistungsstärker wird, sollten wir uns, was die Sicherheitstechnik betrifft, weniger auf den Ansatz Versuch und Irrtum verlassen“ [4], schrieb Max Tegmark in Leben 3.0 und riet dazu, in KI-Sicherheitsforschung zu investieren, bevor Unfälle passieren, Schwachstellen entstehen oder Systeme angegriffen werden können. Zwar gibt es keine 100-prozentige Sicherheit, doch sollten KI-Systeme zumindest möglichst unangreifbar sein, bevor man ihnen wichtige Infrastrukturen wie die Energieversorgung oder Waffensysteme anvertraut.
„Mit der zunehmenden Bedeutung der KI in der Gesellschaft erhöht sich auch der Einsatz für die Computersicherheit“, schrieb Tegmark. Komplexe Schwachstellen oder einfache Programmfehler könnten für Angriffe ausgenutzt werden, weswegen er als die wichtigsten Bereiche der KI-Sicherheitsforschung Verifizierung, Überprüfung, Sicherheit und Kontrolle nennt. Verifizierung sollte sicherstellen, dass eine KI wirklich das tut, wofür sie geschaffen beziehungsweise trainiert worden ist.
Damit rücken jedoch zwei weitere Aspekte in den Fokus der IT-Sicherheit: die Mensch-Maschine- Kommunikation (offenbar auch im Eingangsbeispiel der sächsischen Landtagswahl ein Problem) sowie die zwischenmenschliche (Fach-)Kommunikation verschiedener Beteiligter.
Übersetzungsfehler
Klassischer Software-Code ist algorithmische Mathematik und daher eindeutig – (natürliche) Sprache hingegen ist das nicht. Trotzdem muss es unser Ziel sein, Spezifikationen so präzise zu formulieren, dass Interpretationsspielräume möglichst vermieden werden. Die Übersetzung von Spezifikationen hat dabei nicht nur die Aufgabe, klare Anforderungen exakt zu übermitteln, vielmehr muss sie auch die unvermeidbare Ambivalenz von Formulierungen in die Zielsprache übertragen.
Es gibt viele – vielleicht zu viele – Möglichkeiten, durch die Übersetzung in eine andere natürliche Sprache Informationen zu verfälschen, sodass das Endprodukt nicht mehr den Erwartungen entspricht oder im schlimmsten Fall fehlerhaft ist. Möglicherweise handelt es sich auch bereits um Fehler in der (Fach-)Kommunikation – viele Missverständnisse oder falsche Übersetzungen ließen sich durch eine angemessene Kontextualisierung vermeiden.
Künstliche Intelligenz ist kein Algorithmus – ihre fachliche Funktionalität wird anhand von „Beispielen“ trainiert. Es wäre eine verfehlte Hoffnung, anzunehmen, KI-Systeme könnten Ungenauigkeiten und Ambivalenzen in einer Spezifikation ausgleichen. KI nutzt vielmehr die Spielräume, die sie lernt.
Darum gilt in beiden folgenden Entwicklungsszenarien: Redundanz schafft Sicherheit. Redundanz bedeutet hier nicht ein Übermaß an Worten, sondern liefert vielmehr unterschiedliche Blickwinkel auf einen Sachverhalt oder eine Anforderung. So kann man Übersetzern* und Softwareentwicklern die Sicherheit geben, Anforderungen richtig verstanden zu haben.
Das Versäumnis, von Anfang an für eine gute Kommunikation im Softwareentwicklungsprozess zu sorgen, kann zu einer Reihe von Problemen führen. Im schlimmsten Fall funktioniert die Software nicht wie vorgesehen oder so fehlerhaft, dass Prozesse nicht unterstützt oder sogar beeinträchtigt werden. Dadurch können auch Sicherheitslücken entstehen, die eine Software anfällig für Angriffe oder Datenlecks machen. Zudem führt das Neuaufrollen von Spezifikationen, um Kommunikations- und Übersetzungsfehler zu beheben, fast immer zu höheren Kosten und Verzögerungen. Eine fehlerhafte Software kann außerdem Reputationsschäden für das Unternehmen oder für die betroffene Fachabteilung nach sich ziehen.
Die im Folgenden näher erörterte Klassifizierung benennt die drei häufigsten Problemstellungen, ist jedoch naturgemäß nicht abschließend.
Unterschiedliches Verständnis der Messeinheiten
Ein prominentes Beispiel für das Problem unterschiedlich verwendeter Einheiten ist der Verlust des Mars-Climate-Orbiters im Jahr 1999 [4]: Bei der Berechnung der Schubkraft wurde die Umrechnung zwischen metrischen und imperialen Einheiten fehlerhaft implementiert. Dies führte dazu, dass die Sonde in die Marsatmosphäre eintrat und verglühte.
Das Problem mit unterschiedlichen Einheiten beschränkt sich jedoch nicht allein auf metrisch versus imperial: Auch US-amerikanische und britische (imperiale) Einheiten unterscheiden sich im Detail. Die daraus resultierenden Probleme – zum Beispiel in einer Software, die medizinische Dosierungen berechnen soll – könnten fatale Folgen haben.
Unterschiedliches Verständnis von Begriffen
Das unterschiedliche Verständnis von (technischen) Begriffen kann auf mehreren Ebenen problematisch sein. Einerseits existiert ein unterschiedliches Verständnis von eindeutig technischen Begriffen, die in verschiedenen Ländern und Sprachen zwar ähnlich klingen, aber unterschiedliche Bedeutungen haben. Andererseits kann es vorkommen, dass Begriffe, die nicht technisch gemeint sind, von Softwareentwicklern oder Übersetzern als technische Begriffe und damit als technische Anforderungen verstanden werden.
Ein Beispiel aus der Praxis verdeutlicht dies: Eine Anforderung formulierte, dass das Ergebnis einer Berechnung im Benutzerdialog als ganze Zahl darzustellen sei – gemeint war, dass Nachkommastellen für den Anwender irrelevant sind und daher nicht angezeigt werden sollten. In der Übersetzung wurde daraus jedoch die Anforderung „the value is integer“. Die Softwareentwickler programmierten daraufhin die Berechnungen mit Integer-Variablen, sodass in jedem Berechnungsschritt die Nachkommastellen verloren gingen – also abgerundet wurde. Dies führte zu Verfälschungen der Ergebnisse, welche die effektive Verwendung der Software beeinträchtigten. Zudem waren die Ergebnisse teilweise korrekt und teilweise nicht, was zusätzlich zur Verwirrung beitrug.
Edsger Dijkstra, ein Pionier der Informatik, drückte es treffend aus: „[…] program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. The only effective way to show the confidence level of a program significantly is to give a convincing proof of its correctness“ [6]. Im genannten Beispiel wurde das Problem der falschen Datentypen übrigens durch Tests mit Mersenne-Zahlen identifiziert.
Unterschiedliche kulturbedingte Kommunikation
Ein weiteres interessantes Fehlverhalten wurde durch eine ambivalente Formulierung verursacht. In der Anforderung hieß es sinngemäß: „Das Eingabefeld muss bei Bedarf ausgefüllt werden“. Gemeint war, dass das Feld nur dann ausgefüllt werden muss, wenn die Vorbelegung ausnahmsweise unzutreffend ist. Übersetzt wurde die Anforderung jedoch als „input is mandatory“. Dies führte in der fertigen Software zwar zu keinem technischen Fehler, wohl aber zu einer unkomfortablen Benutzererfahrung und abnehmender Akzeptanz: Auch Felder, deren Vorbeugung unverändert hätte übernommen werden können, verlangten nun bei jedem Durchlauf eine Eingabe. In diesem konkreten Fall mussten die Benutzer den bereits vorbelegten Wert erneut eingeben.
Dieses Missverständnis bei der Übersetzung der Softwareanforderung lässt sich als kulturelles Problem oder kulturelle Besonderheit betrachten: In einer eher liberalen Unternehmenswelt liegt der Schwerpunkt auf den Worten „bei Bedarf“ – in einer hierarchisch organisierten Gesellschaft (z. B. Indien) oder einem solchen Unternehmen wird hingegen das Wort „muss“ stärker betont. Unabhängig davon, ob diese kulturelle Interpretation zutreffend ist, führen ambivalente Formulierungen im Zweifel zu unerwünschten Ergebnissen. Daher sollte man eine konzeptionelle Eindeutigkeit anstreben, indem derselbe Sachverhalt aus verschiedenen Perspektiven beschrieben wird, um Übersetzenden und Softwareentwickelnden Sicherheit bei der Interpretation der Anforderungen zu geben.
Mehr Klarheit durch KI?
Fehler in der Interpretation, Übersetzung und letztlich in der Kommunikation sollten vermieden oder zumindest reduziert werden. Dafür ist es wichtig, bereits im Konzeptionsteam qualifizierte Übersetzer einzubeziehen. Nicht nur Softwareentwickler, sondern auch Übersetzer sollten Fachkenntnisse aus dem jeweiligen Bereich mitbringen, um Anforderungen und Texte im Kontext richtig und zuverlässig zu übersetzen. Idealerweise wird die Spezifikation bei Bedarf von Beginn an in einem mehrsprachigen Team erstellt, sodass sich potenzielle Missverständnisse bereits bei der Formulierung von Anforderungen erkennen und beseitigen lassen.
Tools für Übersetzungen oder das Management von Übersetzungen können helfen, die Qualität der übersetzten Anforderungen zu sichern und den Übersetzungsprozess zu optimieren. Dazu gehören heute natürlich auch KI-Tools wie DeepL oder ChatGPT. Allerdings entstehen dabei neue Risiken: Solche Textgeneratoren könnten gelegentlich „halluzinieren“ – das bedeutet, dass ein an sich plausibel und überzeugend wirkender Text nach der Bearbeitung durch die KI möglicherweise nichts mehr mit der ursprünglichen Anforderung zu tun hat. Auch eine KI-gestützte Übersetzung bedarf daher der Kontrolle durch ein qualifiziertes menschliches Team. Andernfalls besteht die Gefahr, dass menschliche Fehler lediglich durch KI-Fehler ersetzt werden – ohne dadurch eine wesentliche Verbesserung der Softwarequalität zu erreichen.
Maßnahmen zur Fehler-Vermeidung
Um sicherzustellen, dass eine Software wie gewünscht funktioniert, sind Tests – beispielsweise a priori vor der Inbetriebnahme – oder Penetrationstests (a posteriori, über den gesamten Lebenszyklus einer Software hinweg) eine weitverbreitete, von vielen IT-Herstellern bevorzugte Methode der Softwareprüfung und Verifizierung [5].
Pentests sind ein wesentliches und bewährtes, aber dennoch nicht hinreichendes Verfahren zur Überprüfung der Softwarequalität und -sicherheit. Sie sind unentbehrlich, wenn der Entwicklungsprozess oder der Softwarecode selbst im Verborgenen bleibt. Doch auch solche Tests bieten nur unvollkommene Beweise, wenn man sie nicht durch geeignete Maßnahmen und Kriterien zur Gewährleistung der Qualität und Sicherheit entlang des Softwareentwicklungsprozesses ergänzt. Hierzu sind die im Folgenden aufgeführten Standards und Verfahren – Stand heute – empfehlenswert.
Standards für Sicherheit und Qualität
Es gibt etablierte Standards für die Entwicklung sicherer und qualitativ hochwertiger Software. Dazu gehören die allgemeine Norm für Qualitätsmanagementsysteme ISO 9001 sowie die speziell für die Softwareentwicklung gedachte ISO/IEC/IEEE 90003:2018 „Software engineering – Guidelines for the application of ISO 9001:2015 to computer software“. Als Standard für Softwarequalität wurde die aktuelle ISO/IEC 25002:2024 „Systems and software engineering – Systems and software Systems and software Quality Requirements and Evaluation (SQuaRE) – Quality model overview and usage“ eingeführt, welche die frühere ISO 9126 „Quality Software Engineering“ ersetzt. Die ISO/IEC 27034-7:2018 „Information technology – Application security“ bleibt nach ihrer Revision im Jahr 2023 unverändert gültig.
Was die Sicherheit künstlicher Intelligenz betrifft, entwickelt die ISO derzeit neue Richtlinien: ISO/ IEC CD 27090 „Cybersecurity –Artificial Intelligence – Guidance for addressing security threats and failures in artificial intelligence systems“ befindet sich als Committee-Draft in Vorbereitung (www.iso.org/standard/56581.html). Zielgruppe dieses Standards sind sowohl Hersteller als auch Nutzer von KI: Die Norm bietet Leitlinien, um Sicherheitsbedrohungen und -fehler in KI-Systemen zu adressieren. Es geht dabei unter anderem um ein besseres Verständnis für die Konsequenzen von Sicherheitsbedrohungen für KI-Systeme über deren gesamten Lebenszyklus hinweg.
Ein weiteres Modell zur Qualität von KI-Systemen bietet ISO/IEC 25059:2023 „Software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Quality model for AI systems“ (www.iso.org/standard/80655.html). Diese definiert unter anderem Merkmale für die Spezifikation, Messung und Bewertung der Qualität von KI-Systemen. Diese ist nicht zu verwechseln mit der ISO/IEC-5259-Reihe, die sich auf Datenqualität für „Analytics and Machine Learning“ (ML) konzentriert und auf eine höhere Genauigkeit und Zuverlässigkeit von ML-Modellen abzielt (www.iso.org/standard/56581.html).
Programm- und Systemeinsatzverfahren
Programmeinsatzverfahren verankern entlang des Softwareentwicklungs- oder -beschaffungsprozesses sogenannte Quality-Gates, in denen zunächst eine Bewertung der relevanten Risiken bei der Verarbeitung personenbezogener Daten sowie der Sicherheit erfolgt – gefolgt von Überprüfung, Test und Freigabe einer Software im Hinblick auf den Einsatz und die Implementierung geeigneter (technischer und organisatorischer) Sicherheitsmaßnahmen. Solche Verfahren waren ursprünglich den sogenannten rechnungslegungsrelevanten Systemen vorbehalten. Sie dienten seit 1995 der Umsetzung der Grundsätze ordnungsmäßiger DV gestützter Buchführungssysteme (GoBS) und wurden 2015 in die GoBD [7] überführt und teilweise modernisiert.
Auch außerhalb des Geltungsbereichs für die Finanzverwaltung fanden Systemeinsatzverfahren Anwendung. Ein Beispiel ist das Privacy-and-Security-Assessment-Verfahren (PSA-Verfahren) der Deutschen Telekom AG [8], das ein „integriertes und standardisiertes Verfahren für technische Sicherheit und Datenschutz als fest verankerter Bestandteil in den Produkt- und Systementwicklungsprozessen“ zum Ziel hat [9].
Design-Grundsätze
„Security by Design“ war ein Bestandteil der Cyber-Sicherheitsstrategie 2016 der Bundesregierung und fordert IT-Hersteller dazu auf, Sicherheit „von Anfang an“ in die Entwicklung ihrer Produkte und Systeme einzubinden. Leider fehlt bis heute die Operationalisierung dieser Vorgabe, wie Dr. Gerhard Schabhüser, Vizepräsident des BSI, auf der Handelsblatt Jahrestagung Cybersecruity in Düsseldorf anmerkte.
Auch die Forderung nach Privacy by Design gemäß EU Datenschutzgrundverordnung (DS‑GVO), die ursprünglich als Datenschutzzertifikat vorgesehen war, wartet noch auf ihre Operationalisierung. Eine Verknüpfung beider Anforderungen in einem Verfahren wäre denkbar – doch auch hier fehlen bislang konkrete Vorschläge und Umsetzungsansätze.
Fazit
Warum ähnelt heutiger Computercode noch so sehr dem, was James Lovelock in Novacene [10] als „just most appalling Stuff“ bezeichnete? Einerseits sind viele Konzepte – wie Security by Design – trotz jahrelanger Diskussionen weiterhin nicht operationalisiert. Zudem sind weder relevante Standards noch Zertifizierungen für Sicherheit und Qualität verbindlich oder obligatorisch. Vielmehr zeigt sich ein Trend zur „Mikrogesetzgebung“: Technische Vorgaben werden zunehmend direkt in Gesetzen festgelegt, anstatt auf bewährte Standards zu verweisen – ein Umstand, der auch in der öffentlichen Anhörung zum NIS-2-Umsetzungsgesetz am 4. November 2024 kritisiert wurde.
IT- und KI-Hersteller haben ihre Ansätze zur Prüfung technischer Kriterien sogar zurückgefahren – Code- Inspektionen etwa gelten aufgrund ihrer Komplexität und des erforderlichen Fachwissens als schwer umsetzbar. Das Vorhandensein von Sicherheitsfunktionen wie Zwei-Faktor-Authentifizierung (2FA) wird zunehmend als unzureichendes Kriterien für die Sicherheitsbewertung betrachtet. Stattdessen setzen Hersteller vermehrt auf „prozessuale Kriterien“ wie Patch-Management und Penetrationstests, die langfristig ein verbessertes Qualitätsmanagement und eine erhöhte Sicherheit fördern sollen [11]. Das ursprünglich in der Cyber-Sicherheitsstrategie angekündigte IT-Sicherheits-Gütesiegel ist letztlich zu einem freiwilligen Sicherheits-Kennzeichen geworden.
„Sicherheit von Anfang an“ erfordert, die Sicherheit dort zu verankern, wo die Entwicklung beginnt – und das bedeutet: nicht erst mit der ersten Codezeile. Der Softwareentwicklungsprozess fängt viel früher an, nämlich mit der Spezifikation der fachlichen Anforderungen und ihrer Übersetzung in eine Sprache, die für die Entwickler verständlich ist.
Eine hundertprozentige Qualität über den gesamten Übersetzungsprozess zu gewährleisten, mag nie vollständig gelingen. Tests sind daher nicht nur entlang der Phasen der Softwareentwicklung unerlässlich, sondern auch im Übersetzungsprozess. Durch das Outsourcing und Offshoring von Softwareentwicklungsprojekten in nicht-deutschsprachige Länder ist eine Qualitätssicherung in der Design- und Konzeptionsphase (bspw. durch Schreibtischtests), notwendig geworden. In Projekten, die mehr als zwei Sprachen umfassen, potenziert sich das Risiko verlorener oder falsch verstandener Informationen.
Es gilt, wie Tegmark es ausdrückte, mehr Initiative zu zeigen und in Weiterentwicklung der Methoden zu investieren, anstatt nur zu reagieren [4].
Dr. Aleksandra Sowa ist zertifizierte Datenschutzbeauftragte, Datenschutzauditorin und IT-Compliance-Manager, Sachverständige für IT-Sicherheit sowie Mitglied im Leitungskreis der FG „Datenschutzfördernde Technik (Privacy-Enhancing Technologies)“ der GI e. V.
Dr. Franz Ammann war Senior Experte für IT-Strategie, Systemanalyse und Pflichtenhefterstellung bei der Deutschen Telekom IT GmbH.
Literatur
[1] Friedhelm Greis, CCC kritisiert Intransparenz bei Wahlsoftware, golem.de, September 2024, www.golem.de/news/softwarefehler-bei-landtagswahl-ccc-kritisiertintransparenz-bei-wahlsoftware-2409-188781.html
[2] Alice Echtermann, Viktor Marinov, Softwarefehler bei der Landtagswahl in Sachsen: Was hinter der Korrektur der Sitzverteilung steckt, Correctiv Faktencheck, September 2024, https://correctiv.org/faktencheck/2024/09/06/softwarefehler-bei-der-landtagswahl-in-sachsen-was-hinter-der-korrektur-der-sitzverteilung-steckt/
[3] Statista Market Insights, IT Outsourcing – Deutschland, April 2024, https://de.statista.com/outlook/tmo/it-services/it-outsourcing/deutschland#umsatz (kostenpflichtig)
[4] Max Tegmark, Leben 3.0, Mensch sein im Zeitalter Künstlicher Intelligenz, Ullstein, 5. Auflage, Januar 2019, ISBN 978-3-548-37796-4
[5] Aleksandra Sowa, Peter Duscha, Sebastian Schreiber, IT-Revision, IT-Audit und IT-Compliance, Neue Ansätze für die IT-Prüfung, Springer, 2. Auflage, April 2019, ISBN 978-3-658-23764-6
[6] Edsger W. Dijkstra, The humble programmer, in: ACM Turing award lectures, S. 1972, Januar 2007, ISBN 978-1-4503-1049-9, online verfügbar auf https://doi.org/10.1145/1283920.1283927
[7] Bundesministerium der Finanzen (BMF), Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD), BMF-Schreiben IV A 4 – 0316/19/10003:001 November 2019, https://ao.bundesfinanzministerium.de/ao/2023/Anhaenge/BMF-Schreiben-und-gleichlautende-Laendererlasse/Anhang-64/inhalt.html, geändert durch BMF-Schreiben IV D 2 – S 0316/21/10001:002, März 2024, www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Weitere_Steuerthemen/Abgabenordnung/AO-Anwendungserlass/2024-03-11-aenderung-gobd.html
[8] Stefan Pütz, Aleksandra Sowa, Privacy and Security Assessment, Eine standardisierte sicherheitstechnische und datenschutzrechtliche Freigabe für IT-Systeme, Datenschutz und Datensicherheit (DuD), Vol. 37, S. 40, Januar 2013, https://link.springer.com/article/10.1007/s11623-013-0010-8
[9] Deutsche Telekom AG, Privacy and Security Assessment Verfahren, Mai 2022, www.telekom.com/de/konzern/datenschutz-und-sicherheit/news/privacy-and-security-assessment-verfahren-342724
[10] James Lovelock, Novacene, The Coming Age of Hyperintelligence, Allen Lane, Juli 2019, ISBN 978-0-241-39936-1
[11] PwC, Strategy&, Konzeption eines IT-Sicherheits- Gütesiegels, Management Summary, April 2017, www.bmi.bund.de/SharedDocs/downloads/DE/veroeffentlichungen/themen/it-digitalpolitik/it-guetesiegel-summary.pdf