Skip to content

Information Security Incident Response Procedure

Purpose. Defines how Soon prepares for, detects, assesses, responds to and learns from information security incidents (ISO/IEC 27001:2022 A.5.24–A.5.28, A.6.8). Addresses risk R-16 (no formal incident response).

1. Scope & definitions

Applies to all Soon personnel, contractors and systems in ISMS scope.

  • Security event — an observed occurrence that may be relevant to security (an alert, a lost laptop, a suspicious email).
  • Security incident — an event (or series) that has compromised, or is likely to compromise, the confidentiality, integrity or availability of information or systems.
  • Personal-data breach — an incident affecting personal data; triggers the Personal Data Breach Notification Procedure (ISMS-DOC-A05-34-2) and GDPR obligations.

2. Roles (per Roles & Responsibilities)

Role In an incident
Incident Coordinator — ISM (Olaf) Owns the incident; declares severity; coordinates response & communications; authority to declare an incident
Technical Lead (Thomas) Leads containment, eradication, recovery; preserves technical evidence
Privacy Owner (Olaf) Determines if personal data is affected; runs breach notification
All staff Report events immediately via the Event Reporting Procedure (A.6.8)
External consultant (Andrea) Advisory / specialist support if needed

3. Severity classification

Severity Definition Examples Target response
P1 – Critical Major breach or outage; customer data exposed; platform down Confirmed data breach, ransomware, full outage Immediate; all-hands
P2 – High Significant risk; limited data exposure or partial outage Compromised account, key service degraded < 4 working hours
P3 – Medium Contained issue, limited impact Malware on one endpoint, minor misconfig < 1 working day
P4 – Low Minor, no material impact Spam, single failed-login anomaly Best effort

4. Response workflow

  1. Report — anyone detecting an event reports it immediately (A.6.8), via two channels used together:
  2. Slack, for speed. Post in the channel matching the issue — #Security, #DevOps, #Development, or #General if unsure — and @-mention the channel or the specific people who need to know now. This gets the right people aware fast.
  3. Email (security@soon.works), for the record. This is the paper trail — what was reported, when, and by whom — used as evidence if the event becomes a formal incident. Confirmed 2026-07-03 (Q1 follow-up).
  4. Assess & triage (A.5.25) — the ISM confirms whether it's an incident, assigns severity and an owner, and starts an incident record (§6).
  5. Contain — limit the impact (isolate hosts, revoke credentials/sessions, block access). Technical Lead leads; preserve evidence before destructive actions (A.5.28).
  6. Eradicate — remove the cause (malware, vulnerability, misconfig, compromised key).
  7. Recover — restore service from known-good state/backups; verify integrity; monitor.
  8. Notify — if personal data is affected, trigger breach notification (§5). Inform affected customers per contractual/SLA commitments.
  9. Close — confirm resolution; ISM closes the incident record.
  10. Learn (A.5.27) — for P1/P2 (and others as useful), hold a post-incident review within 10 working days; capture root cause and actions in a Lessons Learned record (ISMS-FORM-A05-27-1); feed actions into the Nonconformity & Corrective Action process and update the risk assessment.

5. Personal-data breaches & external notification

If personal data is or may be affected, the Privacy Owner runs the Personal Data Breach Notification Procedure. As a data processor, Soon notifies the affected customer (controller) without undue delay; the controller is responsible for notifying the supervisory authority (GDPR Art. 33, generally within 72 hours) and data subjects (Art. 34).

6. Incident record & evidence (A.5.28)

Every incident is recorded with: ID, date/time detected & reported, reporter, severity, systems/data affected, timeline of actions, containment/eradication/recovery steps, personal data involved (Y/N), notifications made, root cause, corrective actions, closure. Evidence (logs, images, emails) is preserved in a controlled, access-limited location — not in this policy repo. Incident records are held in Linear (one issue per incident, security-labelled), with the initial report in Slack #Security and email to security@soon.works as the paper trail.

7. Scenario playbooks

One page each for the most likely P1 scenarios — detection signals, the first 30–60 minutes, key contacts, and what to do next. Written to be read during an incident, not before one.

Playbook Owner The thing people get wrong
Ransomware Olaf Treating it as a laptop problem rather than a credential compromise
Denial of Service Thomas Mitigating external traffic when the cause was our own deploy
Data Breach Olaf Waiting for a complete picture before starting the notification clock

Change log

Version Date Author Comments
0.1 2026-06-25 Andrea Cardinali / ISMS First draft — severity model, response workflow, roles, breach linkage. Reporting channel, record location and scenario playbooks flagged TODO.