Incident response
How fremverk handles customer-visible incidents and what we publish afterwards. The two pages in this section are the customer-facing pieces: the comms template we follow during an incident and the post-mortem template we publish within 14 days of resolution.
Operator-side procedures (the actual step-by-step the on-call follows for DR drills, RDS PITR restores, secret rotations, regional outages, etc.) live inside the operator console and are not published here. The fremforge SLA and DPA are the contractual layer; the operator procedures are how we deliver against them.
What we commit to
| Commitment | Mechanism | Source contract |
|---|---|---|
| 30-minute SEV-1 acknowledgement | On-call rota with SMS paging + 15-minute escalation | SLA §11.2 |
| Status updates every 30 min during SEV-1 | Incident comms template | SLA §11.4 |
| Post-mortem published within 14 days | Post-mortem template | SLA §11.6 |
| Annual disaster-recovery drill with published log | Operator-internal procedure; log summary on the trust page | DPA §7.4 |
| Region outage failover within RTO | Operator-internal procedure | SLA §11.3 |
Pages
- Incident comms template, the verbatim text we post during an incident.
- Post-mortem template, the shape every public post-mortem follows.
Why we don’t publish the full operator runbooks
The detailed operator procedures (on-call rota structure, RDS point-in-time-restore steps, the data-corruption-recovery procedure, regional outage failover, secret rotation, etc.) are kept internal for two reasons: they describe our infra topology at a level that doesn’t help customers and would help an attacker, and they change on an operational cadence that doesn’t match a documentation-publishing cadence.
If you need to verify a specific operational commitment for your procurement or security review, open a support ticket and we’ll walk through the relevant procedure under NDA.