Skip to content

Incident history

🔒 INTERNAL ONLY. Past incidents and post-mortems contain operational detail that must never be shared without explicit redaction. Customer-facing communications are tracked separately in the comms vault.

This document records security incidents on the Evospin platform. An incident is any event that resulted in (or could plausibly have resulted in) unauthorized access, data exposure, financial loss, or material service disruption. The bar is intentionally low — false positives and dry-runs are also recorded so that the team accumulates pattern-recognition over time.

Process. When an incident is declared, the on-call engineer creates a row in the table below within 24 h, then fills in detail post-resolution. Post-mortems live in their own files (linked from the row) following the template at the bottom of this document.

SLA on entries. - Initial row: within 24 h of declaration. - Full detail: within 5 business days of resolution. - Post-mortem doc: within 10 business days of resolution. - Action items: tracked in this register until status reaches Done.

Incident log

Incident ID Date Severity Detection Root cause Resolution Status Post-mortem
(empty — no recorded incidents to date)

First entry to be added when a security incident occurs. Use the template below.

Action-item register

Open action items from past incidents. Each links back to an incident ID; closing a row requires explicit sign-off from the action-item owner.

AI ID From incident Description Owner Due Status
(empty)

Template — new incident entry

Copy the following block as the first row of "Incident log" and fill in:

| INC-YYYY-NN | YYYY-MM-DD | Critical/High/Medium/Low | <how detected> | <one-line root cause> | <one-line resolution> | Open / Mitigated / Closed | docs/security/internal/post-mortems/INC-YYYY-NN.md |

Detection-method values

  • automated-alert — fired by Prometheus / Sentry / Loki rule
  • manual-dashboard — operator noticed in Grafana / admin UI
  • customer-report — inbound from support
  • external-report — bug bounty / partner / researcher
  • audit — scheduled audit or red-team engagement
  • accidental — discovered by engineering during unrelated work

Severity values (initial assessment)

Same scale as the findings register: Critical / High / Medium / Low. May be re-classified during post-mortem; if so, record both the at-time-of-report severity and the post-mortem severity in the post-mortem doc.

Template — post-mortem doc

Create one file per incident at docs/security/internal/post-mortems/INC-YYYY-NN.md:

# INC-YYYY-NN — <one-line title>

> 🔒 INTERNAL ONLY.

## Summary

- **Date / time (UTC).**
- **Duration.**
- **Severity at report.** Critical / High / Medium / Low
- **Severity post-review.** Critical / High / Medium / Low
- **Detection method.** <see values above>
- **First-detector.** <name / system>
- **Incident commander.**
- **Communications lead.**

## Timeline

- `HH:MM` — <event>
- `HH:MM` — <event>
- ...

## Root cause

Technical explanation: what happened, how it propagated, why existing controls failed.

## Impact

- Users affected:
- Records exposed / modified:
- Financial impact:
- Service availability impact:
- Regulatory impact:

## Detection

What told us about it. Time from start-of-incident to detection. What would have detected it sooner.

## Resolution

What we did to stop it, in chronological order.

## What went well

- <bullet>

## What went badly

- <bullet>

## Action items

| AI ID | Description | Owner | Due |
|-------|-------------|-------|-----|
| AI-1  |             |       |     |

## Lessons learned

Free-form. What does this incident tell us about our threat model, our controls, our culture?

## Customer comms

- Notification timing:
- Channel:
- Message text (link to comms vault):
- Regulator notification (if applicable):

Cross-references

  • Customer-share IR runbook: docs/security/security-incident-policy.md — what we tell the world about how we handle incidents.
  • Findings register: docs/security/internal/findings.md — proactive risk; incidents are reactive.
  • Threat model: docs/security/internal/threat-model.md — the categories incidents tend to fall under.
  • Comms vault: {{TBD: link to canonical customer-notification log}}.
  • Regulatory contacts: {{TBD: per jurisdiction}}.