Status: REGISTER v1, 2026-10-17 — the assessment decisions are PROPOSED and need the SIRO's sign-off. This is the record
that satisfies DSPT 6.1.1 (a system to report incidents, with a log), 6.1.3 (after a breach, risk to affected
individuals considered and people informed where risk was high) and 5.1.1 (the process behind each breach or near miss
reviewed).
It is deliberately separate from the incident procedure. The procedure says what to do — it is
Responding to Incidents, which already contains a worked
example of the 14 May incident. This page is the register: one row per event, with the two judgements DSPT asks for —
were personal data involved, and was the risk to individuals high enough to notify.
DSPT 5.1.1 asks whether the process behind any breach or near miss was reviewed — not whether the organisation was
live. Every event below happened on our own estate, was detected, was handled, and changed something. Two of them are
genuinely useful evidence precisely because they are real: an availability failure that reached a client tenant, and a
confidentiality near miss where a client login landed on a staff dashboard. Recording them, and recording honestly that
no patient data was involved, is stronger evidence than an empty log.
| Ref | Date | What happened | Personal data involved? | Risk to individuals | Notification decision | What changed | Record |
|---|---|---|---|---|---|---|---|
| INC-01 | 2026-05-14 | Wiki.js database loss, with Keycloak client deletion, nginx downtime and a broken DefectDojo pipeline | No — the internal documentation platform; no patient data held there | None identified | Not reportable — no personal data | Corrective actions tracked to closure in the report | report |
| INC-02 | 2026-08-01 | A client tenant's database was unavailable and its tunnel unhealthy (client-facing outage) | No unauthorised access — availability only | None from confidentiality; service interruption | Not reportable | Restore procedure exercised; tunnel monitoring hardened | report |
| INC-03 | 2026-08-01 | Confidentiality near miss: a client login landed on the VeriPath staff dashboard instead of the client's own | To confirm — the staff dashboard carries infrastructure views; no patient records are rendered there | Low, on that basis — pending confirmation | Not reportable, pending SIRO confirmation | Role→dashboard routing consolidated from six files to one; the underlying fleet-view exposure was separately fixed in October (client admins no longer see other clients' client-vps instances) | report |
| INC-04 | 2026-08-11 | Kinsing-family crypto-miner found running inside the Forgejo (git) container on the primary server; attacker toolkit, modified binaries | No patient data — a source-code host. The git data volume was verified unmodified | Assessed low; credentials rotated | Not reportable, pending SIRO confirmation | Contained, forensics captured | report |
| INC-05 | 2026-08-14 | Same intrusion, root cause: a git-apply path-traversal RCE; 253 attacker accounts and 239 malware repositories created; entry vector unclosed on 11 August | No patient data (as INC-04) | Low after remediation; the interval 11–14 August is the exposure window | Not reportable, pending SIRO confirmation | RCE patched, attacker footprint purged, credentials rotated, registration disabled, hosting provider notified | root cause · provider report |
Proposed by: Hermes (technical review), 2026-10-17. Decisions to be signed off by: the SIRO / senior responsible
person — not yet named anywhere in the estate, which is the Standard 1 gap this register exposes.
Every future entry uses these columns, and the procedure points here. The template below is carried over from the draft
6. Data Security Incident Response Policy, which is being superseded by this register plus the procedure:
| Field | What goes in it |
|---|---|
| Ref | INC-YYYY-NN |
| Date and time detected | when it was noticed, not when it started |
| What happened | one or two sentences, in plain English |
| Personal data involved? | yes/no, with the basis — "patient records are not held on that host", not just "no" |
| Categories and numbers affected | if the answer above is yes |
| Risk to individuals | low / medium / high, with the reasoning |
| Notification decision | ICO and data subjects: notifiable yes/no, who decided, when |
| What changed | the corrective action, with a date |
| Record | link to the full report |