Open Banking und API-basierte Geschäftsmodelle haben die Art und Weise, wie Finanzdaten aggregiert, verarbeitet und genutzt werden, grundlegend verändert. Die technischen Möglichkeiten sind beeindruckend – doch sie bringen eine zentrale Verantwortung mit sich: den Schutz sensibler Finanzdaten. Für API-basierte Finanzdienstleister ist Informationssicherheit nicht verhandelbar. Sie ist das Fundament, auf dem Vertrauen, Geschäftsbeziehungen und letztlich das gesamte Geschäftsmodell ruhen.

Bei wealthAPI verarbeiten wir täglich Finanzdaten von über 3.500 Banken und Brokern. Als BaFin-regulierter Kontoinformationsdienst wissen wir: Die Frage ist nicht ob, sondern wie gut man Informationssicherheit umsetzt. Die ISO 27001-Zertifizierung war für uns deshalb auch kein Selbstzweck, sondern ein bewusster Schritt, um unsere technische Infrastruktur zu härten und unsere Prozesse systematisch zu formalisieren und kontinuierlich weiterzuentwickeln – auf einem Niveau, das den Anforderungen unserer Partner und der Regulatorik nicht nur genügt, sondern sie übertrifft.

Dieser Artikel beleuchtet, warum ISO 27001 für Fintech-Unternehmen unverzichtbar ist, welche technischen Herausforderungen auf dem Weg zur Zertifizierung zu meistern sind und zeigen, welche Erkenntnisse andere aus unserem Weg ziehen können.

 

 

Warum ISO 27001 mehr als „nur“ Compliance ist

Für viele Unternehmen beginnt die Auseinandersetzung mit ISO 27001 als Reaktion auf Kundenanfragen oder regulatorische Anforderungen. Das greift jedoch zu kurz. ISO 27001 ist weit mehr als eine Checkbox auf der Compliance-Liste. Es ist ein systematischer Ansatz, um Informationssicherheit ganzheitlich in die DNA eines Unternehmens zu integrieren.

 

Die regulatorische Realität

Beginnen wir mit der harten Wahrheit: In der Finanzbranche gibt es keine Verhandlungsspielräume bei der Datensicherheit. Als BaFin-regulierter Kontoinformationsdienst unterliegen wir bereits strengen Auflagen durch PSD2, DORA, ZAG und künftig FiDA. Doch regulatorische Compliance allein reicht nicht aus. Banken, Broker und institutionelle Partner erwarten von uns nicht nur die Erfüllung von Mindeststandards, sondern nachweisbare Exzellenz in der Informationssicherheit.

ISO 27001 bietet genau das: einen international anerkannten Standard, der zeigt, dass Sicherheit nicht reaktiv gehandhabt wird, sondern proaktiv, strukturiert und kontinuierlich verbessert wird. Für unsere Partner ist die Zertifizierung ein klares Signal: Hier arbeitet ein Unternehmen, das Sicherheit ernst nimmt – nicht nur auf dem Papier, sondern in jedem Prozess, jeder Codezeile, jeder Architekturentscheidung.

Der technologische Wettbewerbsvorteil

Was viele übersehen: ISO 27001 ist auch ein technologischer Katalysator. Die Implementierung eines Information Security Management Systems (ISMS) zwingt dazu, Systeme, Prozesse und Infrastrukturen kritisch zu hinterfragen und zu optimieren. Das hat bei uns zu konkreten technischen Verbesserungen geführt:

• Systematisches Risikomanagement: Anstatt ad hoc auf Bedrohungen zu reagieren, haben wir einen strukturierten Prozess etabliert, der Risiken identifiziert, bewertet und priorisiert behandelt.
• Incident Response Excellence: Unser mehrstufiger Incident Response Plan (P0 bis P3) stellt sicher, dass wir im Ernstfall blitzschnell und koordiniert reagieren können – von der ersten Meldung über die Eskalation bis zur Post-Mortem-Analyse.
• Datenschutz by Design: Durch die Klassifizierung unserer Daten (Confidential, Restricted, Public) und die Definition klarer Handling-Prozesse haben wir Datenschutz von Anfang an in unsere Systeme eingebaut.

Diese Verbesserungen sind keine theoretischen Konstrukte. Sie haben messbare Auswirkungen auf unsere Reaktionszeiten bei Incidents, die Qualität unserer Sicherheitsarchitektur und letztlich die Vertrauenswürdigkeit unserer gesamten Plattform.

 

Der Weg zur Zertifizierung: Technische Herausforderungen und Lösungen

Der Weg zur ISO 27001-Zertifizierung ist ein strukturierter, aber anspruchsvoller Prozess. Bei wealthAPI haben wir ihn nicht als notwendiges Übel betrachtet, sondern als Gelegenheit, unsere technische Infrastruktur systematisch zu durchleuchten und zu optimieren. Hier sind die größten Herausforderungen, denen wir begegnet sind – und wie wir sie gelöst haben.

 

1. Datenklassifizierung und Asset Management

In einem schnell wachsenden Fintech-Unternehmen werden regelmäßig neue Systeme, Datenbanken und Services hinzugefügt. Die Übersicht über alle Assets zu behalten und diese konsistent zu klassifizieren, ist alles andere als trivial.

Unsere Lösung: Wir haben eine dreistufige Datenklassifizierung implementiert (Confidential, Restricted und Public) und klare Regeln definiert, welche Daten in welche Kategorie fallen.

• Confidential: Username und Banking-Informationen, Transaktionsdaten im SEPA-Format, Wertpapier-Positionen, erkannte Verträge (abgeleitete PII)
• Restricted: Finanzdatenmaster (z.B. Aktienkurse, Fondsprofile), Spending-Kategorisierung (abgeleitet, nicht-PII), interne Policies
• Public: Marketing-Materialien, Produktbeschreibungen, externe Policies

Die technische Umsetzung erfolgte über ein zentrales Asset-Register in unserem ISMS, komplementiert von einem externen Daten-Inventory, um Daten auf IT-Services zu mappen Das ISMS nutzt hierbei eine automatische Inventarisierung der Cloud-Ressourcen kombiniert mit Tagging-Mechanismen in unseren Cloud-Infrastrukturen. Jedes neue System wird bei der Einrichtung klassifiziert und Data Owner sind explizit für ihre Assets verantwortlich.

Learning: Datenklassifizierung ist keine einmalige Übung. Parallel zur laufenden Echtzeit-Erfassung haben wir einen jährlichen Review-Prozess etabliert, um sicherzustellen, dass die Klassifizierungen aktuell bleiben und neue Datentypen (z.B. durch FiDA) korrekt eingeordnet werden.

 

2. Access Control und Least Privilege

In einem API-basierten Geschäftsmodell haben verschiedene Teams und Services Zugriff auf unterschiedliche Datenquellen und Systeme. Das Prinzip des „Least Privilege“ umzusetzen – jeder Nutzer und jedes System erhält nur die minimal notwendigen Rechte – erfordert granulare Kontrolle und kontinuierliches Monitoring.

Unsere Lösung: Wir haben eine mehrschichtige Access-Control-Strategie implementiert, die auf einem formalisierten Target Operating Model (TOM) basiert. Das TOM operationalisiert das „Need-to-Know“-Prinzip durch ein striktes Rollenmodell: Jede Rolle ist mit präzisen Datenrichtlinien verknüpft, die definieren, was diese Rolle sehen und bearbeiten darf. Wenn MitarbeiterInnen die Abteilung wechseln oder neue Aufgaben übernehmen, ändern sich die Zugriffsrechte automatisch – historische Zugriffsrechte gibt es bei uns nicht.

Konkret bedeutet das:

• Role-Based Access Control (RBAC): Zugriff wird ausschließlich über vordefinierte Rollen gesteuert, nicht über individuelle Nutzerberechtigungen. Neue MitarbeiterInnen erhalten automatisch die Rechte ihrer Rolle, bei Rollenwechseln werden alte Rechte sofort entzogen.
• Multi-Factor Authentication (MFA): Pflicht für alle Zugänge zu produktiven Systemen, inklusive VPN, Cloud-Konsolen und Admin-Tools.
• Zeitlich begrenzte Zugriffe: Für hochsensible Operationen (z.B. Produktions-Datenbank-Zugriff) werden temporäre, auditierte Zugänge mit automatischer Ablaufzeit vergeben.
• Zentrale Authentifizierung: Alle Systeme nutzen Google Services für die zentrale Authentifizierung, was das strikte Rollenkonzept technisch durchsetzt.
• API-Key-Management: Secrets und API-Keys werden zentral in einem Secrets-Management-System verwaltet und niemals im Code oder in Repositories gespeichert.

Learning: Access Control ist ein kontinuierlicher Prozess. Quartalsweise Reviews aller Zugriffsrechte stellen sicher, dass keine „Zombie-Accounts“ existieren und dass das Least-Privilege-Prinzip eingehalten wird. Die Formalisierung durch das TOM hat uns geholfen, aus einem anfangs eher impliziten „Need-to-Know“ ein messbares, auditfähiges System zu machen.

 

3. Verschlüsselung: At Rest und In Transit

Als Kontoinformationsdienst verarbeiten wir extrem sensitive Daten, die sowohl während der Übertragung als auch bei der Speicherung maximal geschützt werden müssen.

Unsere Lösung: Wir haben eine umfassende Verschlüsselungsstrategie implementiert, die auf unserer Cryptography Policy basiert und durch eine gekapselte Infrastrukturarchitektur verstärkt wird:

• Encryption at Rest: Alle Confidential-Daten werden mit AES-256 verschlüsselt. Das gilt für Datenbanken, Backups und jede Form der persistenten Speicherung. Unsere Backups sind zusätzlich mit Data-at-Rest-Encryption geschützt. Laptop-Festplatten aller MitarbeiterInnen sind mit Full-Disk-Encryption (FDE) geschützt.
• Encryption in Transit: Sämtliche Datenübertragungen über öffentliche Netze erfolgen über TLS 1.2 oder höher. Interne Kommunikation zwischen Microservices nutzt ebenfalls verschlüsselte Verbindungen.
• Encapsulated Infrastructure: Alle kritischen Komponenten – insbesondere unsere Datenbanken – laufen in eigenen, isolierten Netzwerken und sind von außen nicht erreichbar. Diese Netzwerksegmentierung reduziert die Angriffsfläche erheblich.
• Hosting in Frankfurt: Alle Systeme laufen auf Google Cloud in Frankfurt. Das stellt nicht nur GDPR-Compliance sicher, sondern gibt uns auch Zugriff auf moderne Google-Security-Services wie Intrusion Detection und Web Application Firewall.
• Separation of Systems: Wir trennen konsequent zwischen sensitiven und weniger sensitiven Systemen in unserer Infrastruktur. Diese Trennung ermöglicht es uns, Sicherheitsmaßnahmen präzise auf den jeweiligen Schutzbedarf zuzuschneiden.
• Key Management: Verschlüsselungskeys werden in einem dedizierten Key Management Service (KMS) gespeichert, mit automatischer Rotation und Audit-Logging.

Learning: Verschlüsselung ist nicht „set and forget“. Die Kombination aus Verschlüsselung und Netzwerksegmentierung bietet Defense-in-Depth: Selbst wenn eine Komponente kompromittiert wird, bleiben andere Systeme geschützt. Zusätzlich führen wir regelmäßige Penetration Tests durch, um Schwachstellen proaktiv zu identifizieren.

 

4. Incident Response und Business Continuity

Im Ernstfall, sei es ein Sicherheitsvorfall, ein Systemausfall oder eine Naturkatastrophe, muss jeder Handgriff sitzen. Doch ohne klare Prozesse und regelmäßiges Training ist Chaos vorprogrammiert.

Unsere Lösung: Wir haben einen mehrstufigen Incident Response Plan entwickelt, der auf vier Severity-Levels basiert.

• P0 (Critical): Aktiv ausgenutzte Schwachstellen, unmittelbare Bedrohung für Personen oder Systeme. Sofortige Eskalation an IT/Engineering Management.
• P1 (High): Wahrscheinliche Bedrohung, noch nicht aktiv ausgenutzt (z.B. verlorener Laptop ohne Verschlüsselung, Malware-Verdacht). Ticket-Erstellung und Management-Benachrichtigung.
• P2/P3 (Medium/Low): Verdachtsfälle oder Schwachstellen ohne unmittelbares Risiko. Strukturierte Untersuchung über das Ticket-System.

Jeder Severity-Level hat definierte Eskalationspfade, Kommunikationskanäle und Post-Mortem-Prozesse. Kritische Incidents durchlaufen eine Root-Cause-Analysis, um systemische Schwachstellen zu identifizieren und zu beheben. Zusätzlich haben wir einen Business Continuity & Disaster Recovery Plan implementiert, der sicherstellt, dass wir im Falle eines größeren Ausfalls innerhalb definierter Recovery Time Objectives (RTOs) wieder einsatzbereit sind.

Learning: Theorie und Praxis sind zwei Paar Schuhe. Wir führen quartalsweise Incident-Response-Übungen durch, in denen wir realistische Szenarien simulieren. Diese Übungen sind ein unverzichtbares Werkzeug, um unsere Reaktionsfähigkeit zu testen und Prozesse proaktiv zu verbessern. Lange bevor ein echter Vorfall eintritt.

 

5. Vendor Management und Third-Party Risk

Kein Fintech arbeitet isoliert. Wir nutzen Cloud-Provider, andere Multibanking-Partner, Analytics-Tools und weitere Drittanbieter. Jeder dieser Partner kann ein potenzielles Sicherheitsrisiko darstellen.

Unsere Lösung: Wir haben einen strukturierten Third-Party-Management-Prozess etabliert.

• Vendor Assessment: Vor der Einbindung eines neuen Dienstleisters führen wir eine Sicherheitsbewertung durch. Anbieter, die Confidential- oder Restricted-Daten verarbeiten, müssen nachweisen, dass sie unsere Sicherheitsstandards erfüllen (z.B. durch eigene ISO 27001-Zertifizierung).
• Vertragliche Verpflichtungen: Datenschutz- und Sicherheitsanforderungen sind fester Bestandteil aller Verträge, inklusive Audit-Rechte und Incident-Notification-Pflichten.
• Kontinuierliches Monitoring: Vendor-Risiken werden nicht nur bei Vertragsabschluss bewertet, sondern regelmäßig re-evaluiert.

Learning: Der Ausfall eines Drittanbieters kann schnell zum eigenen Problem werden. Wir haben gelernt, kritische Dependencies zu identifizieren und wo möglich Redundanzen zu schaffen.

 

Von der Zertifizierung zur gelebten Praxis

Eine ISO 27001-Zertifizierung zu erreichen ist das eine. Sie dauerhaft zu leben und kontinuierlich zu verbessern, ist das andere. Uns ist klar, dass ein Informationssicherheits-Managementsystem (ISMS) kein statisches Regelwerk sein darf, sondern ein lebendiges System, das sich mit dem Unternehmen weiterentwickelt.

Vier Grundüberzeugungen, die unsere Sicherheitskultur prägen

Bevor wir über konkrete Maßnahmen sprechen, ist es wichtig zu verstehen, welche Überzeugungen unseren Ansatz zur Informationssicherheit leiten. Diese vier Prinzipien sind das Fundament unseres ISMS:

• Sicherheit beginnt in der Organisation: Selbst wenn ein System eine exzellente Sicherheitsarchitektur hat, ist es wirkungslos, wenn diejenigen, die damit interagieren, nicht über die notwendigen Qualifikationen verfügen. Technologie allein schützt nicht. Menschen müssen verstehen, warum Sicherheitsmaßnahmen existieren und wie sie diese korrekt anwenden.
• Organisatorische Sicherheit bestimmt IT-Sicherheit: Sobald Mitarbeiter die Abteilung wechseln oder eine neue Rolle übernehmen, müssen sich ihre Zugriffsrechte ändern. Bei uns gibt es keine historischen Zugriffsrechte, sondern nur Rollenprofile. Diese organisatorische Disziplin ist die Voraussetzung dafür, dass technische Sicherheitsmaßnahmen greifen können.

• Sicherheit muss einem Design-Prinzip folgen: Die Berücksichtigung des Sicherheitsaspekts ist von entscheidender Bedeutung im Service-Design. Das liegt daran, dass es äußerst schwierig ist, bestehende Systeme nachträglich zu ändern. Security by Design ist kein Buzzword für uns, sondern gelebte Praxis: Jedes neue Feature, jeder neue Service wird von Anfang an mit Sicherheit im Fokus entwickelt.

• Menschen machen Fehler – ein Frühwarnsystem hilft: Menschen machen Fehler. Es ist daher notwendig, Systeme so zu gestalten, dass Fehler frühzeitig erkannt werden und ihre Auswirkungen auf die Sicherheit minimiert werden. Wir setzen auf mehrschichtige Kontrollen, automatisierte Alarme und eine Kultur, in der das Melden von Fehlern nicht bestraft, sondern als Chance zur Verbesserung gesehen wird.

 

Kultur der Informationssicherheit

Der größte Erfolgsfaktor für unser ISMS war die Schaffung einer Sicherheitskultur, die von allen MitarbeiterInnen getragen wird. Informationssicherheit ist nicht die alleinige Verantwortung des CTO oder des Security-Teams – sie ist Teil der täglichen Arbeit jedes Einzelnen.

Konkrete Maßnahmen:

• Security Awareness Training: Alle Mitarbeiter durchlaufen beim Onboarding und dann jährlich ein Security-Training, das von Phishing-Erkennung bis zu sicheren Passwort-Praktiken reicht.
• Clear Desk, Clear Screen Policy: Mobile Geräte werden nach 5 Minuten automatisch gesperrt, sensible Dokumente dürfen nicht unbeaufsichtigt auf Schreibtischen liegen.
• Code of Conduct: Unser Code of Conduct definiert klare Erwartungen an das Verhalten aller Mitarbeiter (online wie offline) und schafft ein Arbeitsumfeld, in dem Sicherheit und Respekt Hand in Hand gehen.
• Peer Reviews für alle Code-Änderungen: Kein Code gelangt in die Produktion, ohne dass mindestens ein anderer Entwickler ihn geprüft hat. Diese Peer Reviews sind ein zentrales Element unserer Qualitätssicherung und schließen Einzelfehlverhalten aus.
• Systematischer Einsatz von KI in der Qualitätskontrolle: sämtliche Code-Änderungen werden von KI auf Konsistenz und Schwachstellen geprüft
• Test-Driven Development: Wir setzen auf testgetriebene Entwicklung, um auch in einem dynamischen Umfeld hohe Qualität zu gewährleisten. Automatisierte Tests stellen sicher, dass Sicherheitsanforderungen kontinuierlich erfüllt werden.

Continuous Improvement

ISO 27001 fordert explizit einen kontinuierlichen Verbesserungsprozess (PDCA-Zyklus: Plan-Do-Check-Act). Bei wealthAPI haben wir diesen Ansatz verinnerlicht:

• Quartalsweise Risk Reviews: Das Management überprüft regelmäßig die Risikolandschaft und passt Maßnahmen an neue Bedrohungen an.
• Jährliche Policy Reviews: Alle Policies und Prozesse werden mindestens einmal jährlich auf Aktualität und Effektivität geprüft.
• Lessons Learned aus Incidents: Jeder Sicherheitsvorfall, egal wie klein, wird dokumentiert und analysiert. Die Erkenntnisse fließen direkt in Prozess- und Technologie-Verbesserungen ein.
• Enge Zusammenarbeit mit Partnern: Wir coachen unsere Kunden und Partner aktiv, um Mindestsicherheitsstandards zu gewährleisten. Sicherheit endet nicht an unserer Systemgrenze, sondern erstreckt sich über das gesamte Ökosystem.

 

FiDA, Open Wealth und die Zukunft der Informationssicherheit

Mit der kommenden Financial Data Access Regulation (FiDA) steht die nächste große Welle regulatorischer Veränderungen bevor. FiDA wird die Anforderungen an Finanzdatenaggregation und -schutz nochmals verschärfen und erweitern. Für wealthAPI ist das keine Bedrohung, sondern eine Chance.

FiDA-Readiness durch ISO 27001

Unsere ISO 27001-Zertifizierung ist ein entscheidender Baustein, um „FiDA-ready“ zu sein. Die durch das ISMS etablierten Prozesse – von der Datenklassifizierung über Verschlüsselung bis hin zum Vendor Management – decken bereits viele der erwarteten FiDA-Anforderungen ab.

Konkret bedeutet das:

• Erweiterte Datentypen: FiDA wird über reine PSD2-Zahlungskontendaten hinausgehen und auch Wertpapiere, Krypto, Versicherungen und mehr umfassen. Unsere flexible Datenklassifizierung ist bereits auf diese Vielfalt vorbereitet.
• Granulare Einwilligungsmanagement: ISO 27001 zwingt uns, genau zu dokumentieren, wer wann auf welche Daten zugreift. Diese Granularität ist essentiell für FiDA-konforme Consent-Management-Systeme.
• Incident Reporting: Die durch ISO 27001 etablierten Incident-Response-Prozesse ermöglichen uns, Sicherheitsvorfälle schnell zu erkennen, zu melden und zu beheben – eine zentrale FiDA-Anforderung.

Open Wealth als technologisches Versprechen

Bei wealthAPI verstehen wir „Open Wealth“ nicht nur als Marketingbegriff, sondern als technologisches Versprechen: Wir bringen die verschiedensten Finanzdaten an einen virtuellen Ort und machen sie für unsere Partner nutzbar – sicher, effizient und compliant.

ISO 27001 ist das Fundament dieses Versprechens. Ohne eine robuste Informationssicherheitsarchitektur bliebe Open Wealth eine Idee ohne tragfähige Basis. Mit ISO 27001 haben wir die Infrastruktur, die Prozesse und die Kultur, um dieses Versprechen tagtäglich einzulösen.

 

Fazit: Informationssicherheit als Enabler für Wachstum

Für API-basierte Finanzdienstleister wie wealthAPI ist ISO 27001 keine Option, sondern eine Notwendigkeit. Die Zertifizierung signalisiert nicht nur regulatorische Compliance, sondern technologische Reife, operative Exzellenz und eine Unternehmenskultur, die Sicherheit ernst nimmt.

Der Weg zur Zertifizierung war herausfordernd, aber er hat uns als Organisation stärker gemacht. Wir haben Prozesse optimiert, Systeme gehärtet und eine Sicherheitskultur etabliert, die uns für die Zukunft des Open Banking – FiDA, Open Wealth und darüber hinaus – bestens positioniert.

Bei wealthAPI sind wir stolz auf unsere Zertifizierung. Nicht weil sie ein Ziel war, sondern weil sie der Startpunkt für eine kontinuierliche Reise zu noch höheren Sicherheits- und Qualitätsstandards ist.

 

Konkrete Empfehlungen für andere Fintechs

Abschließend möchte ich einige konkrete Empfehlungen teilen, die aus unserer Zertifizierungsreise resultieren – Learnings, die anderen Fintechs den Weg erleichtern können:

• Starten Sie früh
  Warten Sie nicht, bis ein Partner oder Regulator ISO 27001 fordert. Je früher Sie mit dem Aufbau eines ISMS beginnen, desto natürlicher integriert es sich in Ihre Unternehmenskultur. Nachträgliches Aufsetzen ist deutlich aufwändiger und teurer.

• Sehen Sie es als Investition, nicht als Kostenfaktor
  Ja, eine ISO 27001-Zertifizierung kostet Zeit und Geld. Aber sie zahlt sich mehrfach aus: durch schnellere Partner-Onboardings, durch höhere Systemstabilität, durch verbesserte Incident-Response-Fähigkeiten. Bei wealthAPI hat sich die Investition bereits nach weniger als einem Jahr amortisiert.

• Holen Sie alle ins Boot
  Informationssicherheit ist keine IT-Aufgabe. Holen Sie von Anfang an alle Abteilungen mit ins Boot – von Sales über Legal bis hin zu Customer Success. Ein ISMS funktioniert nur, wenn es von allen gelebt wird.

• Automatisieren Sie, wo möglich
  Viele Aspekte eines ISMS lassen sich automatisieren: Access-Reviews, Vulnerability-Scans, Backup-Verifikationen, Compliance-Checks. Wählen Sie ein ISMS, das Ihnen diese Arbeit großteils abnimmt – auch wenn die Lizenz ggf. etwas teurer ist.