--- title: "Incident Records for SOC 2, ISO 27001, NIS2 and DORA" url: "https://www.openstatus.dev/use-case/incident-records" date: "2026-10-23" author: "openstatus" description: "The incident evidence auditors ask for, written while the incident runs: timestamped timeline, severity, commander, approved postmortem, frozen on close." category: "Compliance" --- ## "Walk me through your last incident" That is the fieldwork request. Not "do you have a status page", which the auditor has already checked, but a sampled incident from the observation period and five questions about it: when did you know, how bad did you decide it was, who was in charge, what did you do and when, and what changed afterwards. Most teams answer from memory, a Slack thread search and a ticket with a title and a close date. The record is reconstructed weeks later, and the auditor can tell. > **This is the response half of compliance** > > This page is about the internal incident record: declaration, severity, commander, timeline, postmortem. The public half, telling customers through a status page (SOC 2 CC2.3, NIS2 Article 23(1), DORA Article 19(3)), is on [status pages for compliance](/use-case/compliance). The requirements themselves are in the [compliance guides](/guides/category/compliance). ## What the record holds An incident in openstatus is declared by a person, from Slack, the dashboard, the API or an agent. From that moment the record writes itself: - **Two timestamps, not one.** When the impact started, pre-filled from the monitor when you declare it from the downtime row, and when someone declared it. The gap is visible. - **A severity decision.** Critical, major or minor, chosen at declaration and changeable later, with every change on the timeline. Canceling an incident records that you looked and decided it was not one. - **A commander.** One named member in charge, changeable until close, with the handover on the timeline. - **An append-only timeline.** Status changes with notes, pinned Slack messages with a link back, status report links, postmortem drafted and approved, closed. Each entry carries the time and the member behind it. - **An approved postmortem.** Summary, impact, timeline, root cause, what went well, what went wrong, action items. Drafted by the agent, corrected by you, approved by an owner, admin or the commander. - **A frozen close.** Approve the postmortem and close the incident. After that, status, severity, commander and notes cannot change. The incident record for "Checkout API 503s in EU" at the fictional Pied Piper: severity Major, status Resolved, commander Gilfoyle, duration 55m, and a timeline from Declared at 09:43 through a note pinned from Slack, the linked status report, Mitigated at 10:14 and Resolved at 10:36 to the approved postmortem at 11:20. ## Which control each field answers **SOC 2** CC7.3 asks you to evaluate events and decide whether they are incidents: the declaration and the severity, both timestamped. CC7.4 asks you to respond by executing a defined program: the commander, the status changes and the notes. CC7.5 asks you to restore and communicate resolution: the resolved timestamp, the linked status report and the postmortem action items. [SOC 2 guide](/guides/soc-2-status-page-requirements) **ISO 27001** A.5.25, assessment and decision, is the severity and the declared time. A.5.26, response, is the timeline. A.5.27, learning from incidents, is the approved postmortem with owners on the action items. A.5.28, collection of evidence, is the append-only timeline, the frozen record and the audit log. [ISO 27001 guide](/guides/iso-27001-incident-communication) **NIS2** The Article 23(4) cascade runs from when you became aware: an early warning within 24 hours, a notification within 72 hours, and a final report within one month of that notification. The record holds the impact-start and declaration timestamps, the severity and impact assessment, the mitigation steps as they happened and the root cause for the final report. The moment you became aware is a decision your process records. The filing itself goes through your CSIRT. [NIS2 guide](/guides/nis2-incident-reporting-requirements) **DORA** The 4-hour clock starts at classification, and the 24-hour outer limit at awareness. The record supplies duration and service downtime, one of the classification criteria, from the monitor incident it was declared from. Your process records the awareness and classification decisions and their timestamps. The intermediate and final reports draw on the postmortem. Classification is your call. [DORA guide](/guides/dora-incident-reporting-requirements) ## Where it stops Openstatus is the record, not the procedure. It does not write your incident response policy, decide your severity thresholds, classify a DORA major incident, file a NIS2 notification or replace a GRC platform. It makes the evidence those things need exist without anyone reconstructing it afterwards. ## Run one incident this way 1. Declare it from the monitor's downtime row, so the impact start is already filled in. Or declare it from Slack with a title and a severity. 2. Name a commander. 3. Work it where the team already is. If that is the incident's Slack channel, pin the decisions and the rollback messages so they land on the timeline with their author. Otherwise add them as notes. 4. Link the status report your customers read, and keep its wording separate. 5. Mark it mitigated, then resolved, with a note each time. 6. Write the postmortem, or let the agent draft it on Starter and above. Correct it, assign the action items, approve it, and close the incident. The record freezes. The next time an auditor says "walk me through your last incident", open the record. > **Retention has to cover the observation period** > > A SOC 2 Type II window runs 3 to 12 months. ISO 27001 does not prescribe a fixed evidence-retention period; your retention policy does. The incident record and its postmortem stay with the workspace. The monitoring data the record was declared from is kept 14 days on Hobby, 3 months on Starter, 12 months on Pro and 24 months on Scale, so pick a plan whose retention spans that policy and the window you will be asked about. ## Frequently asked questions
What evidence does a SOC 2 auditor ask for on incident response? For CC7.3 to CC7.5 the auditor samples incidents from the observation period and asks to see, for each one, when it was detected and declared, how severe you judged it, who responded, what was done and when, when service was restored, and what follow-up was agreed. A ticket with a title and a close date does not answer that. An incident record with a timestamped timeline, a severity, a commander and an approved postmortem does.
Does openstatus satisfy SOC 2 CC7.4? It evidences it. CC7.4 asks you to respond to incidents by executing a defined program. The program is your document. The incident record shows the program was followed: declared with a severity, a commander assigned, status moved from open to mitigated to resolved with notes, a postmortem approved. Your auditor tests the record against your procedure. Openstatus provides the record, not the procedure.
How do I prove when we detected an incident versus when we declared it? Started at and declared at are two separate timestamps on the record. Declaring from the monitor's downtime row fills in the impact start automatically, and you can set it in the past by hand. The gap between them is visible, and that honesty is what an auditor wants to see rather than a record where both happen to match.
Can an incident record be edited after the fact? Timeline entries and notes are append-only. You can add a note that corrects an earlier one, but you cannot rewrite or delete history. Once the postmortem is approved and the incident is closed, the record is frozen: status, severity, commander and notes can no longer change. On Pro and Scale, every change before that point is also in the workspace audit log with the person or agent behind it.
Is a postmortem drafted by an AI agent acceptable audit evidence? The draft is a starting point built from the timeline, the public updates and the Slack channel history, and it says where it has no facts rather than inventing them. What the auditor evaluates is the approved document: its content, who approved it, and whether the action items were followed up. The approver is recorded. Read the draft, correct it, then approve it.
Does openstatus file NIS2 or DORA reports for us? No. The 24h/72h/one-month NIS2 cascade and the 4h/24h/72h DORA clock go through your national CSIRT or competent authority on prescribed templates. Openstatus holds the source material those reports draw on: when impact started, when the incident was declared, how long the service was down and from where, what you did, and the root cause. The awareness and classification decisions, and their timestamps, are yours to record.
Which plan do I need? Incident records, the timeline and the postmortem are part of every workspace. The Slack channel per incident needs the Slack agent, which is on paid plans. The workspace audit log, which records every change with its actor, is on Pro and Scale. Check that your retention covers your audit period before you choose.
Can I reference the record in Vanta, Drata or a GRC tool? Yes. Each incident, with its postmortem, has a stable URL in the dashboard and is readable over the API. Link it as the evidence for the control, or pull it into the evidence request through the API. Openstatus does not replace the GRC platform, it feeds it.
--- Ready for the next "walk me through it"? [Declare your first incident](https://app.openstatus.dev) ---