Kontrollen
Kontrollen als Kernbaustein - vom Framework-Ziel über automatische Statusbewertung bis zum Audit-Beweis
Kurzfassung: Eine Kontrolle ist eine Sicherheitsanforderung, die dein Unternehmen erfüllen muss. Stell sie dir wie einen Punkt auf einer Checkliste vor: „Wir müssen regelmäßig prüfen, wer auf unsere Systeme zugreifen kann." Die Kontrolle sagt was erreicht werden soll, nicht wie.
Was ist eine Kontrolle?
Eine Kontrolle definiert ein spezifisches Sicherheits- oder Compliance-Ziel. Sie beschreibt nicht das „Wie", sondern das „Was". Sie gibt vor, welcher Sicherheitsstandard erfüllt sein muss, ohne die konkrete Umsetzung zu diktieren.
Beispiele für Kontrollen
- „Zugriffsrechte werden regelmäßig überprüft"
- „Alle Systeme werden gegen Schadsoftware geschützt"
- „Sensible Daten werden verschlüsselt übertragen"
- „Backup-Verfahren werden monatlich getestet"
Warum Kontrollen statt Policy-Uploads?
| Traditioneller Ansatz | Kontrollbasierter Ansatz (Kopexa) |
|---|---|
| Statische PDF/Word-Dokumente | Strukturierte, messbare Ziele |
| Keine Verknüpfung zur Umsetzung | Direkte Verbindung zu Maßnahmen |
| Schwer auditierbar | Automatisiert prüfbar |
| Framework-agnostisch | Multi-Framework-Mapping |
| Einmalige Uploads | Kontinuierliche Überwachung |
Mit Kontrollen siehst du nicht nur was dokumentiert ist, sondern was nachweislich funktioniert.
Eine Kontrolle, mehrere Frameworks
Eine Kontrolle in Kopexa kann mehrere Compliance-Frameworks gleichzeitig abdecken.
Beispiel: „Regelmäßige Überprüfung von Zugangsrechten"
- ISO 27001: A.9.2.5
- SOC 2: CC6.2
- NIST CSF: PR.AC-4
- TISAX: 3.1.1
So wird Doppelarbeit reduziert und ein einheitlicher Nachweis über mehrere Frameworks hinweg möglich.
Kontroll-Status
Kontrollen sind die „oberste Ebene". Sie definieren, was erreicht werden soll. Ihr Status ergibt sich automatisch aus den zugeordneten Maßnahmen.
| Status | Bedeutung | Wann |
|---|---|---|
| Umgesetzt | Alle verknüpften Maßnahmen sind wirksam | Mindestens eine aktive Maßnahme verknüpft und alle Maßnahmen haben Status Wirksam |
| Teilweise umgesetzt | Mindestens eine Maßnahme ist nicht voll wirksam | Mindestens eine Maßnahme hat Status Eingeschränkt wirksam oder Nicht wirksam |
| Nicht umgesetzt | Keine Maßnahmen verknüpft | Default für neu angelegte Kontrollen. Sobald Maßnahmen verknüpft werden, schaltet der Status um |
| Nicht anwendbar | Kontrolle ist für deinen Scope nicht relevant | Manuell gesetzt, bleibt sticky und wird nicht automatisch überschrieben |
Nicht anwendbar als bewusste Entscheidung
Nicht anwendbar ist der einzige Kontroll-Status, den du explizit setzt. Damit dokumentierst du im Statement of Applicability (ISO 27001) oder vergleichbaren Reports: „Wir haben diese Anforderung geprüft und sie ist in unserem Scope nicht relevant", z. B. weil eine Technologie nicht im Einsatz ist. Archivierte Maßnahmen an der Kontrolle beeinflussen den Status nicht. Sie werden in der Aggregation ignoriert.
Was du davon hast:
- Du erkennst sofort, welche Kontrollen noch offen oder nur teilweise umgesetzt sind.
- Auditor:innen sehen eine klare Story, von „Nicht umgesetzt" (Planung) bis „Umgesetzt" (Nachweis komplett).
- Nicht anwendbar verhindert, dass irrelevante Anforderungen dein Reporting aufblähen. Du musst sie dafür nicht löschen.
Die Kontroll-Hierarchie in Kopexa
- Kontrolle (Zielvorgabe): Was soll erreicht werden? Beispiel: „Alle Benutzerkonten müssen eindeutig identifizierbar sein"
- Maßnahme (Umsetzung): Wie wird die Kontrolle umgesetzt? Beispiel: „Active-Directory-basierte Benutzerauthentifizierung mit eindeutigen Benutzernamen"
- Nachweis (Beleg): Womit wird die Umsetzung belegt? Beispiel: „Screenshot der AD-Benutzerverwaltung und Audit-Log der letzten Zugangsüberprüfung"
Auditor:innen bewerten nicht nur Dokumente, sondern die Gesamtheit von Kontrolle → Maßnahme → Nachweis.
Best Practices
Granularität optimieren
- Zu granular: „Passwörter müssen mindestens 8 Zeichen haben"
- Optimal: „Authentifizierung erfolgt nach bewährten Sicherheitsstandards"
Flexibilität bei Maßnahmen gewährleisten
Kontrollen sollten verschiedene Umsetzungsansätze zulassen.
Kontrolle: „Sensible Daten werden gegen unbefugten Zugriff geschützt"
Mögliche Maßnahmen:
- Encryption-at-Rest via BitLocker
- Database-Level-Encryption
- Application-Level-Tokenisierung
- Hardware Security Modules (HSM)
Nachweis-Anforderungen definieren
Jede Kontrolle sollte klare Kriterien dafür haben, welche Nachweise ausreichen:
- Dokumentarischer Nachweis: Policies, Prozessbeschreibungen
- Technischer Nachweis: Screenshots, Konfigurationsdateien, Logs
- Testimonialer Nachweis: Interviews, Bestätigungen
Praxis-Beispiel: Lisas erstes Audit
Lisa ist Compliance-Managerin bei einer SaaS-Firma. Sie muss ISO 27001 und SOC 2 nachweisen.
Ohne Kopexa:
- Lisa erstellt separate Excel-Listen für ISO 27001 und SOC 2.
- Sie lädt Policy-PDFs in verschiedene Ordner.
- Beim Audit sucht sie manuell nach Nachweisen.
- Die Auditorin fragt: „Wie hängt diese Policy mit der Anforderung zusammen?" Lisa muss erklären.
Mit Kopexa:
- Lisa legt die Kontrolle „Zugriffsrechte werden regelmäßig überprüft" an.
- Sie verknüpft sie mit ISO 27001 A.9.2.5 und SOC 2 CC6.2.
- Sie erstellt eine Maßnahme „Quartalsweise Zugriffsüberprüfung via Azure AD".
- Sie lädt den letzten Überprüfungs-Report als Nachweis hoch.
- Beim Audit klickt die Auditorin auf die Kontrolle und sieht sofort: Maßnahme ✓, Nachweis ✓, Status: Umgesetzt.
Kopexa transformiert Compliance von einem dokumentenlastigen, reaktiven Prozess zu einem strukturierten, kontinuierlich überwachten System.