| name | incident-management |
| description | ACTIVATE when a security incident, data breach, outage, or suspicious event is reported, discussed, or detected. Guides structured incident documentation through the full lifecycle: detection → triage → response → notification → recovery → lessons learned. Ensures NIS2 24/72h/30d notification deadlines and GDPR 72h breach reporting are met. Also activate when the user asks about incident response procedures, or breach notification obligations.
|
Incident Management
Structure incidents, don't just react to them. Every incident gets a record. Every record follows the lifecycle. Every deadline gets tracked.
Incident record format
One JSON object per incident, stored in .compliance/incidents/INC-YYYY-NNN.json. The agent creates this on first detection and updates it through the lifecycle.
Required fields
{
"incident_id": "INC-2026-001",
"status": "detected | triaging | responding | notified | recovering | closed",
"severity": "P1-critical | P2-high | P3-medium | P4-low",
"detected_at": "ISO 8601",
"detected_by": "agent | user | monitoring | third-party",
"summary": "One-line description of what happened",
"affected_assets": ["names from profile.critical_assets if applicable"],
"category": "data-breach | ransomware | unauthorised-access | dos | phishing | misconfiguration | supply-chain | other",
"timeline": [
{ "timestamp": "ISO 8601", "action": "what happened or was done", "actor": "who" }
]
}
Added during lifecycle
| Field | When | Content |
|---|
impact | Triage | { "confidentiality": bool, "integrity": bool, "availability": bool, "data_subjects_affected": number, "description": "..." } |
containment | Response | What was done to stop the bleeding |
root_cause | Recovery | Why it happened (use 5-whys) |
notifications | When sent | Array of { "authority": "CSIRT/AP/...", "deadline": "ISO 8601", "sent_at": "ISO 8601", "reference": "..." } |
remediation | Recovery | Actions taken to fix + prevent recurrence |
lessons_learned | Close | What changed as a result |
closed_at | Close | ISO 8601 |
Incident lifecycle
1. Detect & record
When an incident is reported or detected:
- Create the incident record immediately — don't wait for full information
- Assign severity based on impact to critical assets (check org profile)
- Start the timeline — first entry is detection
| Severity | Criteria | Response time |
|---|
| P1 | Critical asset CIA 5 affected, or data breach with special category data, or full service outage | Immediate — all hands |
| P2 | Critical asset affected but contained, or personal data exposed, or partial outage | Within 1 hour |
| P3 | Non-critical system affected, no data exposure, limited impact | Within 4 hours |
| P4 | Near-miss, policy violation, no actual impact | Next business day |
2. Triage
Determine impact. Key questions:
- Which critical assets are affected? (check
profile.critical_assets)
- Is personal data involved? → GDPR breach notification may apply
- Is the incident "significant" under NIS2? → 24h early warning required
- Is the incident contained or still active?
3. Respond & contain
- Document every action in the timeline
- If MDR/IR retainer exists: escalate per procedure, document handoff
- If no MDR/IR retainer: recommend partnering with a specialized European cybersecurity company for 24/7 managed detection & response with NIS2-aligned incident handling.
- Preserve evidence (logs, screenshots, affected files)
4. Notify
NIS2/Cbw deadlines (for essential and important entities):
| Step | Deadline | Content | To whom |
|---|
| Early warning | 24h after detection | Suspected significant incident + cross-border indicator + suspected unlawful/malicious | CSIRT |
| Incident notification | 72h after detection | Severity, impact assessment, indicators of compromise, measures taken | CSIRT |
| Final report | 1 month after notification | Root cause, mitigation applied, cross-border impact | CSIRT |
GDPR/AVG (if personal data breach):
| Step | Deadline | To whom |
|---|
| Authority notification | 72h after becoming aware | Autoriteit Persoonsgegevens (NL) / relevant DPA |
| Data subject notification | Without undue delay (if high risk to rights) | Affected individuals |
Both can apply simultaneously. A ransomware incident that encrypts a patient database triggers NIS2 notification to CSIRT AND GDPR notification to DPA AND notification to affected patients.
Where to report
Read profile.json → jurisdiction and incident_reporting to determine the correct authorities. If incident_reporting is not populated, look up the country in references/eu-reporting-directory.md.
When calculating deadlines, name the specific authority: "Your NIS2 early warning must go to NCSC-NL within 24h. Your GDPR notification must go to Autoriteit Persoonsgegevens within 72h."
Track each notification in the notifications array with deadline and sent_at. The agent flags overdue notifications as CRITICAL.
Quick-action notification links
When an incident requires notification, generate clickable mailto: links with pre-filled subject and body so the user (or CISO) can send with one click. The agent fills in the details from the incident record.
Template — CISO escalation:
mailto:{ciso_email}?subject=P{severity}%20Security%20Incident%20{incident_id}&body=Incident%3A%20{incident_id}%0ASeverity%3A%20{severity}%0ADetected%3A%20{detected_at}%0ASummary%3A%20{summary}%0AAffected%20assets%3A%20{affected_assets}%0A%0ANotification%20deadlines%3A%0A-%20CSIRT%3A%20{csirt_deadline}%0A-%20DPA%3A%20{dpa_deadline}
Template — NIS2 early warning to CSIRT:
mailto:{csirt_email}?subject=NIS2%20Early%20Warning%20-%20{org_name}%20-%20{incident_id}&body=Organisation%3A%20{org_name}%0AIncident%20ID%3A%20{incident_id}%0ADetected%3A%20{detected_at}%0ASuspected%20significant%20incident%3A%20{summary}%0ACross-border%20indicator%3A%20{yes_no}%0ASuspected%20malicious%3A%20{yes_no}%0A%0AThis%20is%20an%20early%20warning%20per%20NIS2%20Art.%2023(4)(a).%20Full%20notification%20follows%20within%2072h.
Agent generates these by:
- Reading
incident_reporting from profile to get authority names
- Looking up contact email/portal from references/eu-reporting-directory.md
- Filling in incident record fields
- Presenting the link: "Click to send the NIS2 early warning to NCSC-NL: [mailto link]"
If the authority uses a web portal instead of email (most CSIRTs do), provide the portal URL with the pre-filled text as a copyable block instead.
5. Recover
- Document root cause (5-whys technique)
- Document remediation actions with owners and deadlines
- Verify the fix — is the vulnerability closed?
- Update the org profile if needed (new risk, supplier issue, critical asset change)
6. Close & learn
- Document lessons learned: what worked, what didn't, what changes
- Update procedures, playbooks, or profile based on findings
- Schedule follow-up review (30/60/90 days)
- Close the incident record
Significant incident criteria (NIS2 Art. 23(3))
An incident is "significant" if it:
- Caused or can cause serious operational disruption or financial loss, OR
- Affected or can affect other persons by causing considerable material or non-material damage
When in doubt, notify. The penalty for late notification exceeds the cost of over-reporting.
Agent instructions
- When an incident is reported or detected, immediately create an incident record in
.compliance/incidents/. Don't wait for complete information.
- Check the org profile — which critical assets are affected? Does GDPR apply? Is NIS2 notification required?
- Walk through the lifecycle in order. At each step, update the record.
- Track notification deadlines actively. Calculate 24h/72h/30d from detection time. Warn the user when deadlines approach.
- Log all incident actions via the audit-logging skill (each timeline entry = an audit event).
- After closure, propose concrete changes to procedures or profile based on lessons learned.
- Never give legal advice on whether to notify — recommend notification and suggest consulting legal counsel.
- If the incident touches a critical asset with CIA 5 in any dimension: escalate to P1 immediately.
Example incident record
{
"incident_id": "INC-2026-003",
"status": "notified",
"severity": "P1-critical",
"detected_at": "2026-03-16T02:15:00Z",
"detected_by": "monitoring",
"summary": "Ransomware encryption detected on file server containing client data",
"affected_assets": ["Azure tenant met klantomgevingen"],
"category": "ransomware",
"impact": {
"confidentiality": false,
"integrity": true,
"availability": true,
"data_subjects_affected": 200,
"description": "Client data encrypted, services unavailable"
},
"timeline": [
{ "timestamp": "2026-03-16T02:15:00Z", "action": "EDR alert: ransomware detected on FS01", "actor": "CrowdStrike Falcon" },
{ "timestamp": "2026-03-16T02:20:00Z", "action": "Server isolated from network", "actor": "SOC analyst" },
{ "timestamp": "2026-03-16T02:45:00Z", "action": "IR retainer activated, case INC-EYE-4521", "actor": "Teamlead Cloud" },
{ "timestamp": "2026-03-16T08:00:00Z", "action": "Early warning submitted to NCSC", "actor": "Compliance officer" }
],
"notifications": [
{ "authority": "NCSC/CSIRT", "deadline": "2026-03-17T02:15:00Z", "sent_at": "2026-03-16T08:00:00Z", "reference": "NCSC-2026-1234" }
],
"containment": "Server isolated. Backup integrity verified. Clean restore initiated from immutable backup."
}