incident-response-logger

Incident Response Logger

Structures AI incident reports to align with NIST SP 800-61 response phases and EU AI Act Article 62 serious incident reporting obligations. Produces a completed report ready for internal review, legal sign-off, and regulatory submission where required.

---

Step 1 — Triage the Incident

Before drafting the report, collect the critical facts and determine severity. Infer from conversation where possible; ask only for what's genuinely missing.

Minimum required to proceed:

1. What happened? (plain-language description of the AI system's failure or unexpected behaviour)
2. When did it happen? (date and time, or approximate timeframe)
3. What AI system was involved? (system name, version, deployment context)
4. Who or what was affected? (users, individuals, processes, data, infrastructure)
5. Is the incident ongoing or contained?

Severity screen — ask these immediately:

Load references/article-62-thresholds.md and check whether the incident meets the EU AI Act Article 62 serious incident threshold:

• Did the incident result in death or serious harm to health?
• Did it result in serious and irreversible disruption to critical infrastructure?
• Did it result in a serious breach of fundamental rights obligations?
• Did it result in serious damage to property or the environment?
• Is the system a high-risk AI system under Annex III?

If ANY serious incident threshold is met → flag immediately and proceed to Step 2 with URGENT status. Article 62 notification to the national market surveillance authority may be required within 15 working days.

---

Step 2 — Load References

Load the appropriate reference files based on severity and applicable frameworks:

Condition	Load
Always	references/nist-800-61-phases.md
EU high-risk AI system involved	references/article-62-thresholds.md
Both	Both files

---

Step 3 — Build the Incident Report

Generate a structured incident report. Pre-fill every field you can from the conversation. Use [ to be confirmed — [owner] ] for fields the user will need to complete, naming a specific role (e.g., Legal, DPO, Engineering Lead) so the report is immediately actionable.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚨 AI INCIDENT REPORT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️ ADVISORY NOTICE
───────────────────
This report is generated by an AI skill and is provided for informational and
governance support purposes only. It does not constitute legal advice, regulatory
advice, or a formal compliance determination. Do not submit this report to a
regulatory authority or rely on it as a substitute for review by qualified legal
counsel or a licensed compliance professional with jurisdiction-specific expertise.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Report ID:        INC-[YYYYMMDD]-[NNN]
Status:           🔴 URGENT / 🟡 ELEVATED / 🟢 STANDARD
Created:          [date/time]
Created by:       [name / role]
Last updated:     [date/time]

SECTION 1 — INCIDENT IDENTIFICATION
──────────────────────────────────────
System name:      [AI system name and version]
Deployment context: [where/how the system is used]
Incident type:    [ Harmful output / Bias / Privacy breach / Safety failure /
                    System failure / Unauthorised access / Other: ___ ]
Occurred:         [date and time, or range]
Detected:         [date and time]
Detection method: [ User report / Automated monitoring / Internal review /
                    Regulatory notification / Media / Other: ___ ]
Reported by:      [name / role / channel]

SECTION 2 — INCIDENT DESCRIPTION
───────────────────────────────────
What happened:
[Plain-language narrative — what the AI system did or failed to do, in enough
detail for a non-technical reviewer to understand the failure. Include the
specific input(s) that triggered the failure where known.]

What was expected:
[What the system should have done instead.]

Root cause (initial assessment):
[ Known / Under investigation — owner: Engineering Lead ]
[If known: brief description of likely technical or operational cause]

SECTION 3 — IMPACT ASSESSMENT
───────────────────────────────
Individuals affected:    [number or range — if unknown, state "under assessment"]
Nature of harm:          [ Physical / Psychological / Financial / Discriminatory /
                           Reputational / No harm identified / Under assessment ]
Severity of harm:        🔴 Serious / 🟡 Moderate / 🟢 Minor / ⬜ Under assessment
Harm realised or potential: [ Realised / Potential / Both ]
Data involved:           [ Personal data / Special category data / No personal data /
                           Under assessment ]
Systems/services affected: [list any downstream systems or services impacted]
Geographic scope:        [country/region where affected individuals or systems are located]

SECTION 4 — CONTAINMENT ACTIONS TAKEN
────────────────────────────────────────
Immediate actions:
[ ] System suspended / taken offline
[ ] Affected outputs recalled or corrected
[ ] Affected individuals notified
[ ] Monitoring enhanced
[ ] Access restricted
[ ] Other: ___

Containment status:    [ Contained / Partially contained / Ongoing ]
Containment confirmed: [ to be confirmed — Engineering Lead ]

SECTION 5 — EU AI ACT ARTICLE 62 ASSESSMENT
──────────────────────────────────────────────
System risk tier:          [ High-risk (Annex III) / GPAI / Other / Unconfirmed ]
Serious incident threshold met: [ Yes / No / Under assessment ]
Threshold basis:           [ see references/article-62-thresholds.md ]
Regulatory notification required: [ Yes — due within 15 working days /
                                    No / Under assessment — Legal to confirm ]
Notification authority:    [ to be confirmed — Legal ]
Notification due date:     [ to be confirmed — Legal ]
DPO notified (if personal data): [ Yes / No / Not applicable ]
GDPR breach notification required: [ Yes / No / Under assessment — DPO to confirm ]

SECTION 6 — STAKEHOLDER ROUTING
──────────────────────────────────
[ ] Engineering Lead — root cause investigation
[ ] Legal / Compliance — Article 62 assessment and notification
[ ] DPO — data breach assessment (if personal data involved)
[ ] Communications — user/public notification (if required)
[ ] Executive sponsor — awareness (if serious incident)
[ ] National Market Surveillance Authority — regulatory notification (if required)

Incident commander:     [ to be confirmed — [appropriate senior role] ]
Next review:            [ to be confirmed — within [24h / 72h / 5 days] ]

SECTION 7 — NIST SP 800-61 PHASE TRACKING
─────────────────────────────────────────────
Current phase:  [ Preparation / Detection & Analysis / Containment, Eradication &
                  Recovery / Post-Incident Activity ]

Phase status:
  Preparation:                    [ Complete / In progress / Not started ]
  Detection & Analysis:           [ Complete / In progress / Not started ]
  Containment:                    [ Complete / In progress / Not started ]
  Eradication:                    [ Complete / In progress / Not started ]
  Recovery:                       [ Complete / In progress / Not started ]
  Post-Incident Review:           [ Scheduled for: ___ / Not yet scheduled ]

SECTION 8 — TIMELINE
──────────────────────
[Chronological list of known events — add rows as the incident develops]

[DATE TIME] — Incident occurs / first occurrence
[DATE TIME] — Incident detected
[DATE TIME] — Initial response initiated
[DATE TIME] — [next known event]

SECTION 9 — LESSONS LEARNED (Post-Incident)
─────────────────────────────────────────────
[Complete this section after the incident is resolved — see references/nist-800-61-phases.md
for post-incident activity guidance]

Root cause confirmed:        [ to be completed after investigation ]
Contributing factors:        [ to be completed after investigation ]
Controls that failed:        [ to be completed after investigation ]
Recommended improvements:    [ to be completed after investigation ]
Follow-up actions:           [ to be completed after investigation ]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

Step 4 — Routing Summary

After generating the report, produce a brief routing note:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 ROUTING SUMMARY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Severity:              [🔴 URGENT / 🟡 ELEVATED / 🟢 STANDARD]
Article 62 triggered:  [Yes / No / Under assessment]
Regulatory deadline:   [date or "N/A"]
GDPR breach notif.:    [Required / Not required / Under assessment]
Immediate actions needed:
  1. [Most urgent — owner — deadline]
  2. [Second — owner — deadline]
  3. [Third — owner — deadline]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

Step 5 — Offer Outputs and Next Steps

After presenting the report and routing summary, offer:

1. Save as Markdown — write the report to a .md file for the incident log
2. Export as Word document — hand off to the docx skill for a formatted .docx suitable for legal sign-off
3. Update the report — as new information emerges, update the report inline and re-save
4. Post-incident review template — when the incident is resolved, generate a completed Section 9 (lessons learned)
5. Compliance gate — trigger hitl-compliance-gate before submitting any regulatory notification
6. NIST phase guidance — if the team needs detailed guidance for the current response phase, pull from references/nist-800-61-phases.md

---

Key Principles

• Advisory only — All outputs produced by this skill are for informational and governance support purposes only. They do not constitute legal advice, regulatory advice, or a formal compliance determination. No output from this skill should be relied upon as a substitute for advice from qualified legal counsel, a licensed compliance professional, or a certified auditor with jurisdiction-specific expertise.
• Speed matters for Article 62 — the 15 working day clock starts from when the provider becomes aware of a serious incident. Start the report immediately; refine as facts emerge
• Pre-fill aggressively — a report with [ to be confirmed ] placeholders naming specific owners is far more useful than a blank template; it creates accountability without waiting for complete information
• Severity can escalate — mark incidents as STANDARD initially if facts are unclear, but explicitly flag that severity will be reassessed as the investigation progresses
• Separate fact from assessment — the description (what happened) and the impact assessment (how bad it is) should be clearly distinguished; early impact assessments are often wrong
• This is a living document — an incident report should be updated as the response progresses, not written once and filed; offer to update it as the conversation continues