Skip to content

Incident Response Plan

Document ID: PROC-001 Document owner: Jan Marc Castlunger (ISO) Classification: Confidential Version: 0.9 (Draft — tabletop exercise scheduled 21 March 2026) Last updated: March 2026 Target completion: 21 March 2026 (upgrade to v1.0 after tabletop exercise) Frameworks: ISO 27001 (A.5.24, A.5.25, A.5.26, A.5.27) | SOC 2 (CC7.3, CC7.4, CC7.5)

Tabletop Exercise Scheduled

Tabletop exercise scheduled for 21 March 2026, 09:00 CET — see Exercise Plan. Following the exercise and management review approval, this document will be upgraded to v1.0 (Approved).


1. Purpose

This plan establishes procedures for detecting, responding to, and recovering from information security incidents at CTW Data Solutions GmbH. It ensures that incidents are handled consistently and that legal obligations (including GDPR 72-hour breach notification) are met.


2. Scope

All information security events and incidents affecting CTW Data Solutions GmbH systems, data, or personnel — including those involving third-party suppliers (Azure, GitHub, Google Workspace).


3. Incident Classification

Severity Examples Max Response Time Escalation
🔴 P1 — Critical Breach of ID/personal data, ransomware, full API outage Immediate (< 1 hour) ISO + DPO within 2h; GDPR authority within 72h; affected customers within 24h
🟡 P2 — High Suspected credential compromise, API abuse, partial outage < 4 hours ISO notified immediately; DPO if personal data at risk
🟠 P3 — Medium Failed login spike, unusual access pattern, minor vulnerability < 24 hours ISO reviews; document and monitor
⚪ P4 — Low Policy violation, misconfiguration (no breach confirmed) < 72 hours Document and remediate; include in next quarterly review

4. Response Procedure

Step 1 — Detect & Report

  • Any employee who suspects a security incident must report it immediately to the ISO via:
  • Direct message (primary)
  • Email: security@quick-id.com
  • Azure Monitor and GitHub Security alerts are automatically routed to ISO
  • All incidents must be logged in the Incident Register: Google Drive > Security > Incidents

Step 2 — Assess & Classify

  • ISO assesses severity within 1 hour of detection
  • DPO is notified immediately if personal data may be involved
  • Initial assessment documents:
  • What happened?
  • Which systems/data are affected?
  • Is the incident contained or ongoing?

Step 3 — Contain & Eradicate

  1. Immediately revoke tokens and sessions in Azure AD / GitHub
  2. Rotate affected keys via Azure Key Vault
  3. Disable affected accounts
  4. Audit access logs for the past 30 days
  5. Notify affected API customers if their data was accessible
  1. Preserve forensic evidence — do NOT modify or delete logs
  2. Isolate affected systems if safe to do so
  3. Document exact scope: which records, which time window
  4. Engage DPO immediately — GDPR clock starts now
  5. Notify ISO and begin customer notification preparation
  1. Immediately isolate affected Azure resources (network-level)
  2. Do NOT pay ransom — restore from verified backups
  3. Engage Microsoft Azure support (Severity A)
  4. Restore from most recent clean backup snapshot
  5. Confirm backup integrity before returning to production
  1. Rotate ALL secrets referenced in affected repos immediately
  2. Revoke all GitHub personal access tokens and OAuth apps
  3. Audit GitHub audit log for the past 90 days
  4. Review and notify any affected API customers
  5. Conduct full dependency audit

Step 4 — Notify

GDPR 72-Hour Rule

If personal data of EU residents is involved, the DPO must notify the competent Supervisory Authority within 72 hours of becoming aware of the breach. In Germany: BfDI (Bundesbeauftragte fur den Datenschutz) or relevant Landesbehorde.

Who When How
DPO (internal) Immediately on P1/P2 with personal data Direct message
Supervisory Authority (BfDI) Within 72 hours of confirmed personal data breach Online portal / written notification
Affected API customers Within 24 hours of confirmed breach Email + https://app.quick-id.com/health/
All staff Within 24 hours for P1 incidents All-hands message from ISO

Step 5 — Recover & Close

  1. Restore from verified Azure backups; confirm integrity before returning to production
  2. Validate all systems are clean before resuming normal operations
  3. Conduct post-incident review within 5 business days — document:
  4. Root cause
  5. Timeline of events
  6. What worked / what failed
  7. Lessons learned
  8. Update Risk Register and controls as required
  9. Close incident record with final status
  10. File Corrective Action if systemic issues identified

5. Incident Register

All incidents are logged in Google Drive > Security > Incidents using the Incident Report Template.

Field Description
Incident ID INC-YYYY-NNN (e.g. INC-2026-001)
Date detected
Date reported
Severity P1 / P2 / P3 / P4
Description
Systems affected
Personal data involved? Yes / No / Unknown
Actions taken
Resolution date
Post-incident review date

6. Contact Directory

Role Name Contact Available
Jan Marc Castlunger (ISO) Jan Marc Castlunger +39 338 265 6358 24/7 for P1
DPO / CTO Sebastian Windeck +49 170 837 1038 24/7 for P1
Chief of AI Malte Toetzke +49 178 488 0322 Business hours; on-call for P1
Microsoft Azure Support via Azure Portal — Severity A 24/7
GitHub Support support.github.com Business hours
BfDI (German DPA) www.bfdi.bund.de Business hours
API Status Page https://app.quick-id.com/health/ Public