Security by Design in der IKT-Projektgovernance 2026

Das Projekt lag im Zeitplan, bis das Audit eine Frage stellte

Der CISO eines schnell wachsenden Zahlungstechnologieunternehmens hatte gute Nachrichten für das Leitungsorgan. Die neue Plattform für das Kunden-Onboarding war startbereit. Das Produktteam hatte die mobile Nutzererfahrung geliefert, die Entwicklung hatte die Identitätsprüfung integriert, die Rechtsabteilung hatte die Cloud- und API-Anbieter freigegeben, und der Betrieb hatte den Produktivsetzungsplan geprobt.

Dann stellte der interne Auditor eine einfache Frage:

„Zeigen Sie mir, wo Sicherheit und Datenschutz in jeder Projektphase berücksichtigt wurden.“

Im Projektraum wurde es still.

Es gab einen Bericht zu Penetrationstests, aber er wurde spät erstellt. Es gab ein Cloud-Architekturdiagramm, aber keinen Nachweis, dass die Datenflüsse anhand der GDPR-Grundsätze geprüft worden waren. Es gab einen Fragebogen zur Lieferanten-Due-Diligence, aber er war nicht mit dem Risikoregister verknüpft. Es gab ein Änderungsticket für die Produktivsetzung, aber die Genehmigung erwähnte keine Auswirkungen auf kritische Services, Vorfallmeldung, Resilienztests, Kundenbenachrichtigung oder Eskalation bei einer Verletzung des Schutzes personenbezogener Daten. Es gab Sprint-Notizen, aber die Sicherheitsanforderungen waren über User Stories und Chatnachrichten verteilt.

Nichts davon war offensichtlich fahrlässig. Alles sah nach einem geschäftigen modernen IKT-Projekt aus. Für ein Finanzunternehmen unter DORA, einen SaaS-Anbieter, der potenziell in den Geltungsbereich von NIS2 fällt, und einen Verantwortlichen oder Auftragsverarbeiter unter GDPR ging es jedoch nicht mehr nur darum, ob Sicherheit vorhanden war. Es ging darum, ob Security by Design nachweisbar war.

Das ist das Problem des Jahres 2026. IKT-Projekte werden nicht mehr nur nach Liefergeschwindigkeit, Kostenkontrolle und technischer Qualität beurteilt. Sie werden anhand von Governance-Nachweisen beurteilt: Risikobeurteilungen, Designentscheidungen, Lieferanten-Due-Diligence, Nachweise zur sicheren Entwicklung, Änderungsgenehmigungen, Datenschutzentscheidungen, Testergebnisse und Aufsicht durch das Management.

ISO/IEC 27001:2022 bietet Organisationen eine praxisnahe Managementsystemstruktur, um dieses Problem zu lösen. Sie hilft CISOs, Compliance-Managern, Projektsponsoren, DPOs, Architekten, Beschaffungsteams und Auditoren, wesentliche IKT-Projekte in belastbare Security-by-Design-Nachweise zu überführen.

Warum IKT-Projektgovernance heute ein Thema regulatorischer Nachweise ist

Eine Cloud-Migration, ein Kundenportal, eine Zahlungsplattform, eine CRM-Implementierung, ein Wechsel des Identitätsanbieters, eine Analysepipeline, eine API-Integration, ein SaaS-Workflow, eine Low-Code-Anwendung oder die Überführung zu einem Managed Service können das Risikoprofil der Organisation verändern. 2026 erfolgen solche Änderungen unter sich überschneidenden Verpflichtungen.

NIS2 gilt breit für wesentliche und wichtige Einrichtungen in den Sektoren nach Annex I und Annex II, einschließlich digitaler Infrastruktur, Managed Service Providers, Managed Security Service Providers und digitaler Anbieter. NIS2 Article 20 macht die Leitungsorgane für die Genehmigung von Maßnahmen des Cybersicherheitsrisikomanagements und die Überwachung ihrer Umsetzung verantwortlich. NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen für Risikomanagement, Behandlung von Sicherheitsvorfällen, Geschäftskontinuität, Sicherheit der Lieferkette, sichere Beschaffung, sichere Entwicklung, Behandlung von Schwachstellen, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Zugriffskontrolle, Asset-Management und sichere Kommunikation.

DORA gilt für Finanzunternehmen und konzentriert sich auf digitale operationale Resilienz. DORA Article 5 weist dem Leitungsorgan die Verantwortung für das IKT-Risikomanagement zu. DORA Article 6 verlangt ein solides, umfassendes und gut dokumentiertes Rahmenwerk für das IKT-Risikomanagement. DORA umfasst außerdem die Meldung IKT-bezogener Vorfälle, Tests der operationalen Resilienz, IKT-Geschäftskontinuität, Reaktion und Wiederherstellung, den Austausch von Informationen zu Cyberbedrohungen, IKT-Drittparteienrisikomanagement, vertragliche Regelungen und die Aufsicht über kritische IKT-Drittdienstleister.

GDPR ergänzt die Ebene der Rechenschaftspflicht für personenbezogene Daten. GDPR Article 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Verantwortliche müssen die Einhaltung von Grundsätzen wie Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht nachweisen können. Wenn eine Verarbeitung voraussichtlich ein hohes Risiko zur Folge hat, kann außerdem eine Datenschutz-Folgenabschätzung nach GDPR Article 35 erforderlich sein.

Der gemeinsame Nenner sind Nachweise. Aufsichtsbehörden und Auditoren fragen nicht nur, ob eine Plattform verschlüsselt, gepatcht, gescannt oder getestet wurde. Sie fragen, ob die Organisation zeigen kann, dass Sicherheit, Datenschutz, Lieferantenrisiko und Resilienz von Beginn an Teil der Entscheidungsfindung waren.

Deshalb ist ISO/IEC 27001:2022-Projektgovernance so wirksam. Sie ermöglicht der Organisation, NIS2, DORA, GDPR, NIST CSF 2.0, vertragliche Verpflichtungen und Programme zur Vertrauensbildung bei Kunden über einen wiederholbaren ISMS-Prozess zu steuern, statt über mehrere voneinander getrennte Checklisten.

Die ISO 27001-Struktur für Projektgovernance

ISO/IEC 27001:2022 wird häufig als reine Zertifizierungsübung missverstanden. Für IKT-Projekte ist ihr operativer Wert deutlich größer. Sie liefert eine Governance-Struktur für geschäftliche Veränderungen.

Die Abschnitte 4.1 bis 4.4 verlangen, dass Organisationen interne und externe Themen, interessierte Parteien, gesetzliche, regulatorische und vertragliche Anforderungen, den ISMS-Geltungsbereich, Schnittstellen und Abhängigkeiten verstehen. In Projektbegriffen bedeutet dies, dass der Projektauftrag betroffene Services, Kunden, Lieferanten, Vorschriften, Geschäftsprozesse, personenbezogene Daten, kritische Abläufe und ausgelagerte Dienstleistungen identifizieren sollte.

Die Abschnitte 5.1 bis 5.3 verlangen Führungsverantwortung, Ausrichtung an Richtlinien, Ressourcen, Integration in Geschäftsprozesse und zugewiesene Verantwortlichkeiten. Das ist relevant, weil NIS2 und DORA Cybersicherheit und IKT-Risiken jeweils in die Verantwortung des Leitungsorgans stellen. Ein Projekt, das eine kritische Kundenplattform verändert, kann sich nicht auf einen informellen Sicherheitskommentar in einem Chatverlauf stützen. Es benötigt klare Rechenschaftspflicht.

Die Abschnitte 6.1.1 bis 6.1.3 verlangen einen wiederholbaren Prozess für Risikobeurteilung und Risikobehandlung, Risikokriterien, Risikoverantwortliche, Bewertung von Vertraulichkeit, Integrität und Verfügbarkeit, Risikobehandlungspläne, Erklärung zur Anwendbarkeit und Genehmigung von Restrisiken. An dieser Stelle wird Projektrisiko zu Auditnachweis.

Die Abschnitte 7.1 bis 7.5 verlangen Ressourcen, Kompetenz, Sensibilisierung, Kommunikation und Lenkung dokumentierter Information. So werden Projektaufzeichnungen zu zuverlässigen Nachweisen statt zu verstreuten Artefakten.

Abschnitt 8.1 verlangt operative Planung und Steuerung, dokumentierte Information darüber, dass Prozesse wie geplant durchgeführt wurden, die Steuerung geplanter Änderungen, die Überprüfung unbeabsichtigter Änderungen, die Minderung nachteiliger Auswirkungen und die Steuerung extern bereitgestellter Prozesse, Produkte oder Dienstleistungen, die für das ISMS relevant sind. Die Abschnitte 8.2 und 8.3 verlangen Risikobeurteilungen und Risikobehandlung zur Informationssicherheit in geplanten Abständen oder bei wesentlichen Änderungen.

Annex A verbindet diesen Managementzyklus anschließend mit praktischen Maßnahmen. Für Security by Design in IKT-Projekten sind drei Maßnahmen aus ISO/IEC 27001:2022 Annex A zentral:

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap behandelt Informationssicherheit im Projektmanagement als Governance-Thema über alle Projekttypen hinweg, nicht nur in der Softwareentwicklung:

„Jedes Projekt – eine Migration eines Marketingsystems, ein Standortumzug, die Neugestaltung eines Geschäftsprozesses, eine HR-Onboarding-Plattform oder sogar eine Fusion oder Übernahme – kann die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen beeinflussen. Und wenn dies der Fall ist, muss Sicherheit am Tisch vertreten sein.“

Derselbe Abschnitt fasst die zentrale Umsetzungslehre zusammen:

„Ziel dieser Maßnahme ist nicht, Projekte mit Bürokratie zu belasten. Es geht darum sicherzustellen, dass Sicherheit als Designvorgabe behandelt wird, nicht als Testphase.“

Diese Unterscheidung trennt Compliance-Theater von belastbarem Security by Design.

Wie Security by Design innerhalb eines IKT-Projekts aussieht

Security by Design beginnt vor dem ersten Sprint, der ersten Beschaffungsanfrage, dem ersten Architekturdiagramm oder Migrations-Runbook. Es stellt eine einfache Frage: Was könnte dieses Projekt am Risiko verändern?

Ein praxistaugliches Modell für Projektgovernance nutzt sieben Nachweis-Gates.

Es geht nicht um Bürokratie. Es geht darum, Sicherheit dort sichtbar zu machen, wo Projektentscheidungen tatsächlich getroffen werden.

Die Clarysec Enterprise Informationssicherheitsleitlinie formuliert dies direkt:

„Security Governance ist mit Unternehmensführung, Projektmanagement, Beschaffung und rechtlichen Aufsichtsfunktionen zu integrieren, um sicherzustellen, dass Informationssicherheit nicht isoliert ist, sondern durchgängig in geschäftliche Entscheidungsprozesse eingebettet wird.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.5.

Sie macht außerdem Projektlebenszyklen zu einem Umsetzungsaspekt:

„Projektlebenszyklen (z. B. sichere Entwicklung, Bedrohungsmodellierung)“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.1.1.

Und sie hält den Audit-Grundsatz fest, den viele Organisationen zu spät erkennen:

„Alle implementierten Kontrollen müssen auditierbar sein und durch dokumentierte Verfahren sowie aufbewahrte Betriebsnachweise unterstützt werden.“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.6.1.

Mit anderen Worten: Sicherheitsarbeit, die nicht gesteuert, aufbewahrt und zugeordnet wird, fällt im Audit häufig durch, selbst wenn technische Teams vertretbare Entscheidungen getroffen haben.

Vom Bedrohungsmodell zum Nachweis: ein praktisches Fintech-Beispiel

Betrachten wir ein Projekt zur Einführung eines neuen EU-Kunden-Onboarding-Portals für ein Fintech. Das Portal erfasst Identitätsdokumente, führt eine biometrische Verifikation über einen Dritten durch, speichert den Onboarding-Status, integriert sich mit CRM, löst Kundenbenachrichtigungen aus und speist das Risiko-Scoring.

Ein Security-by-Design-Ansatz baut die Nachweise im Projektverlauf auf.

Erstens: Eröffnen Sie eine Aufzeichnung zur Sicherheitsklassifizierung des Projekts. Ermitteln Sie, ob das Projekt kritische oder wichtige Funktionen, personenbezogene Daten, besondere Kategorien personenbezogener Daten, Authentifizierung, kundenbezogene Verfügbarkeit, ausgelagerte IKT-Services, regulierte Meldeprozesse oder Kundenkommunikation betrifft. Nach GDPR sind biometrische Daten, die zur eindeutigen Identifizierung verwendet werden, eine besondere Kategorie personenbezogener Daten, sofern keine spezifische Ausnahme greift. Das erhöht unmittelbar das erforderliche Niveau der rechtlichen Analyse und der Schutzmaßnahmen.

Zweitens: Erstellen Sie eine Projektrisikobeurteilung. Die Clarysec SME Risikomanagement-Richtlinie macht Risikomanagement zu einem Bestandteil der Planung, nicht zu einer quartalsweisen Tabellenübung:

„1.2 Sie stellt sicher, dass Risikomanagement ein aktiver Bestandteil von Planung, Projektdurchführung, Lieferantenauswahl und Reaktion auf Informationssicherheitsvorfälle ist, ausgerichtet an ISO 27001, ISO 31000 und anwendbaren regulatorischen Anforderungen.“

Aus dem Abschnitt „Zweck“, Richtlinienklausel 1.2.

Für Unternehmensumgebungen definiert die Clarysec Enterprise Risikomanagement-Richtlinie den Geltungsbereich über Projekt- und technische Ebenen hinweg:

„Sie umfasst Informationssicherheitsrisiken auf strategischer, operativer, projektbezogener und technischer Ebene und ist für sämtliches Personal, Auftragnehmer und Dienstleister verbindlich, die an Tätigkeiten des Informationssicherheits-Managementsystems (ISMS) beteiligt sind.“

Aus dem Abschnitt „Geltungsbereich“, Richtlinienklausel 2.3.

Drittens: Führen Sie vor Beginn der Entwicklung ein Bedrohungsmodell durch. Die Enterprise Richtlinie für sichere Softwareentwicklung ist eindeutig:

„Alle neuen Anwendungen und wesentlichen Änderungen müssen vor Beginn der Entwicklung eine Sicherheitsarchitekturprüfung und Bedrohungsmodellierung durchlaufen.“

Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.

Für das Onboarding-Portal sollte das Bedrohungsmodell exponierte Schnittstellen, Identitätsflüsse, Berechtigungsgrenzen, API-Missbrauchsfälle, Webhook-Spoofing, Replay-Angriffe, kompromittierte Zugangsdaten, Pfade für Datenabfluss, Abhängigkeitsrisiken, Anforderungen an Protokollierung, Backup-Annahmen, Wiederherstellungsanforderungen und Ausfallmodi von Anbietern abdecken.

Viertens: Aktualisieren Sie die Datenschutznachweise. Die SME Richtlinie zu Datenschutz und Privatsphäre setzt die Basislinie:

„5.3.1. Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen muss in allen neuen Systemen und Services durchgesetzt werden.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.1.

Die Projektaufzeichnung sollte Zweck, Rechtsgrundlage, Rolle als Verantwortlicher oder Auftragsverarbeiter, Entscheidungen zur Datenminimierung, Aufbewahrungsregeln, Zugriffsrollen, Verschlüsselungsentscheidungen, Betrachtungen zu Auswirkungen auf betroffene Personen, Transparenzanforderungen, Bedingungen für Auftragsverarbeiter und Meldewege bei Verletzungen des Schutzes personenbezogener Daten enthalten.

Fünftens: Erfassen Sie Nachweise zur sicheren Entwicklung. Die SME Richtlinie für sichere Softwareentwicklung liefert eine knappe Nachweisliste, die für kleine und mittlere Teams funktioniert:

„5.3 Der General Manager (GM) muss Aufzeichnungen führen über: 5.3.1 alle aktiven Softwareentwicklungsprojekte und die verantwortlichen Entwickler oder Anbieter 5.3.2 die für jedes Projekt verwendeten Sicherheitschecklisten 5.3.3 durchgeführte Codeprüfungen und die Personen, die sie durchgeführt haben 5.3.4 Testergebnisse vor der Bereitstellung 5.3.5 Drittanbieter-Komponenten und ihren jeweiligen Lizenz- oder Risikostatus“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.

Sechstens: Steuern Sie die Bereitstellung als Änderung. Die SME Änderungsmanagement-Richtlinie legt fest:

„1.1 Diese Richtlinie stellt sicher, dass alle Änderungen an IT-Systemen, Konfigurationen, Geschäftsanwendungen oder Cloud-Services vor der Umsetzung geplant, risikobeurteilt, getestet und genehmigt werden.“

Aus dem Abschnitt „Zweck“, Richtlinienklausel 1.1.

Für das Onboarding-Portal sollte das Änderungsticket betroffene Services, Risikobeurteilung, Testergebnisse, Rollback-Plan, Überwachungsplan, Sicherheitsfreigaben, Datenschutzfreigabe, Lieferantenbereitschaft, Aktualisierungen zur Vorfalleskalation und Auslöser für Kundenkommunikation enthalten.

Abschließend: Ordnen Sie die Verpflichtungen zu. Die SME Richtlinie zur rechtlichen und regulatorischen Compliance liefert die operative Regel:

„5.2.2 Wenn eine Vorschrift mehrere Bereiche betrifft (z. B. GDPR betrifft Aufbewahrung, Sicherheit und Datenschutz), muss dies im Compliance-Register und in Schulungsmaterialien klar zugeordnet werden.“

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.2.

Dieses Compliance-Register wird zur Brücke zwischen ISO/IEC 27001:2022-Maßnahmen, Maßnahmen nach NIS2 Article 21, DORA-Pflichten zum IKT-Risiko, GDPR-Rechenschaftspflicht und Verpflichtungen aus Kundenverträgen.

Ein Projektnachweispaket NIS2, DORA, GDPR und NIST CSF 2.0 zuordnen

Die effizienteste Compliance-Strategie besteht nicht darin, Arbeit zu duplizieren. Sie besteht darin, einen starken Nachweissatz mehreren Verpflichtungen zuzuordnen.

Der Zenith Blueprint empfiehlt in der Phase Risikomanagement, Schritt 14, diese Art der Querverknüpfung:

„Für jede Vorschrift können Sie, sofern anwendbar, eine einfache Zuordnungstabelle erstellen (z. B. als Anhang in einem Bericht), die die wichtigsten Sicherheitsanforderungen der Vorschrift und die entsprechenden Kontrollen/Richtlinien in Ihrem ISMS aufführt.“

Er ergänzt, dass dies hilfreich ist, weil es Auditoren und Prüfern zeigt, „dass Sie Sicherheit nicht im luftleeren Raum steuern, sondern den rechtlichen Kontext kennen.“

Clarysecs Zenith Controls: The Cross-Compliance Guide unterstützt denselben integrierten Ansatz, indem ISO/IEC 27001:2022-Maßnahmen anderen Rahmenwerken, Auditerwartungen und Compliance-Anforderungen zugeordnet werden. Für IKT-Projektgovernance beschreibt er A.5.8, A.8.25 und A.8.32 als präventive Kontrollen, die Vertraulichkeit, Integrität und Verfügbarkeit über Governance, Anwendungssicherheit, Ökosystem, Schutz sowie System- und Netzwerksicherheitsbelange hinweg schützen.

Diese Tabelle ersetzt keine rechtliche Analyse. Sie ist ein Governance-Beschleuniger. Sie stellt sicher, dass CISO, DPO, Projektsponsor, Beschaffungsleitung, Systemverantwortlicher und interner Auditor auf dieselben Nachweise blicken.

NIST CSF 2.0 fügt sich ebenfalls nahtlos in dieses Modell ein. Seine GOVERN Function hilft Organisationen, Richtlinien, Rollen, Risikobereitschaft, Aufsicht und Kenntnis gesetzlicher oder vertraglicher Anforderungen zu etablieren. Seine Functions IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER helfen Teams, Assets, Lieferantendienste, Zugriffskontrolle, Datensicherheit, Plattformsicherheit, sichere Softwareentwicklung, Überwachung, Reaktion auf Sicherheitsvorfälle und Wiederherstellung in einer gemeinsamen operativen Sprache zu besprechen.

Ein einzelner, an ISO 27001 ausgerichteter Prozess mit Schwerpunkt auf Annex A.5.8 kann belastbare Nachweise für all diese Erwartungen erzeugen.

Sichere Entwicklung ist mehr als Code schreiben

Viele IKT-Projektfehler entstehen, weil die Organisation sichere Entwicklung als etwas betrachtet, das nur Entwickler tun. 2026 umfasst sichere Entwicklung auch SaaS-Konfiguration, Workflow-Automatisierung, Infrastructure as Code, API-Integrationen, Identitätsregeln, Cloud Landing Zones, Analysepipelines, Robotic Process Automation und Low-Code-Geschäftsanwendungen.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 20, behandelt ISO/IEC 27002:2022 control 8.25 Secure Development Life Cycle:

„Diese Maßnahme gilt unabhängig davon, ob Sie eigene Anwendungen schreiben, Plattformen wie ERP- oder CRM-Systeme konfigurieren, SaaS-Workflows anpassen oder Infrastructure-as-Code-Umgebungen verwalten.“

Er erläutert außerdem, dass Sicherheitsanforderungen neben funktionalen Anforderungen stehen müssen und dass Bedrohungsmodellierung hilft, exponierte Teile des Systems, riskante Benutzerrollen und Datenflüsse zu identifizieren, die höheren Schutz erfordern.

Für ein modernes Projekt können Nachweise zur sicheren Entwicklung Folgendes umfassen:

• Sicherheitsanforderungen, die mit Geschäftsanforderungen verknüpft sind
• Bedrohungsmodell oder Sicherheitsarchitekturprüfung
• Checkliste für sichere Programmierung oder sichere Konfiguration
• Aufzeichnungen zu Codeprüfung oder Peer-Review
• Komponenteninventar und Status von Abhängigkeitsrisiken
• Entscheidungen zum Management von Geheimnissen
• Design für Zugriffskontrolle und Prinzip der minimalen Berechtigung
• Anforderungen an Protokollierung und Überwachung
• Ergebnisse von Schwachstellenscans und Nachweise zu Abhilfemaßnahmen
• Sicherheitsprüfung in der Vorproduktion
• Backup-, Wiederherstellungs- und Resilienztests, soweit relevant
• Bereitstellungsgenehmigung und Rollback-Nachweise

Das Ziel ist nicht, jedes Projekt durch denselben schwergewichtigen Prozess zu zwingen. Das Ziel ist Verhältnismäßigkeit. Eine geringfügige interne Workflow-Änderung erfordert nicht dieselben Nachweise wie die Migration einer zentralen Zahlungsplattform. Aber jedes Projekt sollte nach seiner Auswirkung klassifiziert, risikobeurteilt und gesteuert werden.

Änderungsmanagement schützt das Projekt vor sich selbst

Der riskanteste Moment in vielen Projekten ist nicht Design oder Programmierung. Es ist die Bereitstellung.

Ein Team kann Bedrohungsmodellierung, Codeprüfung, Lieferantenbewertung und Datenschutzprüfung durchführen und dennoch durch eine überhastete Produktivänderung einen Ausfall oder eine Sicherheitsverletzung verursachen. Ein Debug-Flag bleibt aktiviert. Eine Firewall-Regel ist weiter gefasst als genehmigt. Ein Migrationsskript kopiert personenbezogene Daten in eine Nicht-Produktivumgebung. Ein Webhook-Endpunkt eines Drittanbieters wird ohne Authentifizierung bereitgestellt. Eine Änderung der Protokollierung zeichnet Nummern von Identitätsdokumenten auf. Ein Backup-Job fällt nach der Umstellung still aus.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 21, beschreibt ISO/IEC 27002:2022 control 8.32 Change Management sehr direkt:

„Änderung ist unvermeidlich, aber in der Cybersicherheit ist unkontrollierte Änderung gefährlich.“

Weiter heißt es:

„Im Kern ist wirksames Änderungsmanagement ein wiederholbarer Workflow. Er beginnt mit einem klaren Vorschlag, der beschreibt, was sich ändert, warum, wann und welche potenziellen Risiken bestehen.“

Eine belastbare IKT-Änderungsaufzeichnung sollte folgende Fragen beantworten:

• Welches System, welcher Service, welcher Datenfluss, welcher Lieferant oder welche Konfiguration ändert sich?
• Welche Risiken wurden identifiziert und wem gehören sie?
• Betrifft die Änderung personenbezogene Daten, kritische Services, Authentifizierung, Protokollierung, Backups oder Reaktion auf Sicherheitsvorfälle?
• Welche Sicherheits-, Datenschutz-, Resilienz- und Lieferantenprüfungen wurden durchgeführt?
• Welche Tests wurden vor der Bereitstellung abgeschlossen?
• Welche Überwachung bestätigt das erwartete Verhalten?
• Welcher Rollback- oder Wiederherstellungsplan besteht?
• Wer hat das Restrisiko genehmigt?
• Welche Nachweise werden aufbewahrt?

Für DORA unterstützt dies dokumentiertes IKT-Risikomanagement, Resilienz, Kontinuität, Vorfallklassifizierung und Lessons Learned. Für NIS2 unterstützt es Risikomanagementmaßnahmen, sichere Entwicklung, Vorfallsprävention und Kontinuität. Für GDPR hilft es nachzuweisen, dass Änderungen mit Auswirkungen auf personenbezogene Daten anhand der Grundsätze Zweck, Minimierung, Aufbewahrung, Zugriff und Sicherheit geprüft wurden.

Lieferanten- und Cloud-Entscheidungen müssen Teil des Projektdesigns sein

In modernen IKT-Projekten ist die risikoreichste Designentscheidung häufig „kaufen“ statt „bauen“. Cloud-Services, API-Anbieter, Plattformen zur Identitätsprüfung, Zahlungsabwickler, Analyseanbieter, Managed Service Providers und Managed Security Providers werden Teil der Risikooberfläche.

NIS2 umfasst ausdrücklich Sicherheit der Lieferkette, Schwachstellen direkter Lieferanten und Dienstleister, Cybersicherheitspraktiken von Lieferanten, sichere Entwicklungsverfahren und Ergebnisse koordinierter Risikobewertungen der Lieferkette. DORA geht für Finanzunternehmen weiter. Es verlangt IKT-Drittparteienrisikomanagement als Bestandteil des Rahmenwerks für das IKT-Risikomanagement, fortbestehende Verantwortung auch bei Auslagerung von IKT-Services, Informationsregister, Vorvertragsbewertungen, Analyse von Konzentrationsrisiken, Vertragskontrollen, Audit- und Prüfungsrechte, Auslöser für Vertragsbeendigung und getestete Exit-Strategien für kritische oder wichtige Funktionen.

Für das Onboarding-Portal darf der Anbieter für biometrische Verifikation nicht nur genehmigt werden, weil die Beschaffung den Preis attraktiv findet und die API-Dokumentation gut ist. Das Projekt benötigt Nachweise zu Sicherheits-Due-Diligence, Verarbeitungsrolle, Datenstandort, Unterauftragnehmern, Verfügbarkeitszusagen, Unterstützung bei Vorfällen, Auditrechten, Unterstützung bei der Vertragsbeendigung, Exit-Fähigkeit und Überwachungsverpflichtungen.

In einem ausgereiften Nachweismodell befinden sich Lieferanten- und Cloud-Entscheidungen im Projektnachweispaket, nicht in einem getrennten Lieferantenordner. Wenn der Auditor fragt, warum ein Dritter akzeptiert wurde, sollte die Antwort geschäftlichen Bedarf, Risikobeurteilung, vertragliche Schutzmaßnahmen, Datenschutzprüfung, Auswirkungen auf Resilienz und laufende Überwachung umfassen.

Wie Auditoren Security-by-Design-Nachweise prüfen

Unterschiedliche Auditoren betrachten dasselbe IKT-Projekt aus unterschiedlichen Blickwinkeln. Ein Zertifizierungsauditor, interner Auditor, DORA-Prüfer, eine zuständige NIS2-Behörde, ein Datenschutzauditor, ein NIST-orientierter Prüfer oder ein Auditor im COBIT-/ISACA-Stil kann ähnliche Nachweise anfordern, sie aber unterschiedlich interpretieren.

Auditoren wollen keine schöne Projektpräsentation. Sie wollen Nachvollziehbarkeit. Sie wollen sehen, dass Anforderungen zu Risiken geführt haben, Risiken zu Kontrollen, Kontrollen zu Umsetzungsnachweisen und die Umsetzung zu einer Überprüfung.

Deshalb ist Zenith Controls in der Auditvorbereitung hilfreich. Es unterstützt Teams dabei zu erklären, warum Annex A.5.8, A.8.25 und A.8.32 präventive Kontrollen sind, die Vertraulichkeit, Integrität und Verfügbarkeit schützen, bevor vorhersehbare Fehler die Produktion erreichen.

Das minimale Clarysec-Projektnachweispaket

Ein belastbares Security-by-Design-Nachweispaket muss nicht enorm umfangreich sein. Es muss konsistent, verhältnismäßig und zugeordnet sein.

Für ein IKT-Projekt mit mittlerem Risiko empfiehlt Clarysec typischerweise das folgende Mindestpaket:

1. Aufzeichnung zur Sicherheitsklassifizierung des Projekts
2. Hinweis zur regulatorischen Anwendbarkeit, der NIS2, DORA soweit relevant, GDPR und vertragliche Verpflichtungen abdeckt
3. Datenfluss- und Asset-Auswirkungsübersicht
4. Projektrisikobeurteilung und Risikobehandlungsplan
5. Bedrohungsmodell oder Sicherheitsarchitekturprüfung
6. Bewertung von Lieferanten und Cloud-Services, soweit anwendbar
7. Checkliste für sichere Entwicklung oder Konfigurationscheckliste
8. Ergebnisse von Sicherheitstests und Nachweise zu Abhilfemaßnahmen
9. Änderungsgenehmigung mit Rollback- und Überwachungsplan
10. Privacy-by-Design-Aufzeichnung, einschließlich Rechtsgrundlage und Aufbewahrung, wenn personenbezogene Daten betroffen sind
11. Aktualisierungen zu Incident Response und Überwachung
12. Prüfung nach der Implementierung und Lessons Learned
13. Zuordnung im Compliance-Register zu Kontrollen und Verpflichtungen

Der Zenith Blueprint liefert die Logik der Roadmap. Schritt 22 bringt Informationssicherheit in alle Projektphasen. Schritt 20 verankert sichere Entwicklung in Planung, Design, Code, Tests und Bereitstellung. Schritt 21 macht Änderungsmanagement strukturiert, nachvollziehbar und überprüfbar. Schritt 14 empfiehlt die Querverknüpfung von GDPR, NIS2, DORA und anderen Verpflichtungen, damit Compliance-Anforderungen nicht durch die Lücken fallen.

Die Richtlinien liefern die operativen Regeln. Die Informationssicherheitsleitlinie integriert Sicherheit mit Projektmanagement, Beschaffung und Rechtsaufsicht. Die Risikomanagement-Richtlinie macht Projektrisiken zu einem Bestandteil der ISMS-Aktivität. Die Richtlinie für sichere Softwareentwicklung verlangt Bedrohungsmodellierung. Die Änderungsmanagement-Richtlinie verlangt geplante, risikobeurteilte, getestete und genehmigte Änderungen. Die Richtlinie zu Datenschutz und Privatsphäre verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Die Richtlinie zur rechtlichen und regulatorischen Compliance verlangt, dass bereichsübergreifende Vorschriften im Compliance-Register zugeordnet werden.

Zusammen machen diese Werkzeuge aus Security by Design keinen Anspruch, sondern ein auditierbares Betriebsmodell.

Häufige Fehlermuster in IKT-Projekten

Die Fehler sind meist vorhersehbar.

Der erste Fehler ist die späte Einbindung der Sicherheit. Sicherheitsprüfungen erfolgen, nachdem die Architektur festgelegt, Verträge unterzeichnet und Liefertermine öffentlich kommuniziert wurden. Zu diesem Zeitpunkt wird Sicherheit zum Blocker statt zur Designvorgabe.

Der zweite Fehler sind fragmentierte Nachweise. Das Projekt hat Testergebnisse in einem Werkzeug, Lieferantenprüfung in einem anderen, Datenschutzkommentare in E-Mails, Risikoakzeptanz in einer Besprechungsaufzeichnung und Änderungsgenehmigung in einem Ticket. Kein durchgehender Strang belegt Governance.

Der dritte Fehler sind blinde Flecken bei Lieferanten. Das Projekt stützt sich auf einen Cloud-Service oder API-Anbieter, aber niemand prüft Unterauftragnehmer, Datenstandort, Auditrechte, Unterstützung bei Vorfällen, Exit-Pläne oder Konzentrationsrisiken.

Der vierte Fehler ist Datenschutzdrift. Ein System, das für einen Zweck gebaut wurde, beginnt Analyse, KI-Experimente, Marketing-Exporte oder operative Überwachung zu unterstützen, ohne Rechtsgrundlage, Transparenz, Minimierung oder Aufbewahrung erneut zu prüfen.

Der fünfte Fehler ist eine ungeprüfte Änderung. Eine Produktivsetzung wird hinsichtlich Funktionalität genehmigt, aber nicht auf Auswirkungen auf Zugriff, Protokollierung, Verschlüsselung, Backup, Resilienz, personenbezogene Daten oder Berichterstattung bewertet.

Der sechste Fehler ist schwache Aufsicht durch das Management. Projektrisiken mit hoher Tragweite werden auf zu niedriger Ebene akzeptiert, ohne Nachweis, dass der zuständige Risikoverantwortliche die regulatorischen Folgen verstanden hat.

Diese Probleme werden nicht durch den Kauf eines weiteren Scanners gelöst. Sie werden gelöst, indem Sicherheitsgovernance in die Art und Weise integriert wird, wie Projekte vorgeschlagen, entworfen, beschafft, umgesetzt, getestet, geändert und überprüft werden.

Die CISO-Kernaussage für 2026

Security by Design in IKT-Projekten ist heute ein Thema für Leitungsorgan, Audit und Aufsicht. NIS2 macht Cybersicherheitsrisikomanagement zu einer Angelegenheit des Leitungsorgans. DORA macht IKT-Risiko, Resilienztests, Vorfallmanagement und Aufsicht über Drittparteien zu einer strukturierten Verpflichtung im Finanzsektor. GDPR verlangt Rechenschaftspflicht für die Verarbeitung personenbezogener Daten und angemessene Sicherheit. ISO/IEC 27001:2022 liefert die Managementsystemstruktur, um diese Verpflichtungen operativ umzusetzen.

Für CISOs besteht die Chance darin, Projektteams nicht erst am Ende der Lieferung zu bekämpfen. Bringen Sie Sicherheit in Initiierung, Anforderungen, Design, Lieferantenauswahl, Umsetzung, Test, Änderungsgenehmigung und Prüfung nach der Implementierung.

Für Compliance-Manager besteht die Chance darin, verstreute Nachweise durch ein zugeordnetes Projektnachweispaket zu ersetzen.

Für Auditoren besteht die Chance darin, den Projektlebenszyklus zu prüfen, nicht nur das finale System.

Für Geschäftsverantwortliche besteht die Chance in schnellerer und sichererer Lieferung. Security by Design reduziert Nacharbeit, verhindert Überraschungen bei der Compliance, verbessert Lieferantenentscheidungen und gibt der Leitung eine belastbare Risikoerzählung.

Wenn Ihre IKT-Projekte schneller voranschreiten als Ihr Nachweismodell, beginnen Sie mit einem Pilotprojekt. Nutzen Sie Clarysecs Zenith Blueprint, um Security-Gates für Projekte zu definieren, wenden Sie Clarysec-Richtlinien für Risikomanagement, sichere Entwicklung, Änderungsmanagement und Datenschutz an, und nutzen Sie Zenith Controls, um ISO/IEC 27001:2022-Projektgovernance NIS2, DORA, GDPR und NIST CSF 2.0 zuzuordnen.

Clarysec kann Ihnen helfen, ein wiederverwendbares Security-by-Design-Projektnachweispaket aufzubauen, es an Ihrem ISMS auszurichten und es für internes Audit, Zertifizierungsaudit, DORA-Bereitschaft, NIS2-Governance und GDPR-Rechenschaftspflicht vorzubereiten.

Beginnen Sie mit Ihrem nächsten wesentlichen IKT-Projekt. Wenn es Systeme, Lieferanten, Daten, Zugriff, Resilienz oder Kundenvertrauen verändert, verdient es Security by Design ab dem ersten Tag.