Sicherheitsrichtlinien und -verfahren erstellen

Dieses Kapitel behandelt drei wesentliche Richtlinien: die Acceptable Use Policy (was Mitarbeitende tun und lassen dürfen), den Notfallplan (was zu tun ist, wenn etwas schiefgeht) und die Datenklassifizierungsrichtlinie (wie verschiedene Datentypen zu behandeln sind). Sie erhalten Vorlagen, die Sie an einem Nachmittag anpassen können – keine Frameworks, die ein Komitee erfordern.

Warum Richtlinien für kleine Unternehmen wichtig sind

„Wir sind nur 20 Personen, alle wissen, was zu tun ist" – das funktioniert, bis es nicht mehr funktioniert. Richtlinien sind wichtig, weil:

Personen kommen und gehen. Das implizite Wissen in den Köpfen aller? Es verlässt das Unternehmen, wenn jemand kündigt. Neue Mitarbeitende wissen nicht, was akzeptabel ist, wenn es nicht schriftlich festgehalten ist.

Vorfälle geschehen schnell. Wenn Sie um 2 Uhr nachts mit einem Sicherheitsvorfall konfrontiert sind, haben Sie keine Zeit, herauszufinden, wen Sie anrufen, was zu sichern oder was Sie Kunden mitteilen sollen. Sie brauchen einen Plan, dem Sie auf Autopilot folgen können.

Haftungsschutz. Wenn ein Mitarbeiter etwas Unüberlegtes tut und Sie keine Richtlinie haben, die es verbietet, viel Glück vor Gericht. Schriftliche Richtlinien setzen Erwartungen und bieten rechtliche Absicherung.

Anforderungen von Kunden und Partnern. Selbst kleine B2B-Unternehmen werden von Interessenten gefragt: „Haben Sie Sicherheitsrichtlinien?" Echte Richtlinien (nicht nur „Ja, uns ist Sicherheit wichtig") gewinnen Aufträge.

Versicherungsanforderungen. Cyber-Versicherungen verlangen zunehmend dokumentierte Richtlinien. Keine Richtlinien = höhere Prämien oder abgelehnte Ansprüche.

Das Ziel ist nicht Bürokratie. Es geht darum, klare Antworten auf häufige Fragen zu haben, damit Sie das Rad nicht jedes Mal neu erfinden, wenn etwas auftaucht.

Grundsätze für das Schreiben von Richtlinien

Bevor Sie sich in konkrete Richtlinien vertiefen, verstehen Sie, was eine Richtlinie effektiv macht:

Kurz halten

Wenn Ihre Richtlinie länger als 3 Seiten ist, wird sie niemand lesen. Eine Richtlinie, die niemand liest, ist schlimmer als keine Richtlinie – sie erzeugt falsches Vertrauen.

Ziel-Längen:

Acceptable Use Policy: 2–3 Seiten
Notfallplan: 3–5 Seiten
Datenklassifizierung: 1–2 Seiten

Klare Sprache verwenden

Schreiben Sie für Ihre tatsächlichen Mitarbeitenden, nicht für Anwälte oder Prüfer. Wenn ein Anwalt benötigt wird, um Ihre Richtlinie zu interpretieren, schreiben Sie sie neu.

SCHLECHT: "Employees shall refrain from utilizing corporate computing resources 
     for purposes not directly related to authorized business activities."

GUT: "Don't use work computers for personal stuff that could get us in trouble: 
      pirated software, inappropriate content, or running a side business."

Bei Konsequenzen konkret sein

Vage Drohungen wirken nicht. „Verstöße können zu Disziplinarmaßnahmen führen" bedeutet nichts. Seien Sie konkret:

SCHLECHT: "Violations of this policy may result in disciplinary action."

GUT: "First violation: Verbal warning and required security training.
      Second violation: Written warning in personnel file.
      Serious violations (data breach, malware infection): Immediate termination possible."

Das „Warum" erklären

Menschen befolgen Regeln, die sie verstehen. Erklären Sie die Begründung:

SCHLECHT: "Personal devices must not be connected to the corporate network."

GUT: "Personal devices can't connect to our network because we can't verify 
      they're secure. Infected personal devices have caused major breaches 
      at other companies. Use guest WiFi for personal phones."

Ausnahmen klar definieren

Jede Regel hat Ausnahmen. Dokumentieren Sie diese, sonst erfinden die Leute eigene:

**Policy:** Software must be approved before installation.

**Exception:** Development team members may install packages via npm/pip/brew 
for their projects without approval. However, packages in production 
deployments must be scanned for vulnerabilities.

Von Unternehmen lernen, die ihre Richtlinien veröffentlichen

Sie müssen nicht bei null anfangen. Mehrere Technologieunternehmen veröffentlichen ihre Sicherheitsrichtlinien und Handbücher offen. Studieren Sie diese für Struktur, Sprache und Umfang – und passen Sie sie dann an Ihren Kontext an.

Öffentliche Richtlinienbeispiele

Unternehmen	Was veröffentlicht wird	Warum es nützlich ist	Link
GitLab	Vollständiges Sicherheitshandbuch: Datenklassifizierung, Vorfallsreaktion, Acceptable Use, On-Call-Verfahren	Sehr detailliert, deckt Grenzfälle ab, gut für Technologieunternehmen	handbook.gitlab.com/handbook/security
PagerDuty	Incident-Response-Dokumentation (Open Source)	Der Goldstandard für IR-Prozesse, von Tausenden von Unternehmen genutzt	response.pagerduty.com
Atlassian	Incident-Management-Handbuch und Playbooks	Hervorragende Schweregrad-Definitionen und Kommunikationsvorlagen	atlassian.com/incident-management
Mattermost	Sicherheitsrichtlinien im öffentlichen Handbuch	Gutes Beispiel für kleinere Technologieunternehmen	handbook.mattermost.com
Basecamp	Mitarbeiterhandbuch auf GitHub	Praktische, verständliche Richtlinien	github.com/basecamp/handbook

Kostenlose Richtlinienvorlagen

Ressource	Was Sie erhalten	Am besten für	Link
SANS Policy Templates	60+ sofort einsetzbare Vorlagen (AUP, IRP, Passwortrichtlinie, Remote-Zugang usw.)	Schnellstart mit branchenüblicher Sprache	sans.org/information-security-policy
NIST Small Business Cybersecurity	Leitfäden, Checklisten und Frameworks für KMU	Buy-in der nicht-technischen Führungsebene	nist.gov/itl/smallbusinesscyber
CIS Controls	Priorisierte Sicherheitsmaßnahmen mit Implementierungsgruppen nach Unternehmensgröße	Strukturierter Ansatz, IG1 ist ideal für kleine Unternehmen	cisecurity.org/controls
CISA Incident Response Playbooks	Bundesbehörden-Playbooks für Ransomware, Schwachstellenreaktion	Wenn Sie detaillierte Schritt-für-Schritt-IR-Leitfäden benötigen	cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf

Schnellstart: Mindest-Richtlinien

Wenn Sie Richtlinien HEUTE benötigen und wenig Zeit haben:

1. Acceptable Use Policy (30 Minuten)

SANS-Vorlage für Acceptable Use Policy herunterladen
Unternehmensname und Kontaktdaten ersetzen
Nicht relevante Abschnitte entfernen
Ihre spezifischen Tools und Dienste hinzufügen
Fertig – später iterieren

2. Notfallplan (1 Stunde)

Struktur von response.pagerduty.com studieren
Schweregrad-Definitionen übernehmen
Kontaktdaten Ihres Teams hinzufügen
Einfache Slack-Kanal-Namenskonvention erstellen
Playbooks können später hinzugefügt werden

3. Datenklassifizierung (20 Minuten)

4-stufiges Schema verwenden: Öffentlich / Intern / Vertraulich / Streng vertraulich
3–5 Beispiele für jede Stufe aus Ihren tatsächlichen Daten auflisten
Definieren, wo jede Stufe gespeichert werden darf
Das war's – bei Bedarf erweitern

Einfach starten, iterieren

Eine 2-seitige Richtlinie, die Sie tatsächlich verwenden, schlägt eine 20-seitige Richtlinie, die niemand liest. Veröffentlichen Sie Version 1.0 schnell, dann verbessern Sie auf Basis echter Fragen und Vorfälle.

Reale Vorfälle: was ohne Richtlinien passiert

Das sind keine Schreckensszenarien – das sind Lektionen von Unternehmen, die es auf die harte Tour gelernt haben.

Kein Notfallplan

Uber (2016): Als Angreifer auf Daten von 57 Millionen Nutzern zugriffen, hatte Uber keinen dokumentierten IR-Prozess. Statt einer ordnungsgemäßen Reaktion zahlten sie den Angreifern 100.000 Dollar, um die Daten zu löschen und zu schweigen. Ergebnis: 148-Millionen-Dollar-Vergleich, strafrechtliche Anklagen gegen den CISO, massiver Reputationsschaden. Ein dokumentierter Notfallplan hätte die ordnungsgemäße Meldung des Datenschutzverstoßes geleitet.

Equifax (2017): Der Datenschutzvorfall, der 147 Millionen Personen betraf, wurde durch eine chaotische Reaktion verschlimmert. Keine klaren Zuständigkeiten, verzögerter Patch-Prozess, kein Kommunikationsplan. Der CEO bezeugte vor dem Kongress, dass niemand wusste, wer für das Patchen verantwortlich war. Die Gesamtkosten überstiegen 1,4 Milliarden Dollar.

Keine Acceptable Use Policy

Twitter (2020): Angreifer nutzten telefonbasiertes Social Engineering bei Mitarbeitenden, um Zugang zu internen Tools zu erlangen, und kaperten dann hochkarätige Accounts (Obama, Elon Musk, Apple). Eine klare AUP zum Umgang mit Anmeldedaten und zur Meldung von Social-Engineering-Versuchen hätte Mitarbeitenden helfen können, den Angriff früher zu erkennen und zu melden.

SolarWinds (2020): Ein Praktikant soll das Passwort „solarwinds123" auf einem kritischen Server verwendet haben. Ohne durchgesetzte Passwortrichtlinien und klare Nutzungsrichtlinien scheiterte grundlegende Sicherheitshygiene.

Keine Datenklassifizierung

Capital One (2019): Eine falsch konfigurierte WAF legte 100 Millionen Kundendatensätze offen. Teil des Problems: Keine klare Datenklassifizierung bedeutete, dass sensible Daten zusammen mit weniger kritischen gespeichert wurden, was die Exposition vergrößerte. Kosten: 80 Millionen Dollar Strafe, 190 Millionen Dollar Vergleich.

Das Muster: Unternehmen ohne dokumentierte Richtlinien treffen unter Druck schlechtere Entscheidungen, reagieren langsamer und sehen sich schärferen regulatorischen Konsequenzen gegenüber.

Acceptable Use Policy (AUP)

Die AUP definiert, was Mitarbeitende mit Unternehmensressourcen tun und lassen dürfen: Computer, Netzwerk, E-Mail, Cloud-Dienste und Daten. Sie ist das Fundament aller Sicherheitsrichtlinien.

Was abzudecken ist

Zweck und Geltungsbereich — Für wen gilt das, welche Ressourcen sind abgedeckt
Allgemeine Grundsätze — Kernerwartungen: Professionalität, keine illegalen Aktivitäten
Konto- und Passwortanforderungen — Passwortregeln, MFA, keine Weitergabe von Zugangsdaten
E-Mail und Kommunikation — Berufliche Nutzung, Phishing-Bewusstsein, Grenzen privater E-Mail
Internet und soziale Medien — Was während der Arbeit erlaubt ist, das Unternehmen online vertreten
Software und Downloads — Was installiert werden darf, Genehmigungsverfahren
Private Geräte (BYOD) — Dürfen private Geräte auf Unternehmensdaten zugreifen, unter welchen Regeln
Datenhandhabung — Wie mit Unternehmens- und Kundendaten umzugehen ist
Fernarbeit — VPN-Anforderungen, öffentliches WLAN, physische Sicherheit zu Hause
Überwachung und Datenschutz — Was das Unternehmen überwacht, Datenschutzerwartungen der Mitarbeitenden
Meldung von Verstößen — Wie Bedenken gemeldet werden, Schutz vor Vergeltungsmaßnahmen
Konsequenzen — Was bei Richtlinienverstößen passiert

AUP-Vorlage

Hier ist eine einsatzbereite Vorlage. Passen Sie die eckigen Klammern an Ihr Unternehmen an:

# [COMPANY NAME] Acceptable Use Policy

**Effective date:** [DATE]
**Last updated:** [DATE]
**Owner:** [SECURITY CHAMPION NAME]

## Purpose

This policy defines acceptable use of [COMPANY NAME] technology resources. 
Following these guidelines protects you, your colleagues, and our customers.

## Scope

This policy applies to:
- All employees, contractors, and temporary workers
- All company-owned devices and accounts
- Personal devices when accessing company data
- All use of company network and cloud services

## Your responsibilities

### Accounts and passwords

- Use unique passwords of at least [12/14/16] characters for all work accounts
- Enable MFA on all accounts that support it (mandatory for [list critical services])
- Never share your credentials with anyone — including IT or your manager
- Lock your computer when stepping away (Windows+L or Cmd+Ctrl+Q)
- Report suspected account compromise immediately to [CONTACT]

### Email and communication

- Use company email for work communication only
- Don't open unexpected attachments — verify with sender first
- Report suspicious emails to [SECURITY EMAIL/CHANNEL]
- Don't use company email to sign up for personal services
- Assume all email could become public in a legal dispute

### Internet use

Personal internet use during breaks is acceptable within reason. Don't:
- Access illegal content
- Download pirated software or media
- Use excessive bandwidth (streaming during work hours)
- Access content that would embarrass the company if discovered

### Software installation

- Approved software: [LIST OR LINK TO APPROVED SOFTWARE LIST]
- To request new software: [PROCESS]
- Never install software from untrusted sources
- Browser extensions must be from official stores only
- Developers: Package managers (npm, pip, brew) are allowed for development

### Personal devices (BYOD)

If you access company data on personal devices:
- Device must have screen lock enabled
- Install security updates within 1 week of release
- Company reserves right to remote wipe company data if device is lost
- Don't store customer data on personal devices
- Use [APPROVED MDM] if accessing email on mobile

### Remote work

- Use company VPN when accessing internal resources
- Don't work on sensitive data in public places (coffee shops, airports)
- Secure your home WiFi with WPA3 or WPA2 and a strong password
- Don't let family members use work devices

### Data handling

- Treat all customer data as confidential
- Don't share company data through personal email or messaging apps
- Use approved file sharing services: [LIST]
- Don't copy company data to personal cloud storage
- See Data Classification Policy for details

## Company monitoring

[COMPANY NAME] monitors company resources to protect security. This includes:
- Email (content and metadata)
- Web browsing history
- File access logs
- Login times and locations

We don't monitor personal devices except for company apps installed on them.

## Reporting concerns

Report policy violations or security concerns to [CONTACT]. Reports can be 
anonymous via [MECHANISM]. We don't retaliate against good-faith reports.

## Consequences

| Violation type | First offense | Repeat offense |
|---------------|---------------|----------------|
| Minor (e.g., unapproved software) | Warning + training | Written warning |
| Moderate (e.g., sharing credentials) | Written warning | Suspension possible |
| Severe (e.g., data breach, malware) | Termination possible | Termination |

Severity is determined by [ROLE, e.g., HR in consultation with Security Champion].

## Questions

Contact [SECURITY CHAMPION NAME] at [EMAIL] with any questions about this policy.

---

**Acknowledgment**

I have read and understand the [COMPANY NAME] Acceptable Use Policy.

Name: ____________________
Signature: ________________
Date: ____________________

Häufige AUP-Fehler

Fehler	Warum es ein Problem ist	Lösung
Unternehmensrichtlinien kopieren	Zu komplex, für Ihren Kontext irrelevant	Neu schreiben, kurz halten
Keine Durchsetzung	Richtlinie wird zur Empfehlung	Klare Konsequenzen definieren, konsequent durchsetzen
Veraltete Technologie	Verweist auf Faxgeräte, ignoriert Cloud	Jährlich aktualisieren, tatsächliche Tools abbilden
Zu restriktiv	Menschen umgehen die Regeln	Sicherheit und Produktivität ausbalancieren
Kein Ausnahmeprozess	Menschen ignorieren Regeln, wenn diese die Arbeit blockieren	Dokumentieren, wie Ausnahmen beantragt werden
Juristisches Fachjargon	Niemand liest es	In verständlicher Sprache schreiben

Notfallplan (IRP)

Wenn etwas schiefgeht – Ransomware, Datenschutzvorfall, kompromittierter Account – brauchen Sie einen Plan. Der IRP sagt jedem genau, was zu tun ist. Es geht nicht um Strategie; es ist eine Checkliste für eine Krise.

Warum Sie einen IRP brauchen, bevor ein Vorfall eintritt

Während eines Vorfalls sind Sie gestresst, schlafmangelig und treffen schnelle Entscheidungen. Das ist der schlechteste Zeitpunkt, um herauszufinden:

Wer sollte was tun?
Wen rufen wir extern an?
Was kommunizieren wir an Kunden?
Sichern wir Beweise richtig?

Schreiben Sie den IRP, wenn Sie ruhig sind. Befolgen Sie ihn, wenn Sie in Panik sind.

IRP-Struktur

Vorfallsklassifizierung — Was zählt als Vorfall, Schweregrade
Reaktionsteam und Rollen — Wer was während eines Vorfalls tut
Erkennung und Meldung — Wie wir von Vorfällen erfahren
Eindämmung — Blutung stoppen, betroffene Systeme isolieren
Untersuchung — Verstehen, was passiert ist
Beseitigung und Wiederherstellung — Bedrohung entfernen, Normalbetrieb wiederherstellen
Kommunikation — Intern, Kunden, Behörden, Öffentlichkeit
Nachbesprechung — Lernen und verbessern
Kontaktliste — Alle, die Sie möglicherweise anrufen müssen

IRP-Vorlage

# [COMPANY NAME] Incident Response Plan

**Version:** 1.0
**Effective date:** [DATE]
**Owner:** [SECURITY CHAMPION NAME]
**Review frequency:** Annually or after any major incident

---

## 1. What is an incident?

A security incident is any event that:
- Compromises confidentiality, integrity, or availability of company data
- Violates security policies
- Could harm customers, employees, or the company

### Severity levels

| Level | Description | Examples | Response time |
|-------|-------------|----------|---------------|
| **Critical** | Active attack, major data breach | Ransomware, customer DB exposed | Immediate (within 15 min) |
| **High** | Confirmed compromise, limited scope | Single account compromised, malware on one system | Within 1 hour |
| **Medium** | Potential compromise, needs investigation | Suspicious login, phishing clicked | Within 4 hours |
| **Low** | Policy violation, no confirmed impact | Unauthorized software, failed attack | Within 24 hours |

---

## 2. Response team

### Primary responders

| Role | Person | Phone | Backup |
|------|--------|-------|--------|
| **Incident Lead** | [NAME] | [PHONE] | [BACKUP NAME] |
| **Technical Lead** | [NAME] | [PHONE] | [BACKUP NAME] |
| **Communications** | [NAME] | [PHONE] | [BACKUP NAME] |
| **Executive Sponsor** | [NAME] | [PHONE] | [BACKUP NAME] |

### Role responsibilities

**Incident Lead (usually Security Champion):**
- Coordinates response activities
- Makes containment decisions
- Maintains incident timeline
- Ensures documentation
- Leads post-incident review

**Technical Lead (usually senior developer or DevOps):**
- Performs technical investigation
- Implements containment measures
- Leads eradication and recovery
- Preserves evidence

**Communications (usually CEO or Head of Customer Success):**
- Drafts customer communications
- Handles media inquiries
- Coordinates with legal
- Internal employee updates

**Executive Sponsor (CEO or CTO):**
- Authorizes major decisions (system shutdown, customer notification)
- External stakeholder communication
- Resource allocation

---

## 3. Detection and reporting

### How we detect incidents

- Employee reports suspicious activity
- Automated alerts (monitoring, SIEM, security tools)
- Customer complaints
- Third-party notification (vendor, researcher)
- Law enforcement contact

### Reporting an incident

**Any employee who suspects an incident must:**

1. Don't try to fix it yourself
2. Report immediately via:
   - Slack: #security-incidents (preferred for speed)
   - Email: security@[company].com
   - Phone: [SECURITY CHAMPION PHONE] (after hours)
3. Include:
   - What you observed
   - When it happened
   - Systems/accounts involved
   - Any actions you've already taken

---

## 4. Initial response (first 30 minutes)

### Incident Lead actions

1. ☐ Acknowledge report, assign severity level
2. ☐ Create incident channel: #incident-[DATE]-[BRIEF-NAME]
3. ☐ Alert response team members based on severity
4. ☐ Start incident log (use template below)
5. ☐ Assess: Is containment needed immediately?

### Incident log template

Incident Log: [INCIDENT NAME]

Reported: [DATE TIME] Reported by: [NAME] Severity: [LEVEL] Status: [INVESTIGATING / CONTAINED / RESOLVED]

Timeline

Time	Action	Person	Notes
14:32	Incident reported	Jane	Suspicious login from Russia
14:35	Response team alerted	Security Champion	Via Slack
14:42	Account suspended	DevOps	Revoked all sessions
...	...	...	...

Affected systems

[LIST]

Evidence preserved

[LIST]

Key decisions

[DATE TIME] Decided to [DECISION] because [REASON]. Decided by [WHO].

---

## 5. Containment

**Goal:** Stop the incident from getting worse. Speed matters more than perfection.

### Containment options (choose based on situation)

| Action | When to use | How |
|--------|-------------|-----|
| **Disable account** | Compromised credentials | Admin console → Suspend user |
| **Revoke sessions** | Active unauthorized access | Force logout all sessions |
| **Isolate system** | Malware, active attacker | Disconnect from network |
| **Block IP/domain** | Known attacker infrastructure | Firewall/DNS block |
| **Disable service** | Vulnerable application | Take offline temporarily |
| **Rotate credentials** | Exposed secrets | Generate new, update everywhere |
| **Revoke API keys** | Key compromised | Regenerate in service console |

### Evidence preservation

Before destroying evidence (wiping systems, deleting accounts):

1. Take screenshots of relevant logs and screens
2. Export audit logs from affected services
3. Copy access logs from web servers
4. Note IP addresses, timestamps, user agents
5. For malware: image the disk before wiping

**Store evidence in:** [SECURE LOCATION, e.g., locked folder, separate account]

---

## 6. Investigation

### Questions to answer

- What happened? (Attack vector, timeline)
- How did they get in? (Credentials, vulnerability, social engineering)
- What did they access? (Data, systems)
- What did they take or change?
- Are they still in? (Persistence mechanisms)
- Who else might be affected?

### Investigation sources

| Source | What to check | How to access |
|--------|--------------|---------------|
| **Cloud audit logs** | Login attempts, API calls | AWS CloudTrail, GCP Audit Logs, Azure Activity |
| **Email logs** | Phishing, data exfiltration | Google Admin, Microsoft 365 Security |
| **Application logs** | Unauthorized actions | Your logging system |
| **Endpoint logs** | Malware, lateral movement | EDR if you have it, Windows Event Log |
| **Network logs** | Connections, data transfer | Firewall, VPN logs |
| **Git history** | Code tampering | git log, GitHub audit log |

### When to call for help

Call external help (incident response firm) if:
- You're in over your head technically
- Significant customer data is exposed
- Law enforcement may need to be involved
- Insurance requires professional investigation
- Attack is ongoing and you can't contain it

**Incident response contacts:**
- [IR FIRM NAME]: [PHONE] — [NOTES ON ENGAGEMENT]
- Cyber insurance hotline: [PHONE] — Policy #[NUMBER]

---

## 7. Eradication and recovery

### Eradication checklist

- ☐ Remove attacker access (all credentials rotated, backdoors removed)
- ☐ Patch vulnerability that allowed entry
- ☐ Remove malware from all affected systems
- ☐ Verify no persistence mechanisms remain
- ☐ Scan other systems for indicators of compromise

### Recovery steps

1. ☐ Restore systems from known-good backups if needed
2. ☐ Verify integrity of restored data
3. ☐ Re-enable disabled services gradually
4. ☐ Monitor closely for re-infection
5. ☐ Confirm normal operations

### Recovery validation

Before declaring "all clear":
- Run security scans on affected systems
- Review logs for 24-48 hours post-recovery
- Verify no unauthorized changes to critical files
- Test affected functionality

---

## 8. Communication

### Internal communication

| Audience | When | Who communicates | Channel |
|----------|------|-----------------|---------|
| Response team | Immediately | Incident Lead | Incident Slack channel |
| Leadership | Critical/High: immediately; others: daily | Incident Lead | Email/call |
| All employees | When contained or if they need to act | Communications Lead | All-hands email/Slack |

### Customer communication

**Decision matrix:**

| Situation | Notification required? | Timeline |
|-----------|----------------------|----------|
| Customer data accessed | Yes | Within [72 hours for GDPR, varies by law] |
| Service outage only | Consider, especially if prolonged | As appropriate |
| Internal incident, no customer impact | No | N/A |

**Customer notification template:**

Subject: Security Notification from [COMPANY]

Dear [CUSTOMER],

We're writing to inform you about a security incident that may affect your data.

What happened: [Brief, factual description]

What data was involved: [Specific data types, be precise]

What we're doing: [Actions taken and ongoing]

What you can do: [Specific recommendations: change passwords, monitor accounts, etc.]

How to contact us: [Dedicated email/phone for incident inquiries]

We take the security of your data seriously and apologize for any concern this causes. We'll provide updates as we learn more.

[SIGNATURE]

### Regulatory notification

**Check requirements for:**
- GDPR (72 hours to supervisory authority)
- State breach notification laws (varies by US state)
- Industry regulations (HIPAA, PCI DSS)
- Contractual obligations to customers

**Keep legal counsel informed** for anything involving customer data.

---

## 9. Post-incident review

### Blameless postmortem

Within 1 week of resolution, conduct a review:

**Attendees:** All responders, relevant stakeholders

**Agenda:**
1. Timeline review — what happened, when?
2. What went well?
3. What could have gone better?
4. Action items to prevent recurrence
5. Action items to improve response

### Postmortem template

```markdown
## Incident Postmortem: [INCIDENT NAME]

**Date of incident:** [DATE]
**Date of review:** [DATE]
**Severity:** [LEVEL]
**Duration:** [TIME FROM DETECTION TO RESOLUTION]

### Summary
[2-3 sentence description]

### Timeline
[From incident log]

### Root cause
[What allowed this to happen?]

### Impact
- Systems affected: [LIST]
- Data affected: [TYPE AND VOLUME]
- Customer impact: [DESCRIPTION]
- Business impact: [COST, DOWNTIME, REPUTATION]

### What went well
- [EXAMPLE]
- [EXAMPLE]

### What could improve
- [EXAMPLE]
- [EXAMPLE]

### Action items
| Action | Owner | Due date | Status |
|--------|-------|----------|--------|
| [ACTION] | [NAME] | [DATE] | ☐ |
| [ACTION] | [NAME] | [DATE] | ☐ |

### Lessons learned
[Key takeaways for the team]

10. Contact list

Internal

Role	Name	Phone	Email
Security Champion	[NAME]	[PHONE]	[EMAIL]
CTO	[NAME]	[PHONE]	[EMAIL]
CEO	[NAME]	[PHONE]	[EMAIL]
Legal Counsel	[NAME]	[PHONE]	[EMAIL]
HR	[NAME]	[PHONE]	[EMAIL]

External

Service	Contact	Phone/URL	Account info
Cyber Insurance	[CARRIER]	[PHONE]	Policy #[NUMBER]
IR Firm	[FIRM]	[PHONE]	[RETAINER DETAILS]
Legal (external)	[FIRM]	[PHONE]
FBI	Local field office	[PHONE]	For major crimes
AWS Support		[SUPPORT URL]	[ACCOUNT ID]
Google Workspace		[SUPPORT URL]
[OTHER CRITICAL VENDORS]

Appendix: Quick reference cards

If you suspect your account is compromised

Change your password immediately
Enable MFA if not already enabled
Report to #security-incidents
Check recent account activity for unauthorized access
Don't delete anything — we may need it for investigation

If you clicked a phishing link

Disconnect from network (turn off WiFi/unplug ethernet)
Report to #security-incidents immediately
Don't log into anything else
Wait for instructions from response team

If you see ransomware

DON'T turn off the computer (may destroy evidence)
Disconnect from network immediately
Take photo of ransom message
Report to #security-incidents
Alert people nearby to disconnect too

## Vorfalls-Playbooks für häufige Szenarien

Der IRP gibt Ihnen den allgemeinen Prozess. Playbooks liefern spezifische Schritte für bestimmte Vorfallstypen. Beginnen Sie mit diesen vier – sie decken 80 % der Vorfälle ab, mit denen kleine Unternehmen konfrontiert werden.

### Playbook: Kompromittierter Mitarbeiter-Account

**Schweregrad:** Meist Hoch (kann Kritisch sein, wenn Admin-Account)

**Indikatoren:**
- Impossible Travel (Anmeldung aus zwei Ländern innerhalb weniger Stunden)
- Anmeldung von ungewöhnlichem Standort oder Gerät
- Ungewöhnliche Aktivitäten in Audit-Logs
- Mitarbeiter meldet, eigene Aktionen nicht zu erkennen
- Passwort-Reset, den er nicht angefordert hat

**Sofortmaßnahmen (erste 15 Minuten):**

| Schritt | Aktion | Wer |
|---------|--------|-----|
| 1 | Account sperren (nicht löschen) | IT/Security Champion |
| 2 | Alle aktiven Sitzungen widerrufen | IT |
| 3 | API-Tokens/-Keys für diesen Nutzer deaktivieren | DevOps |
| 4 | Mitarbeiter kontaktieren (Telefon, nicht Unternehmens-E-Mail) | Incident Lead |
| 5 | Prüfen, ob MFA aktiviert war | Security Champion |

**Untersuchungs-Checkliste:**
- [ ] Wann erfolgte die Kompromittierung? (Erste verdächtige Anmeldung)
- [ ] Wie kamen sie rein? (Phishing? Credential Stuffing? Malware?)
- [ ] Worauf haben sie zugegriffen? (E-Mail, Dateien, Code, Admin-Panels)
- [ ] Was haben sie getan? (Gelesen, heruntergeladen, geändert, gelöscht)
- [ ] Haben sie von diesem Account auf andere zugegriffen?
- [ ] Sind andere Accounts kompromittiert? (Gleiche Passwort-Wiederverwendung)

**Wiederherstellung:**
1. Passwort mit starkem Zufallspasswort zurücksetzen
2. MFA verifizieren und aktivieren (Hardware-Key, falls verfügbar)
3. Unnötige Berechtigungen prüfen und widerrufen
4. Alle Browser-Sitzungen löschen
5. Gerät des Mitarbeiters auf Malware scannen
6. Account 30 Tage lang engmaschig überwachen

**Kommunikation:**
- Mitarbeiter: Erklären, was passiert ist, keine Schuldzuweisungen, Sicherheitstraining anbieten
- Team: Allgemeine Erinnerung zu Phishing, falls relevant
- Kunden: Nur, wenn ihre Daten betroffen waren

---

### Playbook: Ransomware-Angriff

**Schweregrad:** Kritisch

**Indikatoren:**
- Dateien mit ungewöhnlichen Erweiterungen verschlüsselt
- Lösegeldforderung auf dem Desktop oder in Ordnern
- Systeme ungewöhnlich langsam oder nicht reagierend
- Antivirus-Warnungen zu Verschlüsselung
- Mehrere Mitarbeiter melden gleichzeitig Probleme

**Sofortmaßnahmen (erste 5 Minuten):**

| Schritt | Aktion | Wer | Hinweise |
|---------|--------|-----|---------|
| 1 | Betroffene Computer NICHT ausschalten | Alle | Erhält Speicher-Beweise |
| 2 | Vom Netzwerk trennen | Alle Betroffenen | Kabel ziehen, WLAN deaktivieren |
| 3 | Alle Mitarbeitenden zur Trennung auffordern | Incident Lead | Slack/SMS/Telefonkette |
| 4 | Cyber-Versicherungs-Hotline anrufen | Executive Sponsor | Sie stellen IR-Firma bereit |
| 5 | Alles dokumentieren (Fotos, Screenshots) | Technical Lead | Zeitstrahl ist entscheidend |

**Folgendes NICHT tun:**
- Lösegeld zahlen (ohne rechtliche/versicherungstechnische Beratung)
- Mit Angreifern über Unternehmens-E-Mail kommunizieren
- Dateien oder Logs löschen
- Von Backup wiederherstellen, bevor der Infektionsweg bekannt ist
- Backup-Laufwerke an infiziertes Netzwerk anschließen

**Untersuchungsprioritäten:**
1. Patient Null identifizieren (erstes infiziertes System)
2. Infektionsweg bestimmen (Phishing, RDP, Schwachstelle)
3. Schadensausmaß ermitteln (was verschlüsselt, was exfiltriert)
4. Backups auf Integrität und Sauberkeit prüfen
5. Ermitteln, welche Daten möglicherweise gestohlen wurden (Double Extortion)

**Wiederherstellung (nur nach Untersuchung):**
1. Systeme aus bekannt-guten Images/Backups neu aufbauen
2. Schwachstelle patchen, die den Einstieg ermöglichte
3. ALLE Anmeldedaten zurücksetzen (alles als kompromittiert betrachten)
4. Daten aus sauberen Backups wiederherstellen
5. Intensiv auf Re-Infektion überwachen

**Externe Kontakte:**
- FBI: ic3.gov zur Meldung
- CISA: cisa.gov/ransomware
- Ihre Cyber-Versicherungs-IR-Hotline

---

### Playbook: Datenschutzvorfall bei Kundendaten

**Schweregrad:** Kritisch (regulatorische und rechtliche Konsequenzen)

**Indikatoren:**
- Unbefugter Datenbankzugriff in Logs
- Kundendaten extern gefunden (Forscher, Darknet, Paste-Site)
- Ungewöhnliche Datenexporte oder API-Aktivitäten
- Benachrichtigung durch Dritte

**Sofortmaßnahmen:**

| Schritt | Aktion | Wer | Zeitrahmen |
|---------|--------|-----|------------|
| 1 | Vorfall bestätigen | Technical Lead | Erste Stunde |
| 2 | Laufenden Zugriff stoppen | IT | Sofort |
| 3 | Rechtsberatung informieren | Executive Sponsor | Innerhalb 2 Stunden |
| 4 | Alle Beweise sichern | Technical Lead | Fortlaufend |
| 5 | Regulatorische Uhr starten (DSGVO: 72 Stunden) | Rechtsabteilung | Entdeckungszeitpunkt dokumentieren |

**Fragen zur Schadensermittlung:**
- Welche Datentypen wurden offengelegt? (Personenbezogene Daten, Finanzdaten, Gesundheitsdaten)
- Wie viele Datensätze/Personen sind betroffen?
- Welche Jurisdiktionen? (EU-Bürger = DSGVO)
- Wie lange waren die Daten zugänglich?
- Wurden Daten exfiltriert oder nur eingesehen?
- Ist die Schwachstelle geschlossen?

**Meldepflichten:**

| Regelwerk | Frist | Wer zu benachrichtigen ist |
|-----------|-------|---------------------------|
| **DSGVO** | 72 Stunden | Aufsichtsbehörde, dann betroffene Personen |
| **CCPA** | „Unverzüglich" | Einwohner Kaliforniens |
| **HIPAA** | 60 Tage | HHS, Personen, Medien bei >500 Personen |
| **PCI DSS** | Sofort | Kartenorganisationen, Acquiring-Bank |
| **Landesgesetze** | Variiert | Jeweiligen Bundesstaat prüfen, in dem Kunden wohnen |

**Elemente der Kundenbenachrichtigung:**
1. Was passiert ist (sachlich, knapp)
2. Welche Daten betroffen waren (konkret)
3. Was Sie dagegen unternehmen
4. Was Kunden tun sollten (Passwörter ändern, Konten überwachen)
5. Wie Sie zu erreichen sind
6. Entschuldigung

**Rechtlicher Schutz:**
- Alles mit Zeitstempeln dokumentieren
- Keine Spekulationen in schriftlicher Kommunikation
- Externe Statements vor Veröffentlichung rechtlich prüfen lassen
- Beweise für mögliche Rechtsstreitigkeiten sichern

---

### Playbook: Geleakte Geheimnisse in Git

**Schweregrad:** Hoch (kann Kritisch sein, wenn Produktions-Zugangsdaten)

**Indikatoren:**
- Alert von GitHub Secret Scanning
- Alert von git-secrets, truffleHog oder ähnlichen Tools
- Benachrichtigung vom Cloud-Anbieter (AWS, GCP erkennen manche Keys automatisch)
- Meldung eines Sicherheitsforschers

**Sofortmaßnahmen (innerhalb von 15 Minuten):**

| Schritt | Aktion | Wer |
|---------|--------|-----|
| 1 | Ermitteln, was offengelegt wurde | Security Champion |
| 2 | Zugangsdaten SOFORT rotieren | DevOps/Entwickler |
| 3 | Prüfen, ob Zugangsdaten missbräuchlich genutzt wurden | DevOps |
| 4 | Aus Git-Historie entfernen, wenn möglich | Entwickler |
| 5 | Prüfen, ob Repository öffentlich ist | Security Champion |

**Rotation von Zugangsdaten nach Typ:**

| Geheimnis-Typ | Wo rotieren | Zusätzliche Schritte |
|---------------|-------------|---------------------|
| **AWS-Keys** | IAM-Konsole | CloudTrail auf unbefugte Nutzung prüfen |
| **GCP-Service-Account** | GCP-Konsole | Audit-Logs prüfen |
| **Datenbankpasswort** | Datenbank-Admin | Zugriffslogsdaten prüfen |
| **API-Key (Drittanbieter)** | Anbieter-Konsole | Nutzungslogs prüfen |
| **JWT-Secret** | Anwendungskonfiguration | Alle vorhandenen Tokens werden ungültig |
| **SSH-Key** | Aus authorized_keys entfernen | Neues Schlüsselpaar generieren |

**Git-Historie bereinigen:**

```bash
# If the commit is only local
git reset --soft HEAD~1
# Remove the secret, recommit

# If already pushed (and repo is private)
# Use BFG Repo-Cleaner
bfg --delete-files 'filename-with-secret'
git push --force

# If repo is public
# Assume the secret is compromised forever
# Focus on rotation, not history cleanup

Prävention:

Pre-Commit-Hooks installieren (git-secrets, detect-secrets)
GitHub Secret Scanning aktivieren
Umgebungsvariablen oder Secret-Manager verwenden
.env-Dateien niemals committen

Untersuchung:

Wann wurde das Geheimnis committet?
Wann wurde das Repository öffentlich (falls zutreffend)?
Wer hatte während dieses Zeitraums Zugang?
Ungewöhnliche Aktivitäten mit diesem Zugangsdatum?

Datenklassifizierungsrichtlinie

Die Datenklassifizierung sagt Mitarbeitenden, wie verschiedene Informationstypen zu behandeln sind. Ohne sie behandeln Menschen entweder alles als streng geheim (ineffizient) oder nichts als sensibel (gefährlich).

Warum Daten klassifizieren?

Schutzmaßnahmen fokussieren — Nicht alle Daten benötigen die gleiche Sicherheit
Klare Handhabungsregeln — Personen wissen, was sie tun dürfen
Compliance-Unterstützung — Regulatorische Anforderungen verlangen oft Klassifizierung
Vorfallsreaktion — Sofort wissen, wie ernst ein Datenschutzvorfall ist

Einfaches Klassifizierungsschema

Für kleine Unternehmen reichen drei oder vier Stufen:

Stufe	Beschreibung	Beispiele
Öffentlich	Kann mit jedem geteilt werden	Marketingmaterialien, öffentliche Blogbeiträge, Open-Source-Code
Intern	Nur für Mitarbeitende	Internes Wiki, Organigramm, allgemeine Richtlinien
Vertraulich	Geschäftssensibel	Finanzdaten, strategische Pläne, Mitarbeiterdaten, Kundenlisten
Streng vertraulich	Höchste Sensibilität	Persönliche Kundendaten, Zugangsdaten, Verschlüsselungsschlüssel, Gesundheits-/Zahlungsdaten

Vorlage für Datenklassifizierungsrichtlinie

# [COMPANY NAME] Data Classification Policy

**Effective date:** [DATE]
**Owner:** [SECURITY CHAMPION]

## Purpose

This policy ensures we protect data appropriately based on its sensitivity. 
Not all data is equal — we apply stronger controls to more sensitive data.

## Classification levels

### Public
**Definition:** Information that can be freely shared outside the company.

**Examples:**
- Published blog posts and marketing content
- Public website content
- Open source code repositories
- Press releases

**Handling rules:**
- No special handling required
- Can be posted publicly
- Can be emailed to anyone

---

### Internal
**Definition:** Information for internal use that isn't sensitive but shouldn't 
be public.

**Examples:**
- Internal documentation and wiki
- Company org chart
- Meeting notes (non-sensitive topics)
- Internal announcements
- Non-sensitive Slack conversations

**Handling rules:**
- Share only with employees and approved contractors
- Don't post publicly
- Use company email and approved tools for sharing
- No special encryption required

---

### Confidential
**Definition:** Sensitive business information that could harm the company 
if disclosed.

**Examples:**
- Financial reports and projections
- Business strategies and roadmaps
- Employee compensation data
- Customer lists and contracts
- Source code (proprietary)
- Vendor contracts and pricing
- Internal security reports

**Handling rules:**
- Share only on need-to-know basis
- Use company-approved tools only (no personal email)
- Don't store on personal devices
- Password-protect if sending externally
- Don't discuss in public places

---

### Restricted
**Definition:** Highly sensitive data requiring maximum protection. Unauthorized 
disclosure could cause severe harm.

**Examples:**
- Customer personally identifiable information (PII)
- Payment card data
- Health information
- Passwords and encryption keys
- Authentication tokens and API secrets
- Security vulnerabilities (before patched)
- Legal matters and investigations

**Handling rules:**
- Access strictly limited to those who need it
- Encrypt at rest and in transit
- Never in email attachments (use secure sharing)
- Never on personal devices
- Log all access where possible
- Report any suspected exposure immediately
- Special handling for disposal (secure delete)

---

## Classifying new data

When creating or receiving new data:

1. **Consider the impact of exposure:**
   - Could it harm customers? → Restricted or Confidential
   - Could it harm the business? → Confidential
   - Is it just internal? → Internal
   - Can anyone see it? → Public

2. **When in doubt, classify higher** and ask Security Champion

3. **Mark classified documents** when practical:
   - Documents: Add classification to header/footer
   - Files: Include classification in filename (e.g., "Q4-financials-CONFIDENTIAL.xlsx")
   - Emails: Add classification to subject when sending Confidential/Restricted

---

## Handling by channel

| Channel | Public | Internal | Confidential | Restricted |
|---------|--------|----------|--------------|------------|
| **Company email** | ✓ | ✓ | ✓ (internal only) | ✗ (use secure share) |
| **Personal email** | ✓ | ✗ | ✗ | ✗ |
| **Company Slack** | ✓ | ✓ | ✓ (private channels) | ✗ |
| **Google Drive (company)** | ✓ | ✓ | ✓ (restricted sharing) | ✓ (encrypted, limited) |
| **Personal cloud storage** | ✓ | ✗ | ✗ | ✗ |
| **Printed documents** | ✓ | ✓ | Secure disposal | Secure disposal, limited printing |
| **External sharing** | ✓ | ✗ | Approved recipients, encrypted | Case-by-case approval |

---

## Data retention and disposal

| Classification | Retention | Disposal method |
|---------------|-----------|-----------------|
| Public | No limit | Normal deletion |
| Internal | [X years] or as needed | Normal deletion |
| Confidential | [X years] per legal/business need | Secure delete, shred paper |
| Restricted | Minimum necessary, per regulation | Secure delete, verified shred |

---

## Questions

Contact [SECURITY CHAMPION] at [EMAIL] with questions about classification 
or handling specific data.

Wo Richtlinien gespeichert und verwaltet werden

Richtlinien sind nutzlos, wenn niemand sie findet. Wählen Sie einen Speicheransatz, der zu Ihrer Unternehmenskultur passt.

Speichermöglichkeiten

Ansatz	Vorteile	Nachteile	Am besten für
Git-Repository	Versionskontrolle, PR-Review für Änderungen, entwicklerfreundlich, Audit-Trail	Nicht-technische Mitarbeitende können schwer bearbeiten	Entwicklungslastige Teams
Notion	Einfache Bearbeitung, gute Suche, professionelles Aussehen	Begrenzte Versionshistorie, unhandlicher Export	Die meisten kleinen Unternehmen
Confluence	Integration mit Jira, gute Berechtigungen	Kann unübersichtlich werden, langsamer	Unternehmen, die bereits Atlassian nutzen
Google Docs	Jeder kennt es, einfaches Teilen	Wird schnell unorganisiert, schlechte Suche	Schnellstart, sehr kleine Teams
SharePoint	Microsoft-Ökosystem, gute Berechtigungen	Komplex, oft unbeliebt	Microsoft-Shops
Dediziertes GRC-Tool (Vanta, Drata, Secureframe)	Compliance-bereit, Vorlagen, Beweissammlung	$$$, überdimensioniert für Grundlagen	SOC 2/ISO 27001-Vorbereitung

Git-basiertes Richtlinienmanagement

Für Technologieunternehmen hat die Speicherung von Richtlinien in Git echte Vorteile:

policies/
├── README.md                    # Index of all policies
├── acceptable-use-policy.md
├── incident-response-plan.md
├── data-classification.md
├── playbooks/
│   ├── ransomware.md
│   ├── compromised-account.md
│   └── data-breach.md
└── templates/
    ├── incident-log.md
    └── postmortem.md

Vorteile:

Änderungen erfordern PR-Review (Audit-Trail)
Diffs zeigen genau, was geändert wurde
Mitarbeitende kennen Git bereits
Einfach aus Code-Repositories zu verlinken
Werden auf GitHub/GitLab gut dargestellt

Tooling:

Markdown für Richtlinien verwenden
Mit MkDocs, Docusaurus oder GitBook rendern
CODEOWNERS einrichten, damit der Security Champion Änderungen genehmigt
Aus Mitarbeiterhandbuch und Onboarding-Dokumenten verlinken

Richtlinien auffindbar machen

Unabhängig vom Speicherort:

Einzige Quelle der Wahrheit — Ein Speicherort, nicht über Laufwerke verstreut
Im Onboarding verlinken — Jede neue Fachkraft sollte wissen, wo Richtlinien sind
In Slack als Lesezeichen — Im jeweiligen Kanal anpinnen
Suche funktioniert — Testen, ob Personen Richtlinien per Stichwortsuche finden können
URL stabil halten — Richtlinien nicht verschieben; Lesezeichen werden dann ungültig

Richtlinien-Versionierung

Änderungen und Zeitpunkte verfolgen:

## Version History

| Version | Date | Changes | Author |
|---------|------|---------|--------|
| 1.0 | 2024-01-15 | Initial release | [Name] |
| 1.1 | 2024-03-22 | Added remote work section | [Name] |
| 2.0 | 2024-06-01 | Major revision for SOC 2 | [Name] |

Bei Verwendung von Git ist Ihre Commit-Historie Ihre Versionshistorie.

Richtlinien an Ihr Unternehmen anpassen

Vorlagen sind Ausgangspunkte, keine fertigen Produkte. So passen Sie an:

Technologische Ausrichtung

Ersetzen Sie generische Tool-Referenzen durch Ihren tatsächlichen Stack:

Generischer Begriff	Tool Ihres Unternehmens
„Unternehmens-E-Mail"	Gmail, Outlook 365 usw.
„Genehmigte Dateifreigabe"	Google Drive, Dropbox Business usw.
„Unternehmens-Chat"	Slack, Teams usw.
„VPN"	Ihre spezifische VPN-Lösung
„Passwort-Manager"	Passwork oder Ihre gewählte Lösung

Kulturelle Anpassung

Ton und Strenge anpassen:

Startup mit lockerer Kultur: Gesprächiger, weniger formale Abschnitte
B2B mit Enterprise-Kunden: Förmlicher, detailliertere Compliance-Abschnitte
Remote-first: Mehr Gewicht auf Fernarbeit-Sicherheit
Entwicklerlastig: Technisches Publikum, kann technische Begriffe verwenden

Regulatorische Anforderungen

Abschnitte basierend auf Compliance-Anforderungen hinzufügen:

DSGVO: Betroffenenrechte, Meldefristen für Datenschutzverletzungen
HIPAA: PHI-Handhabung, Anforderungen an Geschäftspartner
PCI DSS: Schutz von Karteninhaberdaten
SOC 2: Dokumentation der Kontrollen

Häufige Anpassungen

Situation	Anpassung
Vollständig remote arbeitendes Unternehmen	Fernarbeits-Abschnitt erweitern, Anforderungen zur Heimsicherheit
BYOD erlaubt	Detaillierte Anforderungen für private Geräte
Zahlungsdaten verarbeiten	PCI DSS-spezifische Anforderungen
Internationales Team	Mehrere Rechtsordnungen berücksichtigen
Stark regulierte Branche	Spezifische Compliance-Sprache

Richtlinien einführen

Richtlinien zu schreiben ist die halbe Arbeit. Menschen dazu zu bringen, sie zu befolgen, ist die andere Hälfte.

Einführungs-Checkliste

Führungsebene abzeichnen lassen — Richtlinien bedeuten ohne Management-Backing nichts
Mit Kontext ankündigen — Erklären, warum, nicht nur was
Richtlinien auffindbar machen — Zentraler Speicherort, nicht in E-Mails vergraben
Bestätigung einfordern — Unterschrift oder Checkbox-Bestätigung
Zu Kernpunkten schulen — Nicht erwarten, dass Personen jeden Satz lesen
Fragen beantworten — Sprechstunden oder Q&A-Kanal anbieten
Konsequent durchsetzen — Erste Verstöße sind entscheidend

Ankündigungs-Vorlage

Subject: New Security Policies — Action Required by [DATE]

Team,

We're rolling out three security policies that define how we protect company 
and customer data. These aren't bureaucracy for bureaucracy's sake — they're 
our answer to "what should I do when..."

**The policies:**
1. Acceptable Use Policy — What's allowed with work computers and data
2. Incident Response Plan — What to do when something goes wrong
3. Data Classification — How to handle different types of information

**What you need to do:**
1. Read the policies: [LINK TO POLICIES]
2. Sign the acknowledgment: [LINK TO FORM]
3. Complete by: [DATE]

**Key takeaways** (if you read nothing else):
- Enable MFA on everything
- Report suspicious stuff to #security-incidents
- Don't put Restricted data (customer PII, passwords) in email
- Lock your computer when you walk away

I'll hold a Q&A session on [DATE] at [TIME] — bring your questions. 
Or ask anytime in #security-questions.

[YOUR NAME]

Richtlinien lebendig halten

Richtlinien werden zu Altpapier, wenn Sie sie nicht aktiv pflegen:

Jährliche Überprüfung — Für neue Tools, veränderte Bedrohungen, gelernte Lektionen aktualisieren
Vorfalls-Trigger — IRP nach jedem bedeutenden Vorfall aktualisieren
Onboarding neuer Mitarbeitender — Richtlinienüberprüfung in der ersten Woche einschließen
Auffrischungsschulung — Jährliche Erinnerung an Kernpunkte
Ausnahmen verfolgen — Genehmigte Ausnahmen auf Muster überprüfen

Häufige Fehler

Kopieren ohne Anpassen — Richtlinien, die Tools referenzieren, die Sie nicht nutzen
Zu lang — Niemand liest eine 30-seitige AUP
Zu vage — „Gesunden Menschenverstand nutzen" ist nicht umsetzbar
Keine Durchsetzung — Regeln ohne Konsequenzen werden zu Empfehlungen
Kein Ausnahmeprozess — Personen ignorieren Regeln, denen sie nicht folgen können
Juristisches Fachjargon — Mitarbeitende hören bei dichtem Juristendeutsch weg
Einmal erstellen und vergessen — Richtlinien veralten schnell
Kein Training — Erwarten, dass Personen alles selbständig lesen und verstehen
Mit allem anfangen — Besser 3 solide Richtlinien als 10 Entwürfe
Keine Beteiligung von Stakeholdern — Richtlinien, die nicht widerspiegeln, wie die Arbeit tatsächlich abläuft

Workshop: Ihre Richtlinien erstellen

Teil 1: Acceptable Use Policy

Zeit: 2–3 Stunden

Informationen sammeln:
- Aktuelle Tools und Systeme überprüfen
- Mit IT/DevOps über aktuelle Sicherheitspraktiken sprechen
- HR nach bestehenden Mitarbeiterrichtlinien fragen
- Compliance-Anforderungen notieren
Richtlinie entwerfen:
- Obige Vorlage als Ausgangspunkt verwenden
- Alle [IN ECKIGEN KLAMMERN] Platzhalter ersetzen
- Unternehmensspezifische Regeln hinzufügen
- Nicht zutreffende Abschnitte entfernen
Überprüfen:
- Jemanden außerhalb des Teams auf Verständlichkeit lesen lassen
- Bei vorhandenem Rechtsbeistand prüfen lassen
- Genehmigung der Führungsebene einholen

Teil 2: Notfallplan

Zeit: 3–4 Stunden

Ihr Team definieren:
- Wer ist Incident Lead? Stellvertretung?
- Wer übernimmt die technische Untersuchung?
- Wer übernimmt die Kommunikation?
- Telefonnummern für Kontakte außerhalb der Geschäftszeiten einholen
Plan anpassen:
- Kontaktliste mit Ihren Personen aktualisieren
- Schweregrade an Ihren Kontext anpassen
- Spezifische Tools und Zugangsmethoden hinzufügen
- Externe Kontakte einschließen (Versicherung, Rechtsberatung)
Grundlagen testen:
- Weiß jeder, wie ein Vorfall gemeldet wird?
- Können Sie Reaktionsteam-Mitglieder nach Geschäftszeiten erreichen?
- Haben Sie Zugang zu notwendigen Systemen?

Teil 3: Datenklassifizierung

Zeit: 1–2 Stunden

Daten inventarisieren:
- Kundendaten: welche Typen, wo gespeichert?
- Geschäftsdaten: Finanzen, Strategie, HR?
- Technische Daten: Zugangsdaten, Konfigurationen?
Wichtige Datentypen klassifizieren:
- Jeden Typ Öffentlich/Intern/Vertraulich/Streng vertraulich zuordnen
- Notieren, wo jeder Typ gespeichert ist
Handhabungsregeln definieren:
- Welche Tools für jede Stufe verwendet werden dürfen
- Wer auf jede Stufe zugreifen darf
- Wie lange aufbewahrt werden soll

Zu erstellende Artefakte

Nach diesem Workshop sollten Sie haben:

Fertige Acceptable Use Policy (2–3 Seiten)
Fertiger Notfallplan (3–5 Seiten)
Fertige Datenklassifizierungsrichtlinie (1–2 Seiten)
Bestätigungsformular für Mitarbeitende
Entwurf der Einführungsankündigung
Speicherort der Richtlinien (Wiki-Seite, Shared-Drive-Ordner)

Selbstkontrollfragen

Was sind die drei wesentlichen Richtlinien, die jedes Unternehmen haben sollte?
Warum sollten Richtlinien kurz sein (unter 5 Seiten)?
Was ist der Unterschied zwischen Vertraulichen und Streng vertraulichen Daten?
Wer sollte in einem kleinen Unternehmen zum Reaktionsteam gehören?
Wann sollten Sie Kunden über einen Sicherheitsvorfall informieren?
Warum ist ein schuldfreies Postmortem wichtig?
Wie oft sollten Richtlinien überprüft und aktualisiert werden?
Was tun, wenn ein Mitarbeiter die AUP nicht befolgt?
Warum sollte das „Warum" in Richtlinien enthalten sein?
Was ist der erste Schritt, wenn Sie einen Vorfall vermuten?

So erklären Sie das der Führungsebene

Die Botschaft: „Wir brauchen drei Kerndokumente: was Mitarbeitende mit Unternehmensressourcen tun dürfen, was zu tun ist, wenn etwas schiefgeht, und wie mit verschiedenen Datentypen umzugehen ist. Diese schützen uns rechtlich, helfen uns schneller auf Vorfälle zu reagieren, und werden oft von Kunden und Versicherern verlangt."

Der ROI:

Schnellere Vorfallsreaktion (Stunden statt tagelanger Verwirrung)
Rechtlicher Schutz bei Fehlverhalten von Mitarbeitenden
Erforderlich für die meisten Cyber-Versicherungspolicen
Von B2B-Kunden bei Sicherheitsüberprüfungen angefragt
Grundlage für jede zukünftige Compliance (SOC 2 usw.)

Die Bitte: „Ich benötige 2–3 Stunden für die Entwürfe, eine Überprüfung durch die Führungsebene und eine Unternehmensankündigung, die die Bestätigung verpflichtend macht. Gesamter Zeitaufwand für das Unternehmen: vielleicht 30 Minuten pro Mitarbeiter zum Lesen und Unterschreiben."

Das Risiko der Untätigkeit: „Im Moment weiß bei einem Datenschutzvorfall niemand genau, was zu tun ist. Wir würden es um 2 Uhr nachts improvisieren. Und wenn ein Mitarbeiter etwas Unüberlegtes mit Unternehmensdaten macht, haben wir keine dokumentierte Richtlinie, die zeigt, dass er es besser wissen sollte."

Fazit

Richtlinien, die niemand liest, schützen niemanden. Eine einseitige Acceptable Use Policy, die jeder unterschrieben hat, schlägt ein 40-seitiges Compliance-Dokument, das auf einem Shared Drive liegt.

Schreiben Sie für die Menschen, die der Richtlinie folgen werden – nicht für den Prüfer, der sie überprüft.

Was kommt als Nächstes

Weiter geht es mit: Sicherheitskommunikation und Evangelismus — wie man über Sicherheit spricht, sodass Menschen ihr Verhalten tatsächlich ändern.

Warum Richtlinien für kleine Unternehmen wichtig sind​

Grundsätze für das Schreiben von Richtlinien​

Kurz halten​

Klare Sprache verwenden​

Bei Konsequenzen konkret sein​

Das „Warum" erklären​

Ausnahmen klar definieren​

Von Unternehmen lernen, die ihre Richtlinien veröffentlichen​

Öffentliche Richtlinienbeispiele​

Kostenlose Richtlinienvorlagen​

Schnellstart: Mindest-Richtlinien​

Reale Vorfälle: was ohne Richtlinien passiert​

Kein Notfallplan​

Keine Acceptable Use Policy​

Keine Datenklassifizierung​

Acceptable Use Policy (AUP)​

Was abzudecken ist​

AUP-Vorlage​

Häufige AUP-Fehler​

Notfallplan (IRP)​

Warum Sie einen IRP brauchen, bevor ein Vorfall eintritt​

IRP-Struktur​

IRP-Vorlage​

Incident Log: [INCIDENT NAME]​

Timeline​

Affected systems​

Evidence preserved​

Key decisions​

10. Contact list​

Internal​

External​

Appendix: Quick reference cards​

If you suspect your account is compromised​

If you clicked a phishing link​

If you see ransomware​

Datenklassifizierungsrichtlinie​

Warum Daten klassifizieren?​

Einfaches Klassifizierungsschema​

Vorlage für Datenklassifizierungsrichtlinie​

Wo Richtlinien gespeichert und verwaltet werden​

Speichermöglichkeiten​

Git-basiertes Richtlinienmanagement​

Richtlinien auffindbar machen​

Richtlinien-Versionierung​

Richtlinien an Ihr Unternehmen anpassen​

Technologische Ausrichtung​

Kulturelle Anpassung​

Regulatorische Anforderungen​

Häufige Anpassungen​

Richtlinien einführen​

Einführungs-Checkliste​

Ankündigungs-Vorlage​

Richtlinien lebendig halten​

Häufige Fehler​

Workshop: Ihre Richtlinien erstellen​

Teil 1: Acceptable Use Policy​

Teil 2: Notfallplan​

Teil 3: Datenklassifizierung​

Zu erstellende Artefakte​

Selbstkontrollfragen​

So erklären Sie das der Führungsebene​

Fazit​

Was kommt als Nächstes​