Breach Notification & Incident Response
- Executive Summary
- Working Knowledge
- Technical Spec
A data breach at ReGenesis would expose some of the most sensitive personal content in enterprise software — coaching transcripts, personal reflections, emotional insights, and AI-derived behavioral patterns. The reputational and legal consequences would be severe. The incident response strategy is not just a compliance checkbox; it is a business-critical capability that enterprise clients evaluate during procurement.
Under GDPR, ReGenesis has 72 hours from awareness of a breach to notify the data controller (the enterprise client), who then notifies the supervisory authority. Under various US state laws, notification timelines range from 30 to 60 days to affected individuals. The target is aggressive: internal detection within 1 hour, controller notification within 36 hours — giving the controller a full 36-hour buffer to meet their own 72-hour obligation.
The approach goes beyond notification: ReGenesis invests in prevention (security monitoring, anomaly detection), preparation (tabletop exercises, runbooks, war rooms), and post-incident improvement (blameless post-mortems, control enhancements). The goal is to build an incident response muscle that gets stronger with every exercise and every near-miss, so that if a real breach occurs, the response is swift, coordinated, and minimizes harm.
The 72-Hour Clock
When a personal data breach is detected, the GDPR clock starts ticking:
What Counts as a Breach?
A personal data breach is any security incident that leads to the accidental or unlawful:
- Destruction of personal data (data loss)
- Loss of personal data (cannot access it)
- Alteration of personal data (unauthorized modification)
- Unauthorized disclosure of personal data (data exposed to wrong person)
- Unauthorized access to personal data (someone sees data they should not)
Examples specific to ReGenesis:
| Scenario | Breach Type | Severity |
|---|---|---|
| Coaching transcript accidentally shown to wrong coachee | Unauthorized disclosure | High |
| Database backup lost without encryption | Loss | Critical |
| Coach sees another coach's client notes | Unauthorized access | High |
| Sasha generates insight using data from wrong user context | Unauthorized processing | Medium |
| DDoS attack makes platform unavailable for 48 hours | Loss of availability | Medium |
| Employee laptop stolen with cached session data | Potential unauthorized access | High |
| LLM provider breach exposing cached prompts | Unauthorized disclosure | Critical |
The Incident Response Plan
Severity Levels
| Level | Description | Examples | Response Time | Escalation |
|---|---|---|---|---|
| SEV-1 Critical | Confirmed breach of sensitive personal data | Mass data exfiltration, LLM provider compromise, unencrypted backup exposure | Immediate | CEO, legal counsel, all controllers |
| SEV-2 High | Confirmed breach of personal data, limited scope | Single-user data exposure, unauthorized coach access, API key compromise | 1 hour | CTO, DPO, affected controller |
| SEV-3 Medium | Potential breach or security vulnerability | Anomalous access pattern, unpatched CVE, failed auth spike | 4 hours | Security team, engineering lead |
| SEV-4 Low | Security event, no breach confirmed | Port scan, brute force attempt (blocked), suspicious but contained | 24 hours | Security team (log and monitor) |
Response Phases
Phase 1: Detection & Triage (0-1 hour)
- Security monitoring system generates alert
- On-call engineer assesses initial severity
- If SEV-1 or SEV-2: activate Incident Commander
- Create incident channel (Slack/Teams) and incident record
Phase 2: Containment (1-4 hours)
- Isolate affected systems (network segmentation, API key rotation)
- Preserve evidence (snapshot logs, freeze database state)
- Prevent further data exposure
- Activate legal counsel if SEV-1 or SEV-2
Phase 3: Assessment (4-12 hours)
- Determine scope: what data, whose data, how much
- Identify root cause
- Assess risk to data subjects
- Document findings in incident record
Phase 4: Notification (12-36 hours)
- Prepare notification to affected enterprise client (controller)
- Include: nature of breach, data categories, approximate number of affected individuals, likely consequences, measures taken
- Controller decides whether to notify supervisory authority and individuals
- Provide ongoing support and updates
Phase 5: Recovery (24-72 hours)
- Remediate vulnerability
- Restore affected systems
- Verify containment is complete
- Monitor for recurrence
Phase 6: Post-Mortem (1-2 weeks post-incident)
- Blameless post-mortem meeting
- Root cause analysis (5 Whys)
- Document lessons learned
- Create action items for control improvements
- Update runbooks and detection rules
- Share anonymized learnings with team
Security Monitoring & Detection
Monitoring Signals
| Signal | Detection Method | Alert Threshold | Response |
|---|---|---|---|
| Unauthorized data access | Audit log analysis | Any access outside RBAC scope | SEV-2 immediate |
| Anomalous query patterns | ML anomaly detection | >2 sigma deviation from baseline | SEV-3 investigate |
| Failed authentication spikes | Auth system monitoring | >10 failed attempts per user per hour | SEV-4 auto-block + alert |
| API rate limit violations | API gateway metrics | >5x normal rate | SEV-3 investigate |
| Data exfiltration signals | Outbound data volume monitoring | >100MB export by single user | SEV-3 investigate |
| Infrastructure compromise | AWS GuardDuty + CloudTrail | Any GuardDuty finding | SEV varies by finding |
| LLM provider anomalies | Response monitoring | Unexpected data in LLM responses | SEV-2 investigate |
Audit Logging for Investigation
Every data access event is logged in a tamper-evident audit log:
{
"timestamp": "2026-01-15T14:32:07Z",
"eventType": "data_access",
"actor": "coach_user_123",
"actorRole": "coach",
"resource": "session_transcript_456",
"resourceOwner": "coachee_user_789",
"action": "read",
"authorized": true,
"accessContext": "coaching_session_view",
"ipAddress": "203.0.113.42",
"userAgent": "Mozilla/5.0...",
"sessionId": "sess_abc123"
}
The most important part of incident response is what happens after. A blameless post-mortem culture means people report incidents and near-misses without fear. Every incident makes the organization stronger — if teams learn from it. The alternative is hiding problems until they become catastrophes.
Tabletop Exercises
ReGenesis runs regular tabletop exercises to practice incident response without a real breach. These are scenario-based discussions where the IR team walks through a hypothetical breach.
Example Scenarios
- "The Leaked Transcript" — A coaching session transcript appears on a public paste site. How does the team determine scope, contain, and notify?
- "The Insider Threat" — A system admin is accessing coaching content they should not see. How does the team detect, investigate, and respond?
- "The LLM Leak" — The LLM provider reports a potential data exposure in their inference pipeline. What happens next?
- "The Ransomware Attack" — The primary database is encrypted by ransomware. How does the team recover without paying ransom?
- "The Regulator Call" — A GDPR supervisory authority contacts ReGenesis about a complaint. How does the team respond?
Exercise Schedule
| Exercise Type | Frequency | Participants | Duration |
|---|---|---|---|
| Tabletop discussion | Quarterly | Full IR team | 2 hours |
| Technical simulation | Semi-annually | Engineering + security | 4 hours |
| Full IR drill | Annually | All hands (including legal + exec) | Full day |
| Red team exercise | Annually (GA+) | External security firm | 1 week |
A breach of coaching session data is not like a breach of email addresses. These are deeply personal reflections, emotional vulnerabilities, and private developmental struggles. The harm to individuals — and to ReGenesis's reputation — would be severe. Incident response is not optional; it is a core business function.