Controls

Was ist ein Control?

Ein Control definiert ein spezifisches Sicherheits- oder Compliance-Ziel. Controls beschreiben nicht das "Wie", sondern das "Was" - sie geben vor, welcher Sicherheitsstandard erfüllt werden muss, ohne die konkrete Umsetzung zu diktieren.

Beispiele für Controls:

• "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 Controls statt Policy-Uploads?

Der Unterschied: Mit Controls siehst du nicht nur was dokumentiert ist, sondern was nachweislich funktioniert.

Framework-Integration: Ein Control, mehrere Standards

Ein Control in Kopexa kann mehrere Compliance-Frameworks gleichzeitig abdecken.

Beispiel-Control: „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

Die Control-Hierarchie in Kopexa

1. Control (Zielvorgabe)

• Definition: Was soll erreicht werden?
• Beispiel: "Alle Benutzerkonten müssen eindeutig identifizierbar sein"

2. Maßnahme (Umsetzung)

• Definition: Wie wird das Control umgesetzt?
• Beispiel: "Active Directory-basierte Benutzerauthentifizierung mit eindeutigen Benutzernamen"

3. Evidence (Nachweis)

• Definition: Womit wird die Umsetzung belegt?
• Beispiel: "Screenshot der AD-Benutzerverwaltung + Audit-Log der letzten Zugangsüberprüfung"

Audit-Perspektive

Auditor:innen bewerten nicht nur Dokumente, sondern die Gesamtheit von Control → Maßnahme → Evidence.

Best Practices für Control-Management

1. Granularität optimieren

Zu granular: "Passwörter müssen mindestens 8 Zeichen haben" Optimal: "Authentifizierung erfolgt nach bewährten Sicherheitsstandards"

2. Flexibilität bei Maßnahmen gewährleisten

Controls sollten verschiedene Umsetzungsansätze zulassen:

Control: "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)

3. Evidence-Anforderungen definieren

Jedes Control sollte klare Kriterien für ausreichende Evidenz haben:

• Dokumentarische Evidenz: Policies, Prozessbeschreibungen
• Technische Evidenz: Screenshots, Konfigurationsdateien, Logs
• Testimoniale Evidenz: Interviews, Bestätigungen

Reporting und Dashboards

Controls in Kopexa bieten verschiedene Sichten für unterschiedliche Zielgruppen:

• Executive Dashboards: High-level Control-Compliance auf einen Blick
• Operational Views: Detaillierte Maßnahmen-Status für Teams
• Audit Reports: Automatisch generierte Compliance-Nachweise

Praxis-Beispiel: Lisa's erster Audit

Lisa ist Compliance-Managerin bei einer SaaS-Firma. Sie muss ISO 27001 und SOC 2 nachweisen.

Ohne Kopexa:

1. Lisa erstellt separate Excel-Listen für ISO 27001 und SOC 2
2. Sie lädt Policy-PDFs in verschiedene Ordner
3. Beim Audit sucht sie manuell nach Nachweisen
4. Der Auditor fragt: "Wie hängt diese Policy mit der Anforderung zusammen?" – Lisa muss erklären

Mit Kopexa:

1. Lisa legt das Control "Zugriffsrechte werden regelmäßig überprüft" an
2. Sie verknüpft es mit ISO 27001 A.9.2.5 und SOC 2 CC6.2
3. Sie erstellt eine Maßnahme "Quartalsweiser Access Review via Azure AD"
4. Sie lädt den letzten Review-Report als Evidence hoch
5. Beim Audit klickt der Auditor auf das Control und sieht sofort: Maßnahme ✓, Evidence ✓, Status: Fulfilled