Die vier Qualitätsstufen für geschäftskritische Software

Qualität ist nicht eine Sache, sondern vier Stufen

Wenn ein Unternehmen Software in Auftrag gibt, auf die es sich wirklich verlässt, Software, bei der ein Ausfall verlorenes Geld, einen Rechtsverstoß oder verlorene Kundschaft bedeutet, dann ist die schwierigste Frage nicht, welches Framework du nimmst. Die schwierigste Frage ist, was das Wort "Qualität" überhaupt heißt. Fast jeder Anbieter meint damit etwas anderes, und manche meinen damit gar nichts.

Du kennst die Phrasen. "Sicherheit auf Bankniveau." "Fintech Qualität." "Enterprise ready." Sie sollen das Prestige der regulierten Finanzwelt ausborgen, ohne etwas zu sagen, das du nachprüfen könntest. Meine Aufgabe hier ist, dieses Wort auseinanderzunehmen und als vier klar getrennte Stufen wieder zusammenzusetzen, damit du Marketinglärm von den Dingen unterscheiden kannst, die ein System tatsächlich am Leben halten.

Die vier Stufen sind: ein reguliertes Finanzinstitut zu sein, die Zertifizierungen zu halten, die ein seriöser Anbieter erwirbt, die Gesetze zu erfüllen, die bei uns greifen, und zu jener technischen Disziplin zu bauen, die Verlässlichkeit wirklich herstellt. Das ist keine Leiter, die du Sprosse für Sprosse hinaufsteigst. Die meisten Unternehmen berühren die erste Stufe nie, entscheiden bei der zweiten mit Bedacht, können die dritte nicht umgehen und leben oder sterben mit der vierten. Die Unternehmen in den Beispielen sind erfunden. Das Gesetz, die Zahlen und die Quellen sind in Fußnoten belegt.

Stufe 1: ein reguliertes Finanzinstitut sein

Die oberste Stufe ist gar kein Qualitätssiegel. Sie ist ein rechtlicher Status: ein konzessioniertes, beaufsichtigtes Finanzinstitut zu sein. Das ist eine Stufe, auf der ein Auftraggeber sitzen kann. Ein Entwickler wird nie zur konzessionierten Einheit, und wer behauptet, er sei eine, führt dich in die Irre.

Wenn du Kundengeld entgegennimmst und hältst, es im Auftrag der Kundschaft bewegst oder elektronisches Geld ausgibst, brauchst du höchstwahrscheinlich eine Konzession. In der Europäischen Union ist der Rahmen die zweite Zahlungsdiensterichtlinie, die Richtlinie (EU) 2015/2366, meist PSD2 genannt.¹ Sie setzt einen echten Eintrittspreis. Ein Zahlungsinstitut muss ein Anfangskapital von mindestens € 125.000 für die zentralen Zahlungsdienste halten, € 50.000, wenn es nur die Zahlungsauslösung anbietet, und € 20.000, wenn es nur Finanztransfers betreibt.¹ Ein Institut, das elektronisches Geld ausgibt, muss nach der Richtlinie 2009/110/EG mindestens € 350.000 halten.² Für Krypto Firmen gilt ein eigenes Regime, die Verordnung über Märkte für Kryptowerte, die Verordnung (EU) 2023/1114, die seit dem 30. Dezember 2024 vollständig gilt.³

Das Kapital ist nur der Anfang. Die Konzession bringt einen Eignungstest für die Geschäftsleitung, laufende Eigenmittelregeln, aufsichtsrechtliche Meldungen, die Sicherung der Kundengelder und eine Compliance Funktion, alles unter der Aufsicht einer Behörde. In Österreich ist diese Behörde die Finanzmarktaufsicht (FMA), in Deutschland die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) gemeinsam mit der Bundesbank, und im Vereinigten Königreich die Financial Conduct Authority (FCA).⁴⁵⁶ Die Regeln werden gerade neu geschrieben: Im Juni 2023 hat die Europäische Kommission eine dritte Richtlinie und eine unmittelbar geltende Zahlungsdiensteverordnung vorgeschlagen, die PSD2 ersetzen sollen.⁷

Stufe 1 beantwortet also eine Ja oder Nein Frage über das Unternehmen, keine Qualitätsfrage über den Code. Wirst du ein Zahlungsinstitut, nimmt dir keine noch so gute Technik die Konzessionspflicht ab, und wirst du keines, ist kein Mitbewerber "auf Bankniveau", nur weil er das behauptet. Wenn ich für einen Auftraggeber einen Zahlungsfluss baue, baue ich die Software zu dem Standard, den die Aufsicht erwartet, aber die Konzession hält der Auftraggeber, nicht ich. Die Phrase "fast Fintech" lege ich aus genau diesem Grund ab. Sie klingt nach einem Status und meint einen technischen Standard, und die beiden sollte man nie vermischen.

Stufe 2: die Zertifizierungen, die ein seriöser Anbieter erwirbt

Auf der zweiten Stufe wohnt die meiste Verwirrung, darum lies diesen Teil langsam.

Eine Zertifizierung wie SOC 2, ISO/IEC 27001 oder PCI DSS ist eine Aussage über eine Organisation, ausgestellt von einer akkreditierten, unabhängigen Stelle, die die Organisation beauftragt und bezahlt. Sie ist nichts, das ein Entwickler hält, mit dem Code übergibt oder für dich abhakt. Meine Aufgabe ist, Software zu bauen, die konform ist, und dich auf das Audit vorzubereiten. Das Zertifikat musst du erwerben, von jemandem, der nicht ich bin.

SOC 2 ist das klarste Beispiel. Es ist ein System and Organization Controls Bericht, definiert vom American Institute of Certified Public Accountants (AICPA) und an dessen Trust Services Criteria gemessen.⁸ Einen SOC 2 Bericht darf nur eine konzessionierte Wirtschaftsprüfungsgesellschaft nach den Attestierungsstandards des AICPA ausstellen, weshalb Fachleute sorgfältig von einer Attestierung statt von einer Zertifizierung sprechen.⁸ Ein Type II Bericht erfasst, wie die Kontrollen über einen Zeitraum funktioniert haben, meist sechs bis zwölf Monate, nicht nur eine Momentaufnahme. Die Mechanik beschreibe ich in meinem ausführlichen Beitrag zu SOC 2 Type II.

ISO/IEC 27001 ist die internationale Norm für ein Managementsystem der Informationssicherheit, aktuelle Ausgabe 2022.⁹ Zwei Geschwister erweitern sie für die Cloud Welt: ISO/IEC 27017 für Cloud Sicherheit und ISO/IEC 27018 für den Schutz personenbezogener Daten in öffentlichen Clouds.¹⁰¹¹ Auch hier ist die Linie klar. Die ISO schreibt die Norm, zertifiziert aber niemanden. Das macht eine akkreditierte Zertifizierungsstelle, und die ISO sagt das auf ihrer eigenen Seite.¹² Der Entwickler baut das Managementsystem und die Kontrollen. Der Auftraggeber bestellt die Zertifizierungsstelle.

PCI DSS, der Payment Card Industry Data Security Standard, gilt für jedes Unternehmen, das Karteninhaberdaten speichert, verarbeitet oder überträgt. Die aktuelle Fassung ist 4.0.1, veröffentlicht vom PCI Security Standards Council im Juni 2024, mit ihren neueren Anforderungen in Kraft seit dem 31. März 2025.¹³ Wie du validierst, hängt davon ab, wie viel Kartenverkehr du trägst: Ein kleinerer Händler füllt vielleicht einen Selbstauskunftsfragebogen aus, während die größten eine Prüfung vor Ort durch einen Qualified Security Assessor durchlaufen.¹³

Zwei ehrliche Punkte folgen daraus. Erstens kostet das Bauen zu einer benannten Norm echtes Geld beim Bau selbst, lange vor jedem Zertifikat. Prüfpfade, Zugriffskontrollen, dokumentiertes Change Management und das Sammeln von Nachweisen sind Arbeit, und diese Arbeit steckt im Preis, egal ob du je einen Prüfer rufst. Zweitens ist der Prüfer eine eigene Rechnung, die du direkt bezahlst, Jahr für Jahr, um das Zertifikat am Leben zu halten. ISO 27001, PCI DSS und der OWASP Application Security Verification Standard verdienen je einen eigenen Artikel, und die kommen noch. Für den Moment ist SOC 2 das durchgespielte Beispiel dafür, was eine Zertifizierung der Stufe 2 wirklich bedeutet.

Stufe 3: die Gesetze, die bei uns greifen

Die dritte Stufe ist nicht optional und kein Siegel. Das sind Pflichten, die kraft Gesetzes für dich gelten, wegen dem, was du tust, und wo du es tust, ganz gleich, ob je ein Prüfer beteiligt ist.

Vier sind für ein Softwareunternehmen, das Europa bedient, am wichtigsten. Der Digital Operational Resilience Act, die Verordnung (EU) 2022/2554, gilt seit dem 17. Jänner 2025. Er regelt die operationale Ausfallsicherheit für Finanzunternehmen in der EU und erreicht über Verträge auch deren Dienstleister für Informations und Kommunikationstechnik, wenn dein Auftraggeber also eine Bank oder eine Versicherung ist, landen DORA Klauseln bei dir.¹⁴ NIS2, die Richtlinie (EU) 2022/2555, legt Cybersicherheitspflichten für Cloud Dienste, Managed Service Provider und Online Marktplätze fest, mit Meldungen innerhalb einer Frist von 24 Stunden. Dazu habe ich einen vollständigen Leitfaden geschrieben, wen NIS2 erfasst und was sie verlangt.¹⁵ Die Datenschutz Grundverordnung, die Verordnung (EU) 2016/679, regelt personenbezogene Daten für fast alle, und die Lieferantenseite davon habe ich in wie du Dienstleister prüfst, bevor sie deine Compliance untergraben behandelt.¹⁶ Die starke Kundenauthentifizierung nach PSD2 und ihr technischer Standard, die Delegierte Verordnung (EU) 2018/389, entscheidet, wie die Kundschaft an der Kassa nachweisen muss, wer sie ist.¹⁷

Auch die Barrierefreiheit sitzt jetzt hier. Der European Accessibility Act, die Richtlinie (EU) 2019/882, gilt seit dem 28. Juni 2025 und nennt den verbrauchernahen eCommerce ausdrücklich unter den erfassten Dienstleistungen.¹⁸ Die Mitgliedstaaten haben sie in nationales Recht gegossen: Österreich mit dem Barrierefreiheitsgesetz, Deutschland mit dem Barrierefreiheitsstärkungsgesetz, beide seit demselben Datum in Kraft.¹⁹²⁰ Das praktische Ziel sind die Web Content Accessibility Guidelines 2.1 auf der Stufe AA, eine Norm des W3C.²¹ All das lege ich in meinem Artikel zu den Barrierefreiheitsanforderungen für eCommerce und SaaS dar, und der Cyber Resilience Act, den ich in einem eigenen Artikel behandle, legt Produktsicherheitspflichten obendrauf.

Die ehrliche Einordnung der Stufe 3 lautet: Du suchst sie dir nicht aus. Du findest heraus, welche dieser Gesetze für dein Unternehmen gelten, und du erfüllst sie, oder du trägst das Risiko einer Strafe. Gute Technik macht die Erfüllung günstiger und beweisbar, aber sie nimmt die Pflicht nicht weg.

Stufe 4: die technische Disziplin, die Verlässlichkeit wirklich herstellt

Die vierte Stufe braucht keine Konzession und kein Zertifikat, und sie ist die einzige, auf der mein Qualitätsanspruch ruht. Sie ist die technische Disziplin, die Software so baut, dass, soweit es menschenmöglich ist, nichts still und heimlich schiefgehen kann. Sie ist das, was die anderen drei Stufen unter sich voraussetzen, und hier trennen sich gute von lauten Anbietern.

Sie hat sechs Teile, und keiner davon ist exotisch.

Unveränderliche Prüfpfade. Jede Änderung an Geld, an Berechtigungen oder an Kundendaten hinterlässt einen Eintrag, der nachträglich nicht editierbar ist, sodass du immer beantworten kannst, wer wann was getan hat.

Richtigkeit durch Konstruktion. Geld wird nach dem Prinzip der doppelten Buchführung geführt, sodass die Bücher stimmen müssen. Vorgänge werden idempotent gemacht, das heißt, dieselbe Anfrage, die zweimal ankommt, nach einem Timeout oder einem Doppelklick, belastet die Kundschaft nie doppelt. Abstimmungsläufe laufen nach Plan und beweisen, dass die Zahlen in deinem System noch mit den Zahlen beim Zahlungsdienstleister übereinstimmen.

Zero Trust und geringste Rechte. Daten sind bei der Übertragung und im Ruhezustand verschlüsselt, Geheimnisse liegen in einem verwalteten Speicher statt im Code, Zugriff wird nach Rolle vergeben und überprüft, und die Aufgaben, die nicht bei einer Person liegen sollten, sind getrennt.

Change Management. Freigaben, ein Release Register, das festhält, was wann ausgeliefert wurde, und die Möglichkeit, das später zu beweisen. Das halte ich für das Herz beweisbarer Qualität und lege es in Compliance nachweisen mit Release Registern und Sicherheitstests pro Release dar.

Ausfallsicherheit. Hohe Verfügbarkeit, damit ein einzelner Fehler den Dienst nicht lahmlegt, und Notfallwiederherstellung mit einem genannten Recovery Time Objective, der längsten Zeit, die du ausfallen darfst, und einem Recovery Point Objective, dem meisten Datenverlust, den du dir leisten kannst. Sicherungen werden getestet, indem man sie zurückspielt, nicht nur angelegt.

Unabhängige Prüfung. Umfassende automatisierte Tests, zuerst geschrieben, über testgetriebene und verhaltensgetriebene Entwicklung, und darauf aufbauend ein unabhängiger Penetrationstest, bevor ein System ans Netz geht. So gebaute Software lässt sich auch leichter versichern, weil der Versicherer die Disziplin dahinter sieht.

Das ist die Stufe, die ich meine, wenn ich sage, ich baue geschäftskritische Software. Ich sage nicht, ich sei dazu zertifiziert, denn es ist eine Praxis, kein Stempel. Ich sage, es ist die Strenge, zu der ich baue, und ich kann dir das Release Register und den Bericht zum Penetrationstest zeigen, die es belegen.

Die vier Stufen auf einen Blick

Stufe	Was sie ausmacht	Worum es geht	Wer ausstellt oder durchsetzt	Meine Rolle
1. Reguliertes Institut	Eine rechtliche Konzession, Geld zu handhaben oder elektronisches Geld auszugeben	Das Unternehmen selbst	Eine Finanzaufsicht (FMA, BaFin, FCA)	Zum Standard der Aufsicht bauen, die Konzession hält der Auftraggeber
2. Zertifizierung	Eine geprüfte Aussage über die Kontrollen einer Organisation	Die Organisation	Eine akkreditierte Stelle, die der Auftraggeber zahlt (eine Prüfgesellschaft, eine Zertifizierungsstelle, ein QSA)	Konform bauen und dich vorbereiten, nie selbst halten
3. Gesetz	Eine Rechtspflicht, ausgelöst durch das, was du tust, und wo	Das Unternehmen, nach Tätigkeit	Behörden und Gerichte	So bauen, dass Compliance beweisbar ist, und klären, was gilt
4. Technische Disziplin	Die Praxis, die Ausfälle selten und behebbar macht	Die Software und das Vorgehen	Niemand, sie wird gezeigt, nicht verliehen	Das ist der Standard, zu dem ich baue und den ich belegen kann

Ein durchgespieltes Beispiel: eine Linzer Firma mit Kartenzahlung

Eine Linzer Firma verkauft eine Abo Box und ist so weit gewachsen, dass sie Kartenzahlungen direkt entgegennimmt und Namen, Adressen und Bestellverläufe von Zehntausenden Kundinnen und Kunden in Österreich und den Niederlanden hält. Welche Stufen berühren sie tatsächlich?

Stufe 1: keine. Sie verkauft eigene Waren und hält nie Kundengeld für jemand anderen, also ist sie kein Zahlungsinstitut und braucht keine Konzession. Würde sie später eine Geldbörse starten, die Kundenguthaben speichert, änderte das die Lage, und sie müsste zuerst mit der FMA reden.

Stufe 2: PCI DSS, ja, weil sie Karteninhaberdaten verarbeitet, und die Höhe der Validierung hängt von ihrem Kartenvolumen ab. SOC 2 oder ISO 27001 nur, wenn ein Geschäftskunde oder ein Partner es im Vertrag verlangt. Niemand drängt einem Shop, der direkt an Endkunden verkauft, heute ein Zertifikat auf, also sollte sie das als Verkaufsentscheidung behandeln, nicht als Reflex.

Stufe 3: die DSGVO sicher, weil sie personenbezogene Daten österreichischer und niederländischer Kundschaft hält. Der European Accessibility Act, weil sie online an niederländische Verbraucher verkauft. NIS2 fast sicher nicht, weil ein Shop, der eigene Waren verkauft, kein Online Marktplatz ist. DORA nein, weil sie kein Finanzunternehmen ist und keine Finanzkunden hat.

Stufe 4: alles davon. Hier wird das Geld tatsächlich geschützt, hier belastet die Kassa nicht doppelt, hier sind die Kundendaten verschlüsselt, und hier lässt sich ein schlechtes Deployment zurückrollen und erklären. Alles, worauf der Ruf des Shops ruht, lebt in Stufe 4.

Die ehrliche Antwort für diese Linzer Firma lautet also: zu Stufe 4 bauen, die Gesetze der Stufe 3 erfüllen, die gelten, PCI DSS auf der richtigen Ebene validieren und erst dann nach einem Zertifikat der Stufe 2 greifen, wenn ein Kunde es wirklich verlangt. Das ist ein ganz anderer und viel kostengünstigerer Plan als eine pauschale Forderung nach allem auf Bankniveau.

Welche Stufe brauchst du wirklich?

Für die meisten Unternehmen hat die Antwort dieselbe Form. Du brauchst die Technik der Stufe 4 ausnahmslos, denn sie macht die Software überhaupt erst vertrauenswürdig. Du brauchst jene Gesetze der Stufe 3, die für deine Tätigkeit und deine Kundschaft gelten, und aus denen kommst du nicht heraus. Eine Zertifizierung der Stufe 2 brauchst du nur, wenn ein Kunde, eine Branche oder ein Beschaffungsprozess sie wirklich verlangt, und du solltest sie bewusst verfolgen statt als Versicherung gegen ein vages Unbehagen. Und auf Stufe 1 gelangst du nur, wenn du selbst ein reguliertes Institut wirst, was eine strategische Entscheidung mit angehängter Kapitalanforderung ist, kein technisches Upgrade.

Den Fehler, den ich am häufigsten sehe, läuft in eine Richtung: Einem Unternehmen wird ein Zertifikat verkauft, das es nicht braucht, oder eine Phrase wie "Fintech Qualität" macht ihm Angst, während die Technik der Stufe 4, die seine Ausfälle tatsächlich verhindern würde, still übergangen wird. Ein Zertifikat an der Wand und ein System, das Kundschaft doppelt belastet, ist das Schlechteste aus beiden Welten. Gib für die Stufe aus, die das Risiko beseitigt, das du tatsächlich trägst.

Wie du die Behauptungen eines Anbieters liest

Weil die Worte nichts kosten, lerne, über sie hinwegzulesen. Sagt ein Anbieter "SOC 2 konform", lass dir den Bericht zeigen und prüfe, wessen Kontrollen er erfasst. Das SOC 2 eines Hosting Anbieters erfasst das Rechenzentrum, nicht die Anwendung, die dein Anbieter darauf gebaut hat, und das sind völlig verschiedene Dinge. Sagt ein Anbieter "zertifiziert", frag, wer der unabhängige Prüfer oder die Zertifizierungsstelle war und wann das Zertifikat abläuft, denn ein echtes hat beides. Sagt ein Anbieter, seine Software sei sicher und ausfallsicher, verlang die zwei Belege, die Stufe 4 beweisen: das Release Register, das zeigt, was wann ausgeliefert wurde, und den jüngsten Bericht zum Penetrationstest mit Befunden und Behebungen. Ein Anbieter, der zu dieser Disziplin baut, hat beides parat. Ein Anbieter, der Prestige ausborgt, wechselt das Thema.

Dieselben Fragen schützen dich in deiner eigenen Lieferkette. Dein Hosting, dein Zahlungsdienstleister und dein E Mail Dienst sitzen je auf irgendeiner eigenen Stufe, und sowohl unter NIS2 als auch unter der DSGVO können ihre Schwächen zu deiner Haftung werden. Schreib auf, welche Kontrollen ihre sind und welche deine, bevor du es wissen musst.

Die ehrliche Position

Ich bin kein Auditor, und ich halte weder SOC 2 noch ISO 27001 noch PCI DSS, weil diese Organisationen gehören und von unabhängigen Stellen ausgestellt werden, die ein Auftraggeber beauftragt und bezahlt. Ich bin kein reguliertes Finanzinstitut, und ich werde das nie andeuten. Was ich anbiete, ist Stufe 4: die technische Disziplin, die Software verlässlich macht, so gebaut, dass die Gesetze der Stufe 3, denen du gegenüberstehst, beweisbar sind und jedes Zertifikat der Stufe 2, das du verfolgen willst, erreichbar ist statt eines Neubaus entfernt. Lieber sage ich dir klar, welche Stufe du brauchst und welche nicht, als dir einen Stempel zu verkaufen.

Wenn du nicht sicher bist, welche Stufen dein Unternehmen erreichen, oder ob die Behauptung eines Anbieters von "Bankniveau" etwas bedeutet, buch den kostenlosen Workshop, und ich kartiere es mit dir. Die ersten zwei Wochen Arbeit gehen auf meine Rechnung.

Was du jetzt tun solltest

Arbeite das der Reihe nach durch. Erstens, liste auf, was deine Software wirklich tut: Hält sie Geld, verarbeitet sie Karten, hält sie personenbezogene Daten, bedient sie Verbraucher, bedient sie Finanzkunden? Zweitens, lies daraus die Gesetze der Stufe 3 ab, die folgen, und die Zertifizierungen der Stufe 2, die ein Kunde wirklich verlangt. Drittens, sei ehrlich, ob du überhaupt in Stufe 1 gehörst, denn die meisten Unternehmen gehören das nicht. Viertens, verpflichte dich, egal wie die Antworten oben ausfallen, auf Stufe 4, und verlange von deinem Anbieter, oder von dir selbst, das Release Register und den Penetrationstest zu zeigen. Die Stufe, die dich aufrecht hält, ist jene, für die dir niemand ein Zertifikat in die Hand drückt.

Footnotes

1. Europäisches Parlament und Rat, Richtlinie (EU) 2015/2366 über Zahlungsdienste im Binnenmarkt (PSD2), Artikel 5, 7 und 11, Amtsblatt L 337, 23. Dezember 2015, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32015L2366 ↩ ↩²

2. Europäisches Parlament und Rat, Richtlinie 2009/110/EG über die Aufnahme, Ausübung und Beaufsichtigung der Tätigkeit von E Geld Instituten, Artikel 4, Amtsblatt L 267, 10. Oktober 2009, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32009L0110 ↩

3. Europäisches Parlament und Rat, Verordnung (EU) 2023/1114 über Märkte für Kryptowerte (MiCA), Artikel 149 zu den Geltungsdaten, Amtsblatt L 150, 9. Juni 2023, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32023R1114 ↩

4. Finanzmarktaufsicht Österreich, Konzessionierung und Registrierung von Zahlungsdiensten, fma.gv.at, abgerufen am 13. November 2026, https://www.fma.gv.at/en/financial-service-providers/payment-institutions/licencing-and-registration-of-payment-services/ ↩

5. Bundesanstalt für Finanzdienstleistungsaufsicht, Zahlungsdienste und PSD2, bafin.de, abgerufen am 13. November 2026, https://www.bafin.de/EN/ ↩

6. Financial Conduct Authority, Payment Services Regulations 2017 and Electronic Money Regulations 2011, fca.org.uk, abgerufen am 13. November 2026, https://www.fca.org.uk/firms/payment-services-regulations-e-money-regulations ↩

7. Europäische Kommission, Vorschlag für eine Verordnung über Zahlungsdienste im Binnenmarkt, COM(2023) 367 final, 28. Juni 2023, EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:52023PC0367 ↩

8. American Institute of Certified Public Accountants, System and Organization Controls: SOC Suite of Services und die Trust Services Criteria, aicpa-cima.com, abgerufen am 13. November 2026, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services ↩ ↩²

9. Internationale Organisation für Normung, ISO/IEC 27001:2022 Informationssicherheit, Cybersicherheit und Schutz der Privatsphäre, Managementsysteme für Informationssicherheit, Anforderungen, iso.org, https://www.iso.org/standard/27001 ↩

10. Internationale Organisation für Normung, ISO/IEC 27017:2015 Leitfaden für Informationssicherheitskontrollen für Cloud Dienste, iso.org, https://www.iso.org/standard/43757.html ↩

11. Internationale Organisation für Normung, ISO/IEC 27018:2019 Leitfaden zum Schutz personenbezogener Daten in öffentlichen Clouds, iso.org, https://www.iso.org/standard/76559.html ↩

12. Internationale Organisation für Normung, Certification, iso.org, abgerufen am 13. November 2026, https://www.iso.org/certification.html ↩

13. PCI Security Standards Council, PCI DSS v4.0.1 und die offizielle Dokumentenbibliothek, pcisecuritystandards.org, abgerufen am 13. November 2026, https://www.pcisecuritystandards.org/document_library/ ↩ ↩²

14. Europäisches Parlament und Rat, Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA), Artikel 64 zur Geltung ab dem 17. Jänner 2025, Amtsblatt L 333, 27. Dezember 2022, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554 ↩

15. Europäisches Parlament und Rat, Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS2), Amtsblatt L 333, 27. Dezember 2022, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32022L2555 ↩

16. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩

17. Europäische Kommission, Delegierte Verordnung (EU) 2018/389 zur Ergänzung der PSD2 durch technische Regulierungsstandards für die starke Kundenauthentifizierung, Amtsblatt L 69, 13. März 2018, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32018R0389 ↩

18. Europäisches Parlament und Rat, Richtlinie (EU) 2019/882 über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen (European Accessibility Act), Artikel 31 zur Geltung ab dem 28. Juni 2025, Amtsblatt L 151, 7. Juni 2019, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32019L0882 ↩

19. Republik Österreich, Barrierefreiheitsgesetz (BaFG), BGBl. I Nr. 76/2023, in Kraft seit 28. Juni 2025, Rechtsinformationssystem des Bundes, https://ris.bka.gv.at/eli/bgbl/I/2023/76 ↩

20. Bundesrepublik Deutschland, Barrierefreiheitsstärkungsgesetz (BFSG), in Kraft seit 28. Juni 2025, gesetze-im-internet.de, https://www.gesetze-im-internet.de/bfsg/ ↩

21. World Wide Web Consortium, Web Content Accessibility Guidelines (WCAG) 2.1, W3C Recommendation, w3.org, https://www.w3.org/TR/WCAG21/ ↩