Incident response process
What happens when something goes wrong: how we detect, triage, contain and recover from security incidents, and when and how we tell you.
Report a security concern
Email security@northstar-platform.eu.
We acknowledge reports within one business day and do not pursue researchers who report in good faith.
Process version 1.0 · Effective 14 September 2026 · Reviewed at least annually and after every S1 incident.
Severity
How incidents are classified
Severity drives response time and the customer notification window. It is set at triage and revised as facts emerge.
| Severity | Applies when | Triage target | Customer notification |
|---|---|---|---|
| S1 — Critical | Confirmed unauthorised access to customer data, or the platform is unavailable for all customers. | 15 min | Affected customers within 24 h of confirmation; interim updates at least every 24 h until resolved. |
| S2 — High | Suspected exposure of customer data, a vulnerability being actively exploited, or a major function unavailable. | 1 h | Affected customers within 72 h of confirmation. |
| S3 — Medium | Vulnerability with no evidence of exploitation; degraded performance; single-customer impact with no data exposure. | 1 business day | Affected customers in the next scheduled update, or on request. |
| S4 — Low | Informational findings, hardening opportunities, scanner noise confirmed as false positive. | 5 business days | Not notified; tracked in the internal register. |
Process
Detection to post-incident review
1. Detection
Signals come from infrastructure alerting (Vercel, Supabase), application error reporting, the platform audit trail, vulnerability disclosures to security@ and customer reports. Every signal is logged as a ticket within one hour of receipt with the time of detection recorded.
2. Triage
The on-call engineer assigns a provisional severity using the table above, identifies affected customers and data categories, and opens the incident channel. S1 and S2 incidents page the incident lead immediately; the platform Owner is informed of every S1.
3. Containment
Stop the harm first: revoke or rotate compromised credentials and keys, disable affected accounts or features, block offending traffic, or take the affected component offline. Containment actions are recorded with timestamps in the incident ticket before eradication begins.
4. Eradication and recovery
Remove the root cause (patch, configuration change, dependency upgrade), verify with a targeted test, then restore service. Where data integrity is in question, restore from a point-in-time backup and reconcile against the audit trail. Recovery is confirmed by the incident lead, not by the engineer who made the change.
5. Customer notification
Affected customers are notified by email to their Organization Admins within the window for the severity, with: what happened, which data categories and time window are affected, what we have done, what we recommend they do, and a contact for questions. We provide what a financial entity needs for its own DORA incident classification and reporting; we do not classify or report on the customer's behalf.
6. Post-incident review
Within 10 business days of closure a written review records the timeline, root cause, what worked, what did not, and corrective actions with owners and dates. S1 and S2 reviews are shared with affected customers on request.
Roles
Who does what
On-call engineer
Receives signals, performs triage, executes containment and records every action with a timestamp.
Incident lead
Owns the incident from S1/S2 declaration to closure, decides on customer notification, confirms recovery, runs the post-incident review.
Platform Owner
Informed of every S1; approves external communication; accountable for corrective actions being completed.
Back to the security overview.
Questions about our security practices?
See how one platform connects your ICT providers, assessments, evidence, contracts, risks and DORA Register.