Compliance-Übersicht: NIS2, DSGVO, PCI DSS und Security Headers
Dieses Kapitel kartiert alle Security Headers auf die relevanten Compliance-Frameworks — mit einer vollständigen Compliance-Matrix und kopierfertige TOM-Vorlage für Audits.
Warum Compliance-Dokumentation für Security Headers entscheidend ist
HTTP Security Headers sind keine optionalen Extras — sie gehören zum Stand der Technik für Webanwendungssicherheit, den die Risikomanagement-Maßnahmen nach § 30 Abs. 2 BSIG einhalten sollen (NIS2-Richtlinie Art. 21, deutsche Umsetzung seit 06.12.2025 in Kraft). Fehlen sie bei einem Audit, sind zwei getrennte Folgen zu unterscheiden: Bußgelder nach § 65 BSIG richten sich gegen die Einrichtung (bis 10 Mio. EUR bei besonders wichtigen Einrichtungen). Davon getrennt trägt die Geschäftsleitung nach § 38 BSIG die Umsetzungs- und Überwachungspflicht und haftet bei schuldhafter Verletzung der eigenen Einrichtung auf Schadensersatz.
Dieses Kapitel liefert die vollständige Compliance-Matrix — welcher Header erfüllt welche regulatorische Anforderung — sowie eine kopierfertige TOM-Dokumentationsvorlage für Datenschutzbeauftragte und Auditoren. Die einzelnen Header-Kapitel vertiefen die technische Implementierung: SRI (Supply-Chain-Schutz), security.txt (Vulnerability Disclosure), DNS-Sicherheit (DNSSEC und CAA), TLS-Konfiguration (Kryptografie), Cache-Control (Datenschutz), Reporting API (Incident-Detection), Clear-Site-Data (Session-Hygiene) und Erweiterte Header (Infrastruktur-Härtung).
Header → Regulierung: Das vollständige Mapping
Die folgende Tabelle zeigt, welcher HTTP Security Header welche spezifische Anforderung aus welchem Compliance-Framework erfüllt. Die Referenzen können direkt in TOM-Dokumentationen und Audit-Berichten verwendet werden.
| Security Header | NIS2 Art. 21 | §30 BSIG | DSGVO Art. 32 | BSI IT-GS | ISO 27001 | PCI DSS |
|---|---|---|---|---|---|---|
| Content Security Policy | (2)(e) | (Nr. 5) | (1)(b) | APP.3.1.A21 | A.8.9, A.8.26 | 6.4.3 |
| HSTS | (2)(h),(j) | (Nr. 8) | (1)(a) | APP.3.1.A14 | A.8.24 | — |
| Sichere Cookies | (2)(h) | (Nr. 8) | (1)(b), Art. 25 | APP.3.1.A21 | A.8.24 | 6.5.10 |
| X-Frame-Options | (2)(e) | (Nr. 5) | (1)(b) | APP.3.1.A21 | A.8.26 | 6.5.9 |
| Referrer-Policy | (2)(a) | (Nr. 1) | Art. 5(1)(c) | CON.10 | A.8.9 | — |
| X-Content-Type-Options | (2)(e) | (Nr. 5) | (1)(b) | APP.3.1.A21 | A.8.9 | — |
| Permissions-Policy | (2)(e) | (Nr. 5) | Art. 25 | APP.3.1 | A.8.9 | — |
| CORP / COOP / COEP | (2)(e) | (Nr. 5) | (1)(b) | APP.3.1 | A.8.26 | — |
| Subresource Integrity | (2)(e) | (Nr. 5) | (1)(b) | APP.3.1 | A.8.26, A.8.28 | 6.4.3 |
| NEL (Network Error Logging) | (2)(c) | (Nr. 3) | — | APP.3.1 | A.8.15 | 11.6.1 |
| security.txt | (Art. 23) | (§32) | — | DER.2.1 | A.8.8 | — |
| DNSSEC + CAA | (2)(e) | (Nr. 5) | (1)(a) | APP.3.9 | A.8.24 | — |
| TLS 1.3 / Zertifikate | (2)(h) | (Nr. 8) | (1)(a) | TR-02102-2 | A.8.24 | 4.2.1 |
| Cache-Control | (2)(e) | (Nr. 5) | (1)(b) | CON.1 | A.8.9 | — |
| Clear-Site-Data | — | — | Art. 17, (1)(b) | — | A.8.24 | — |
| Erweiterte Header | (2)(e) | (Nr. 5) | — | APP.3.1 | A.8.9 | — |
BSI IT-GS = BSI IT-Grundschutz (Edition 2023). PCI DSS-Anforderungen 6.4.3, 6.5.9, 6.5.10 und 11.6.1 sind seit 31.03.2025 verpflichtend (nicht mehr optional). Zur Zitierweise: Die Buchstaben-Zählung a) bis j) gehört zur NIS2-Richtlinie, nicht zum BSIG; § 30 Abs. 2 BSIG verwendet die Nummern 1. bis 10. Die Zuordnung einzelner Header zu den Maßnahmen-Bereichen ist eine fachliche Einordnung, kein Gesetzeswortlaut.
Die sechs wichtigsten Compliance-Frameworks im Überblick
Je nach Branche und Unternehmensgröße sind unterschiedliche Frameworks relevant. Die gute Nachricht: Eine korrekt implementierte Security-Header-Konfiguration erfüllt die technischen Anforderungen aller sechs Frameworks gleichzeitig.
NIS2 / NIS2UmsuCG
- In Kraft: 06.12.2025 (Deutschland, §30 BSIG)
- Betroffen: rund 30.000 Einrichtungen in DE (rund 8.250 besonders wichtige, rund 21.600 wichtige), 160.000+ in EU
- Schwellenwerte: > 50 MA oder > 10 Mio. EUR Umsatz
- Bußgelder: Bis 10 Mio. EUR gegen die Einrichtung (§ 65 BSIG); 2 % Jahresumsatz erst ab mehr als 500 Mio. EUR Gesamtumsatz
- Besonderheit: Umsetzungs- und Überwachungspflicht der Geschäftsleitung (§ 38 Abs. 1 BSIG) — bei schuldhafter Verletzung Haftung gegenüber der eigenen Einrichtung (§ 38 Abs. 2 BSIG)
CRA (EU) 2024/2847
- In Kraft seit: 10. Dezember 2024
- Meldepflicht ab: 11. September 2026
- Alle Anforderungen ab: 11. Dezember 2027
- Betroffen: Produkte mit digitalen Elementen, SaaS, WebApps
- Bußgelder: Bis 15 Mio. EUR oder 2,5 % Jahresumsatz
DORA (EU) 2022/2554
- Voll anwendbar seit: 17. Januar 2025
- Betroffen: 21 Kategorien von Finanzentitäten + kritische IKT-Drittanbieter
- Schlüsselartikel: Art. 9 (IKT-Schutzmaßnahmen) direkt Header-relevant
- IT-Dienstleister: Können als kritischer IKT-Drittanbieter fallen
- 19 benannte CTPPs unter direkter ESA-Aufsicht (18.11.2025)
DSGVO Art. 32
- Gilt seit: 25. Mai 2018 — betrifft alle Unternehmen
- Art. 32: Geeignete technische und organisatorische Maßnahmen (TOM)
- Art. 25: Privacy by Design — Permissions-Policy erfüllt dieses Gebot
- Art. 5(1)(c): Datenminimierung — Referrer-Policy direkt zugeordnet
- Bußgelder: Bis 20 Mio. EUR oder 4 % Jahresumsatz
BSI IT-Grundschutz
- Aktuelle Edition: 2023 (gültig für alle Audits und Zertifizierungen)
- APP.3.1.A21: HTTP-Response-Header als Standard-Anforderung (SOLLTE)
- Grundschutz++: Preview seit 29.09.2025, parallel zu Edition 2023
- BSI Lagebericht 2025: Web-Angriffsflächen-Management wird Pflicht
- 119 neue Schwachstellen pro Tag (+24 % gegenüber Vorjahr)
PCI DSS 4.0.1
- Aktuelle Version: PCI DSS v4.0.1 (seit 11.06.2024)
- Pflicht seit: 31.03.2025 — alle Future-Dated Requirements jetzt verbindlich
- Req. 6.4.3: CSP + SRI auf Zahlungsseiten (Pflicht)
- Req. 11.6.1: Header-Monitoring mindestens wöchentlich (Pflicht)
- Wichtig: CSP allein reicht NICHT für Req. 6.4.3 (PCI SSC, 10.03.2025)
TOM-Dokumentationsvorlage für HTTP Security Headers
Diese Formulierungen können direkt in Ihre Dokumentation technischer und organisatorischer Maßnahmen (TOM) nach Art. 32 DSGVO übernommen werden. Passen Sie den Stand und die spezifische Konfiguration an Ihre tatsächliche Implementierung an.
Rechtlicher Hinweis: Diese Vorlage dient als Ausgangsbasis. Die Formulierungen müssen an Ihre spezifische Implementierung angepasst werden. Die tatsächliche Konfiguration muss mit den dokumentierten Maßnahmen übereinstimmen.
Transportverschlüsselung (HSTS)
Schutzziel: Vertraulichkeit gemäß Art. 32 Abs. 1 lit. a DSGVO
Sämtliche Datenübertragungen erfolgen ausschließlich über TLS-verschlüsselte Verbindungen (HTTPS). Der HTTP Strict Transport Security (HSTS) Header ist aktiviert mit einer Gültigkeitsdauer von mindestens 12 Monaten (max-age=31536000). Die Direktive includeSubDomains stellt sicher, dass auch alle Subdomains ausschließlich über HTTPS erreichbar sind. Diese Maßnahme verhindert Man-in-the-Middle-Angriffe und SSL-Stripping.
Content Security Policy (CSP)
Schutzziel: Integrität gemäß Art. 32 Abs. 1 lit. b DSGVO
Eine Content Security Policy ist implementiert, die das Laden von Ressourcen aus nicht autorisierten Quellen verhindert. Die Policy definiert explizit erlaubte Quellen für Scripts, Stylesheets, Bilder und andere Ressourcen. Inline-Scripts sind durch Nonces oder Hashes abgesichert. Diese Maßnahme minimiert das Risiko von Cross-Site-Scripting (XSS) Angriffen und damit verbundenem Datendiebstahl.
Sichere Session-Verwaltung (Cookie-Attribute)
Schutzziel: Vertraulichkeit und Integrität gemäß Art. 32 Abs. 1 lit. b DSGVO
Session-Cookies sind mit folgenden Sicherheitsattributen versehen: Secure (Übertragung ausschließlich über HTTPS), HttpOnly (kein Zugriff durch clientseitiges JavaScript) und SameSite=Strict (Schutz vor Cross-Site-Request-Forgery). Diese Konfiguration verhindert Session-Hijacking und Cookie-Diebstahl.
Clickjacking-Schutz (X-Frame-Options)
Schutzziel: Integrität gemäß Art. 32 Abs. 1 lit. b DSGVO
Der X-Frame-Options Header ist auf DENY bzw. SAMEORIGIN gesetzt. Zusätzlich ist die CSP-Direktive frame-ancestors konfiguriert. Diese Maßnahmen verhindern die Einbettung der Website in Frames Dritter und schützen vor UI-Redress-Angriffen (Clickjacking).
Referrer-Kontrolle (Referrer-Policy)
Schutzziel: Datenminimierung gemäß Art. 5 Abs. 1 lit. c DSGVO
Eine Referrer-Policy ist konfiguriert (strict-origin-when-cross-origin), die die Weitergabe von URL-Informationen an externe Websites auf das notwendige Minimum beschränkt. Sensible URL-Parameter werden nicht an Dritte übermittelt. Dies entspricht dem Datenminimierungsgebot der DSGVO.
Script-Integrität (Subresource Integrity)
Schutzziel: Integrität gemäß Art. 32 Abs. 1 lit. b DSGVO
Externe Ressourcen (JavaScript-Bibliotheken, CSS-Frameworks) werden durch Subresource Integrity (SRI) Hashes vor Manipulation geschützt. Bei Abweichungen vom erwarteten Hash wird die Ausführung blockiert. Dies ist zusätzlich Pflicht nach PCI DSS 4.0.1 Requirement 6.4.3 für Zahlungsseiten.
Security Misconfiguration ist jetzt Platz 2 — nicht mehr Platz 5
Die OWASP Top 10:2025 (8. Edition, finalisiert Januar 2026) stuft fehlende Security Headers deutlich höher ein als bisher. Das ist kein akademisches Ranking — Auditoren und Versicherungen referenzieren OWASP direkt in ihren Anforderungskatalogen.
Security Misconfiguration
OWASP beschreibt explizit: "The server does not send security headers or directives, or they are not set to secure values." Fehlende HTTP Security Headers sind damit ein offizieller Top-2-Risikofaktor.
Software Supply Chain Failures
Neue Kategorie in 2025 — von 50 % der befragten Security-Experten als Top-1-Risiko eingestuft. Adressiert CDN-Kompromittierung (wie der Polyfill.io-Angriff 2024), Dependency-Angriffe und Build-Pipeline-Manipulation. Subresource Integrity (SRI) ist die direkte technische Gegenmaßnahme.
Aktuelle Security-Header-Adoption im Web (HTTP Archive 2025)
Trotz klarer regulatorischer Anforderungen zeigen aktuelle Daten erhebliche Lücken in der Umsetzung. Wer heute alle empfohlenen Security Headers korrekt implementiert, gehört zur Spitzengruppe:
Quelle: HTTP Archive Security Chapter 2025, CISPA Browser-Konsistenz-Studie 2025
Wie steht Ihre Domain bei Compliance?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Was sind technisch-organisatorische Maßnahmen (TOM)?
Technisch-organisatorische Maßnahmen (TOM) sind die konkreten Schutzmaßnahmen, die ein Unternehmen gemäß Art. 32 DSGVO implementiert, um die Sicherheit der Verarbeitung personenbezogener Daten zu gewährleisten. HTTP Security Headers zählen zu den technischen Maßnahmen: HSTS sichert die Transportverschlüsselung, CSP schützt vor Code-Injection, sichere Cookie-Attribute verhindern Session-Hijacking. Diese Maßnahmen müssen schriftlich dokumentiert und bei Datenpannen und Audits nachgewiesen werden.
Welche Security Header sind für NIS2 relevant?
HTTP Security Headers sind NIS2-relevant, weil sie zum "Stand der Technik" für Webanwendungssicherheit zählen: Nach § 30 Abs. 2 BSIG sollen die Risikomanagement-Maßnahmen den Stand der Technik einhalten. Die wichtigsten Zuordnungen nach Maßnahmen-Bereich: CSP, X-Frame-Options, SRI und X-Content-Type-Options zahlen auf die Anforderungen an Sicherheit bei Entwicklung und Wartung ein, HSTS und sichere Cookies auf die Anforderungen an Kryptografie, die Referrer-Policy auf die Anforderungen an Sicherheitskonzepte (§ 30 Abs. 2 BSIG). Die Zuordnung einzelner Header zu diesen Bereichen ist eine fachliche Einordnung, kein Gesetzeswortlaut. Im deutschen NIS2UmsuCG (seit 06.12.2025 in Kraft) sind die Maßnahmen in § 30 BSIG geregelt; die Buchstaben-Zählung a) bis j) gehört zur NIS2-Richtlinie, § 30 Abs. 2 BSIG verwendet die Nummern 1. bis 10.
Brauche ich alle Header für PCI DSS?
Für PCI DSS 4.0.1 sind bestimmte Header verpflichtend: CSP und SRI sind für Requirement 6.4.3 (Script-Kontrolle auf Zahlungsseiten) seit dem 31. März 2025 Pflicht. X-Frame-Options bzw. CSP frame-ancestors sind für Requirement 6.5.9 (Clickjacking-Schutz) erforderlich. Sichere Cookies (Secure, HttpOnly, SameSite) decken Requirement 6.5.10 ab. Requirement 11.6.1 verlangt zusätzlich mindestens wöchentliches Monitoring der Header auf Zahlungsseiten auf unautorisierte Änderungen.
Wie dokumentiere ich Security Headers für Audits?
Für Audits (NIS2, ISO 27001, BSI IT-Grundschutz) benötigen Sie: 1) Eine schriftliche TOM-Dokumentation, die jede implementierte Maßnahme, das Schutzziel und die rechtliche Grundlage beschreibt. 2) Nachweise der aktuellen Konfiguration (Server-Konfigurationsdateien oder Screenshot der HTTP-Response-Header). 3) Regelmäßige Prüfnachweise (mindestens quartalsweise automatisierte Scans). Die TOM-Vorlage in diesem Kapitel bietet einen copy-paste-fähigen Ausgangspunkt, der an Ihre spezifische Implementierung angepasst werden muss.
Was droht bei fehlenden Security Headern nach NIS2?
Zwei getrennte Mechanismen. Erstens das Bußgeld: Bußgelder nach § 65 BSIG richten sich gegen die Einrichtung — bis 10 Mio. EUR bei besonders wichtigen, bis 7 Mio. EUR bei wichtigen Einrichtungen; die Umsatzvarianten (2 % bzw. 1,4 %) greifen erst ab einem Gesamtumsatz von mehr als 500 Mio. EUR. Zweitens die Organhaftung: Die Geschäftsleitung muss die Risikomanagement-Maßnahmen nach § 30 BSIG umsetzen und ihre Umsetzung überwachen (§ 38 Abs. 1 BSIG); verletzt sie diese Pflicht schuldhaft, haftet sie der eigenen Einrichtung auf Schadensersatz (§ 38 Abs. 2 BSIG). Operative Aufgaben können delegiert werden; die Überwachungspflicht weist § 38 Abs. 1 BSIG der Geschäftsleitung zu. Zusätzlich können Aufsichtsbehörden Auflagen erteilen und die Öffentlichkeit informieren; als letztes Mittel kann die zuständige Aufsichtsbehörde unzuverlässigen Geschäftsleitungen besonders wichtiger Einrichtungen die Ausübung ihrer Tätigkeit vorübergehend untersagen (§ 61 Abs. 9 Satz 2 Nr. 2 BSIG).
Deckt der Wolf-Agents Scanner Compliance-Anforderungen ab?
Ja, auf der technisch messbaren Ebene. Der Wolf-Agents Web Security Check prüft 166 Punkte, darunter alle compliance-relevanten Security Headers: HSTS, CSP, Sichere Cookies, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, CORP/COOP/COEP, SRI und weitere. Das Ergebnis dokumentiert den extern sichtbaren Konfigurationsstand zu einem Zeitpunkt und kann Ihre eigene Nachweisdokumentation ergänzen — es ist keine Konformitätsfeststellung. Das Wolf-Agents Web Scan Monitoring beobachtet diese Header alle 6 Stunden und meldet Änderungen. Nicht abgedeckt: die von PCI DSS geforderte Erkennung von Manipulationen an HTTP-Headern und Seiteninhalten, wie sie der Browser des Kunden erhält.