Compliance, Risiko & Informationssicherheits-Landschaft.

Framework-Cross-Walk

• ISO 27001 (ISMS). Prozess-orientiert. Annex A (2022-Revision) hat 93 Controls in 4 Themen (Organizational, People, Physical, Technological). Zertifizierbar. Stark in Europa.
• SOC 2 Type II. AICPA-getrieben. Trust-Services-Criteria: Security (CC), Availability, Confidentiality, Processing-Integrity, Privacy. Attestation-Report, keine Zertifizierung. Von US-Enterprise-Kunden gefordert.
• NIST CSF 2.0 (2024). Sechs Funktionen: Govern, Identify, Protect, Detect, Respond, Recover. Freiwilliges Framework; weit adoptiert als gemeinsame Sprache.
• NIST SP 800-53 rev 5. Detaillierter Control-Katalog unter CSF; für US-Federal-Systems verpflichtend.
• BSI IT-Grundschutz. Deutscher Bundesstandard. "Bausteine" mappen auf Compliance-Module. Mit Cross-Reference auf ISO 27001.
• PCI DSS 4.0. Cardholder-Data-Overlay. Zwölf Requirements; eng bei Segmentierung, Encryption, Logging. Verpflichtend für Processors / Merchants je nach Transaktions-Volumen.
• HIPAA / HITECH. US-Healthcare. Administrative + Physical + Technical Safeguards. Sektor-Overlay, kein vollständiges Programm.
• DORA (Digital Operational Resilience Act, EU, in Kraft 2025). Finanzsektor. ICT-Risk-Management, Incident-Reporting, Resilience-Testing, Third-Party-Risk.
• NIS2 (EU). Sektoraler Cyber-Resilience-Baseline; Member-State-Transposition variiert.
• DSGVO/GDPR. Privacy, nicht Security — aber Artikel 32 verlangt angemessene technische/organisatorische Maßnahmen, und Breach-Notification unter Artikel 33-34 treibt Security-Investment.

Wo Frameworks aneinander vorbeireden

• "Risk-Assessment." ISO = formale Asset-Threat-Vuln-Methodologie mit Risk-Register. SOC 2 = Identifikation relevanter Risks. NIST CSF = laufende Funktion. Implementierungen divergieren; gleiches Artefakt erfüllt selten alle drei ohne Anpassung.
• "Access-Review." SOX = quartalsweise mit Sign-Off. ISO = periodisch. SOC 2 = "regelmäßig" nach Auditor-Judgment. Operations-Team baut einen Prozess, der den strengsten erfüllt.
• "Vulnerability-Management." PCI = quartalsweise External-Scan + jährlicher Pentest mit strikten Timelines. ISO = Prozess existiert. NIST = kontinuierlich. Frequenz und Strenge unterscheiden sich.
• "Incident-Response." Notification-Timelines: DSGVO 72h, NIS2 24h initial / 72h detailliert, PCI sofort, SEC 4 Tage bei Material, DORA 4h. Notification-Matrix einmal mappen.
• "Encryption in Transit." Alle Frameworks verlangen es. Keines spezifiziert TLS-Version. Interner Standard = TLS 1.2+ Minimum, TLS 1.3 bevorzugt; dokumentieren und referenzieren.

Risk-Control-Plattform-Architektur

• Layer 1 — Signal-Ingest.
  • Sources: SIEM-Alerts, EDR-Detections, Vulnerability-Scanner, Cloud-Config-Drift, IAM-Events, Ticketing-System.
  • In Canonical-Risk-Event-Schema normalisieren (Asset, Control, Observation, Severity, Source, Timestamp).
  • Beim Ingest deduplizieren.
• Layer 2 — Rule-Layer.
  • Raw-Signals → Risks mappen. "Drei Failed-Auth-Events von gleichem User innerhalb 5 Min" → "Credential-Stuffing-Suspected"-Risk.
  • Risks → Controls (via Framework-Mapping) mappen. Ein Risk kann mehrere Controls über Frameworks impacten.
  • Severity-Scoring: Likelihood × Impact, gegen historische Incidents kalibriert.
• Layer 3 — Decision-Loop.
  • Triage-Queue pro Business-Unit / Owner.
  • SLA pro Severity (P1: 24h, P2: 7 Tage, P3: 30 Tage).
  • Decisions: Mitigate / Accept / Transfer / Avoid, mit dokumentierter Rationale.
  • Eskalation bei SLA-Breach.
• Layer 4 — Audit-Trail.
  • Append-Only-Event-Log: wer sah was, wer entschied was, was änderte sich.
  • Evidence-Linkage: jedes geschlossene Risk hat Artefakt (Ticket, Config-Snapshot, Test-Result).
  • Auditor-Read-Only-Access auf Evidence-Period gescoped.
• Integrationen pro Layer.
  • Identity (Okta, Azure AD, Google Workspace) — wer besitzt das Asset, wer kann approven.
  • Asset/CMDB (ServiceNow, Custom) — was ist das Asset, Kritikalität, Owner-Team.
  • Ticketing (Jira, ServiceNow) — Risk → Ticket-Auto-Create, Status-Sync, Closure-Evidence.
  • Cloud-Config (AWS Config, Azure Policy, GCP SCC, Wiz / Prisma) — Drift-Signal-Source.

Informationssicherheits-Feldkarte

• Product-Security. SDLC, Code-Review, Threat-Modeling, SAST/DAST/SCA, Security-Champions.
• Infrastructure-Security. Network, Endpoint, Cloud-Config, Hardening, Patching.
• Identity & Access. SSO, MFA, Lifecycle, Privileged-Access, Secrets-Management.
• Governance, Risk, Compliance. Frameworks, Audits, Policy, Third-Party-Risk, Vendor-Due-Diligence.
• Detection & Response. SIEM, EDR, SOAR, SOC-Operations, Incident-Response, Forensik.
• Threat-Intelligence. IOC-Ingest, Actor-Tracking, Attribution, Intel-getriebenes Hunting.
• Offensive-Security. Pentest, Red-Team, Bug-Bounty, Exploit-Research.
• Security-Engineering. Platform-Tooling, Automation, IaC für Security, internes SDK.
• Awareness & Training. Phishing-Exercises, Role-Based-Training, Executive-Briefings.
• Leadership (CISO-Funktion). Strategy, Board-Reporting, Budget, Headcount, Vendor-Selection, Risk-Acceptance.

Praktische CISO-Orientierung

1. Ein Primary-Framework für Governance wählen (ISO 27001 wenn europäisch, NIST CSF wenn hybrid).
2. Overlays nur nach Bedarf hinzufügen (PCI bei Karten, HIPAA bei Healthcare, DORA/NIS2 wenn applikabel).
3. Controls einmal mappen, Evidence einmal sourcen, alle Framework-Reports aus gleicher Evidence-Base befriedigen.
4. Outcome-basierte Metrics statt Activity-basiert: "Mean-Time-to-Patch-Critical-CVE" schlägt "% reviewter Policies".
5. Board-Level-Reporting: Risk-Register-Top-10 mit Owner, Status, Trend — keine Raw-Vulnerability-Counts.