magnus919_agent-skills/secure-software-engineering/references/incident-learning.md

Incident Learning

Make The Decision Now

After an incident, near miss, or escaped defect, decide what systemic condition allowed it and which engineering artifact must change: requirement, threat model, design constraint, test, review prompt, telemetry, dependency policy, release gate, or operational response.

Learn Without Replaying Harm

• Preserve minimum necessary facts, timelines, affected boundaries, decisions, and evidence access controls.
• Separate trigger, enabling conditions, detection gap, response effectiveness, and customer impact. Avoid assigning blame in place of identifying a controllable condition.
• Fix the class of defect across comparable paths, not only the observed instance.
• Convert learning into an owned change with acceptance criteria and a verification method. Update the threat model if an assumption failed.
• For AI incidents, include prompt sources, retrieval corpus, model and policy versions, tool authorization, approvals, output handling, and data exposure without retaining unnecessary sensitive content.

Evidence And Verification

Show the changed control in code, configuration, test, review process, or release evidence. Test the original failure mode and adjacent variants; record residual risk when reproduction is unsafe or access is unavailable. Use verification-methodology for verdicts rather than declaring learning complete from a meeting note.

Misuse To Avoid

• Calling a root cause a single human mistake and leaving the system condition unchanged.
• Collecting unrestricted incident data that creates a second exposure.
• Adding a permanent control without an owner, effectiveness check, or review date.