When something goes wrong, here's what we do.
This is the public summary of YionStack's incident response procedure — the playbook our on-call follows when a security or personal-data incident is suspected. It is the operational counterpart to Clause 8 of our DPA.
Last updated: 10 June 2026
Severity bands
Severity drives the response — who's on the bridge, what we tell you, and how fast.
Active confirmed breach of customer data, total service outage, or active exploitation. All-hands; founder on the bridge.
Example: Authentication bypass exposing business data; ransomware on production
Likely breach, partial outage of a critical service, or vulnerability with confirmed exploit path. Engineering on-call leads.
Example: RLS misconfiguration on a non-default code path; partial Stripe webhook failure
Suspected issue with limited customer impact, or vulnerability without confirmed exploit. On-call investigates within working hours.
Example: Spike in 5xx errors on a single endpoint; leaked non-secret config value
The clock from declaration
The moment we declare an incident the timeline below starts running. Every step has an owner; every step is logged for the post-mortem.
- T+001. Detect
Automated alert, support report, or internal escalation. The on-call engineer opens the incident, declares severity, and creates a war room channel.
- T+15min02. Contain
First action is always containment — revoke compromised credentials, isolate affected services, freeze suspect businesses. Stop the bleed before forensics.
- T+1hr03. Triage
Confirm scope: what data, whose data, which businesses, what timespan. Document everything for the post-mortem and for any required regulator submission.
- T+24hr04. Notify customers
For any incident affecting customer data we notify the affected controllers. Notification includes nature, categories of data subjects affected, likely consequences, and our containment.
- T+72hr05. ICO submission window closes
Where the breach is likely to result in a risk to data subjects' rights, the controller (you) must notify the ICO within 72 hours of awareness. Our notification is the trigger of your clock.
- T+48hr post-resolve06. Public retrospective
For any incident we announced, we publish a retrospective on /status within 48 hours of resolution. What broke, how we found it, what we changed.
What our customer notification contains
When we notify you of a personal-data breach, the message contains the information required by Article 33(3) UK GDPR so you can pass it through to the ICO without having to dig:
- The nature of the breach
- The categories and approximate number of data subjects concerned
- The categories and approximate number of records concerned
- The likely consequences of the breach
- The measures we have taken or propose to take to address it
- Contact details of our data-protection point of contact
If we cannot provide all the information at the time of notification we provide it in phases as it becomes available — Article 33(4) explicitly allows phased notification.
Tell us immediately.
We'd rather investigate a false alarm than miss the real one. The same address is listed in your DPA and on /status.