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¶
- Immediately revoke tokens and sessions in Azure AD / GitHub
- Rotate affected keys via Azure Key Vault
- Disable affected accounts
- Audit access logs for the past 30 days
- Notify affected API customers if their data was accessible
- Preserve forensic evidence — do NOT modify or delete logs
- Isolate affected systems if safe to do so
- Document exact scope: which records, which time window
- Engage DPO immediately — GDPR clock starts now
- Notify ISO and begin customer notification preparation
- Immediately isolate affected Azure resources (network-level)
- Do NOT pay ransom — restore from verified backups
- Engage Microsoft Azure support (Severity A)
- Restore from most recent clean backup snapshot
- Confirm backup integrity before returning to production
- Rotate ALL secrets referenced in affected repos immediately
- Revoke all GitHub personal access tokens and OAuth apps
- Audit GitHub audit log for the past 90 days
- Review and notify any affected API customers
- 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¶
- Restore from verified Azure backups; confirm integrity before returning to production
- Validate all systems are clean before resuming normal operations
- Conduct post-incident review within 5 business days — document:
- Root cause
- Timeline of events
- What worked / what failed
- Lessons learned
- Update Risk Register and controls as required
- Close incident record with final status
- 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 |