Technische Security zu regulatorischen Anforderungen
NIS2, der Cyber Resilience Act, der EU AI Act und DORA verlangen von jeweils erfassten Organisationen oder Produkten konkrete Security-Arbeit: Risikoanalyse, Schwachstellenmanagement, sichere Entwicklung, Wirksamkeitsprüfungen, Schulung und mehr. Welche Vorgaben greifen, hängt vom Anwendungsbereich und von Übergangsfristen ab — nicht jedes Unternehmen muss alles erfüllen.
Neben gesetzlichen Pflichten gibt es vertraglich oder durch Kunden geforderte Standards sowie freiwillige Modelle zur Verbesserung der Security. Genau die technische Umsetzung mache ich seit Jahren. Compliance-Zertifizierung, Gap-Analyse auf dem Papier und formelle Freigaben gehören nicht dazu — das bleibt bei Ihrer Rechts- oder Compliance-Funktion.
Kurz: Die Regelwerke beschreiben, welche Security-Maßnahmen Sie brauchen. Ich helfe dabei, sie wirklich umzusetzen.
Überblick: vier EU-Regelwerke
| Regelwerk | Was es für Betroffene bedeutet | Mögliche Folgen bei Nichterfüllung |
|---|---|---|
| NIS2 | Erfasste Einrichtungen müssen Cybersicherheit risikogerecht steuern, Schwachstellen behandeln und geeignete organisatorische und technische Maßnahmen umsetzen. | Aufsichtsrechtliche Maßnahmen und mögliche Bußgelder, je nach Fall und nationaler Umsetzung. |
| DORA | Finanzunternehmen und bestimmte verbundene Akteure müssen digitale operationelle Resilienz aufbauen — vom IKT-Risikomanagement bis zu Tests und Incident-Handling. | Aufsichtsrechtliche Maßnahmen und Sanktionen nach den anwendbaren Vorschriften; es gibt keine einheitliche EU-Bußgeldgrenze. |
| Cyber Resilience Act | Für erfasste Produkte mit digitalen Elementen gelten Sicherheitsanforderungen über den Lebenszyklus, einschließlich sicherer Entwicklung und Schwachstellenbehandlung. | Erforderliche Produktnachbesserungen, mögliche Einschränkungen der Bereitstellung am Markt, Rücknahme oder Rückruf sowie mögliche Bußgelder. |
| EU AI Act | Für bestimmte KI-Systeme gelten zusätzliche Anforderungen an Risikomanagement, Robustheit und Cybersicherheit — insbesondere bei Hochrisiko-KI. | Erforderliche Abhilfemaßnahmen, mögliche Einschränkungen betroffener KI-Systeme und mögliche Bußgelder. |
Diese Folgen treten nicht automatisch ein; sie hängen von Anwendungsbereich, Sachverhalt und Aufsichtspraxis ab.
Risikoanalyse und Bedrohungsbewertung
Betroffene Organisationen sollen Risiken dokumentiert bewerten: Bedrohungen, Schwachstellen und die Wirksamkeit ihrer Maßnahmen.
Ohne nachvollziehbare Risikoanalyse bleiben Entscheidungen spekulativ: wichtige Angriffspfade bleiben unsichtbar, Maßnahmen greifen an der falschen Stelle, und bei Prüfungen fehlen belastbare Unterlagen.
In den Agile-Threat-Modeling-Workshops und im Attack-Tree-Quickstart entstehen dokumentierte Bedrohungsmodelle mit Akteuren, Angriffspfaden, Controls und Wirksamkeitsbewertung. Das ist ein konkreter technischer Beitrag — kein Ersatz für Ihre vollständige regulatorische Risikoanalyse.
Schwachstellen finden und bearbeiten
Erfasste Organisationen sollen Schwächen systematisch finden und in einem wiederholbaren Prozess abarbeiten.
Fehlt dieser Prozess, bleiben Angriffsflächen unerkannt, Findings stapeln sich ohne Priorität, und Vorfälle werden teurer und aufwändiger als nötig.
Attack Surface Mapping, Cloud Security Check und Container Platform Review liefern Findings mit Evidenz, Risikobewertung und Handlungsempfehlungen. Der Security Sparring Partner unterstützt bei der Priorisierung eigener Scan-Ergebnisse. Liegen Bedrohungsmodelle vor, lässt sich die Wirksamkeit umgesetzter Controls zusätzlich über Micro Attack Simulations prüfen.
Penetrationstests
Mehrere Regelwerke erwarten Wirksamkeitsprüfungen; eine allgemeine ausdrückliche Pentestpflicht ergibt sich daraus nicht überall.
Ohne realistische Tests bleibt unklar, ob Verteidigungen halten. Schwachstellen werden erst spät entdeckt — oft erst, wenn Nachbesserungen unter Zeitdruck und mit höherem Aufwand nötig werden.
Im Application Pentest und im API Security Check prüfe ich Anwendungen und APIs mit offensiven Techniken. NIS2 verlangt die Bewertung der Wirksamkeit von Maßnahmen, aber keine allgemeine ausdrückliche Pentestpflicht. DORA sieht Penetrationstests vor; Threat-Led Penetration Testing gilt nur für bestimmte Finanzunternehmen. Ein Application Pentest ist kein DORA-TLPT.
Supply Chain und Entwicklungsprozess
Für erfasste Organisationen und Produkte spielen sichere Entwicklung und Supply-Chain-Sicherheit eine zentrale Rolle.
Schwächen in Abhängigkeiten, Build-Pipelines oder Entwicklungsprozessen öffnen Angriffspunkte und können bei Produkten unter dem Cyber Resilience Act zu Nachbesserungen oder Einschränkungen der Marktbeteiligung führen.
Der Secure-SDLC-Process-Review bewertet den Entwicklungsprozess gegen etablierte Reifegradmodelle. DevSecOps-Pipeline-Coaching bringt Security-Scans in die CI/CD-Pipeline: SCA und SBOM, SAST, Container-Scans, KI-gestützte Code-Reviews. Das unterstützt Anforderungen aus NIS2 und dem Cyber Resilience Act. Ein einzelner Pipeline-Scan oder eine SBOM ersetzt die Gesamtpflicht nicht.
Security-Architektur und Systemdesign
Risikogerechte Schutzmaßnahmen sollen in Architektur und Systemdesign verankert sein.
Wird Security erst nachträglich ergänzt, entstehen teure Umbauten, unnötige Angriffsflächen und schwierige Nachweise gegenüber Aufsicht oder Kunden.
Security Architecture prüft Software- und Systemdesign unter Security-Gesichtspunkten. Zero Trust, Microservice-Isolation und Reviews von GenAI-Komponenten sind mögliche technische Umsetzungen — nicht Methoden, die jedes Regelwerk ausdrücklich vorschreibt.
Sicherheit von KI-Systemen
Für bestimmte KI-Systeme gelten zusätzliche Anforderungen an Risikomanagement, Robustheit und Cybersicherheit — abhängig von Anwendungsbereich und Übergangsfristen.
Unzureichend abgesicherte KI-Integrationen können zu Datenabfluss, Manipulation von Verhalten oder fehlenden Nachweisen führen. Agentische Systeme, RAG und MCP sind nicht automatisch Hochrisiko-KI.
Das Agentic-AI-Security-Assessment untersucht technische Angriffsflächen: Prompt Injection, Tool Poisoning, Datenabfluss, Memory-Manipulation und Goal Hijacking über LLM-Integrationen, RAG-Pipelines, MCP-Tools und agentische Architekturen. Es ist ein technischer Beitrag, keine vollständige Konformitätsprüfung.
Schulung und Security-Awareness
Schulung und Awareness tauchen in Gesetzen, Standards und Reifegradmodellen auf — Pflicht, Zielgruppe und Nachweis unterscheiden sich.
Fehlen passende Schulungen oder nachvollziehbare Lernergebnisse, bleiben Teams und Leitung unvorbereitet. Bei Standards und Kundenanforderungen können fehlende Nachweise Audits, Zertifizierungen beziehungsweise Testate oder vertragliche Anforderungen betreffen — nicht überall dieselben Folgen.
Auf Wunsch liefere ich ein Nachweispaket: Mapping der tatsächlich unterrichteten Module auf die von Ihnen benannten Anforderungen plus ein Quiz mit Bestehensgrenze. Das Paket liegt bei Ihnen; es erzeugt keine Compliance. Ein Quiz kann Lernergebnisse dokumentieren, beweist aber allein weder dauerhafte Wirksamkeit noch vollständige Konformität. Eine technische Entwicklerschulung ersetzt keine passende Leitungsschulung.
Dieses Paket tragen das Web Security Bootcamp, das Pentesting Training und die Custom Focus Sessions. Das Live-Hacking-Event ist Awareness für ein gemischtes Publikum, einschließlich Leitungsebene — nicht der Quiz-Pfad.
| Regelwerk oder Standard | Erwartung an Schulung | Mein Beitrag |
|---|---|---|
| NIS2 | Leitung soll Cybersicherheit verstehen; für Beschäftigte werden Cyberhygiene und rollenbezogene Schulungen erwartet, die Ausgestaltung hängt von der nationalen Umsetzung ab. | Mapping und Quiz zu den von Ihnen benannten Pflichten. Kein Compliance-Zertifikat. |
| DORA | Für betroffene Finanzunternehmen: Awareness und Resilienz-Schulung für Beschäftigte sowie angemessene Kenntnisse der Leitung; ein vereinfachter Rahmen kann eigene Regelungen haben. | Mapping des Mitarbeiter-Curriculums; Quiz dazu. Leitungsschulung nur, wenn diese Schiene gehalten wurde. |
| PCI DSS | Branchenstandard: Entwickler eigener Software brauchen regelmäßig Schulung zu sicherer Entwicklung und, falls eingesetzt, zu Sicherheitstestwerkzeugen. Folgen ergeben sich vor allem aus Zahlungsverkehrs- und Vertragsbeziehungen. | Mapping und Quiz für einen zugeschnittenen Entwicklerkurs. |
| BSI IT-Grundschutz | Standard/Rahmenwerk: Awareness, Schulung und nachvollziehbare Lernergebnisse; zusätzlich Schulung für Entwicklungsteams. | Mapping der Module; Quiz als Beitrag zur Dokumentation von Lernergebnissen. |
| OWASP SAMM | Freiwilliges Reifegradmodell: rollenbezogene Security-Schulung und möglichst ein Verständnisnachweis neben der Teilnahme. | Mapping plus Quiz als Verständnisprüfung; ersetzt keinen Teilnahmenachweis. |
| BSI C5 | Cloud-Sicherheitskatalog, oft vertraglich oder kundenseitig gefordert: Awareness, Schulung und Messung von Lernergebnissen sowie entwicklungsbezogene Schulung. | Mapping auf die von Ihnen als anwendbar erklärten Kriterien. |
| ISO/IEC 27001 | Managementsystem-Standard: Kompetenz und Awareness; Secure Coding je nach risikobasierter Auswahl der Controls. | Mapping auf die Controls, die Sie als anwendbar erklärt haben. |
Laufende Security-Beratung
Statt Expertise nur punktuell einzukaufen, gibt der Security Sparring Partner laufenden Zugang zu technischer Security-Beratung — näher an der kontinuierlichen Risikosteuerung, die viele Regelwerke und Standards erwarten.
Ich unterstütze die technische Umsetzung. Rechtliche Bewertung und formelle Konformitätsentscheidungen gehören nicht zum Leistungsumfang.