From 18f6246ebfa1a715117e5501cf9cc2287fa75e92 Mon Sep 17 00:00:00 2001 From: Maximilian Kaske <56969857+mxkaske@users.noreply.github.com> Date: Fri, 23 Oct 2026 11:46:16 +0200 Subject: [PATCH] feat(web): incident records use case for audits (#2977) * feat(web): incident records use case for audits The compliance use case covers the public half, telling customers through the status page (CC2.3). Nothing covered the half an auditor actually samples: the internal incident record. Add a use case that maps the record's fields (two timestamps, severity, commander, append-only timeline, approved postmortem, frozen close) to SOC 2 CC7.3-7.5, ISO 27001 A.5.25-5.28, the NIS2 cascade and the DORA clock, and is explicit about where the product stops. - new /use-case/incident-records with the incident timeline demo and question-shaped FAQs - product page audit-trail links and the compliance use case's CC7 line point at the new page instead of the status-page one - enterprise sales FAQ answers the "incident response process" questionnaire question with the record - compliance guides and the incident management hub link across - product page FAQ: the agent drafts the postmortem from the dashboard too; Slack only adds the channel history to the draft - use-case listing: brand casing, mention incident records * fix(web): qualify audit claims in incident records content Scope CC7 to supported parts, gate agent drafting by plan, drop the awareness/classification timestamp claims the record does not hold, and tie ISO retention to policy rather than the cert cycle. * fix(web): link incident records use case from compliance FAQ --- apps/web/src/app/(landing)/use-case/page.tsx | 2 +- .../dora-incident-reporting-requirements.mdx | 1 + .../iso-27001-incident-communication.mdx | 1 + .../nis2-incident-reporting-requirements.mdx | 1 + .../guides/soc-2-status-page-requirements.mdx | 1 + .../guides/what-is-incident-management.mdx | 2 +- .../pages/product/incident-management.mdx | 8 +- .../src/content/pages/use-case/compliance.mdx | 6 +- .../pages/use-case/enterprise-sales.mdx | 4 +- .../pages/use-case/incident-records.mdx | 175 ++++++++++++++++++ 10 files changed, 190 insertions(+), 11 deletions(-) create mode 100644 apps/web/src/content/pages/use-case/incident-records.mdx diff --git a/apps/web/src/app/(landing)/use-case/page.tsx b/apps/web/src/app/(landing)/use-case/page.tsx index d1e5b3bac..d411c84f1 100644 --- a/apps/web/src/app/(landing)/use-case/page.tsx +++ b/apps/web/src/app/(landing)/use-case/page.tsx @@ -18,7 +18,7 @@ import { ContentList } from "../content-list"; const TITLE = "Use Cases"; const DESCRIPTION = - "Discover how teams use OpenStatus for compliance, reducing support tickets, closing enterprise deals, open-source projects, crypto exchanges, and API infrastructure."; + "Discover how teams use openstatus for compliance, incident records for audits, reducing support tickets, closing enterprise deals, open-source projects, crypto exchanges, and API infrastructure."; export const metadata: Metadata = { ...defaultMetadata, diff --git a/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx b/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx index 2a6e7b755..9f3157f5d 100644 --- a/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx +++ b/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx @@ -138,6 +138,7 @@ Financial services regulation carries supervisory consequences that a guide cann - [SOC 2 and your status page](/guides/soc-2-status-page-requirements) — what customers ask for alongside the regulator - [Incident severity matrix](/guides/incident-severity-matrix) — a starting point for the classification procedure - [What is MTTR](/guides/what-is-mttr) — duration and downtime feed the classification criteria +- [Incident records for audits](/use-case/incident-records) — the classification timestamp and the record behind each report - [Status pages for crypto exchanges and DeFi protocols](/use-case/crypto) — if you are a CASP or token issuer ## Frequently asked questions diff --git a/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx b/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx index bab224947..d839a3c7b 100644 --- a/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx +++ b/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx @@ -109,6 +109,7 @@ If you are writing the incident procedure that A.5.26 tests, 27035-1 is the more - [SOC 2 and your status page](/guides/soc-2-status-page-requirements) — the other framework most teams carry alongside - [What is incident management](/guides/what-is-incident-management) — the process behind A.5.24 to A.5.27 - [Incident severity matrix](/guides/incident-severity-matrix) — gives A.5.25 a testable threshold +- [Incident records for audits](/use-case/incident-records) — the record behind A.5.25 to A.5.28 - [What is MTTR](/guides/what-is-mttr) — recovery measurement for A.5.30 - [What is synthetic monitoring](/guides/what-is-synthetic-monitoring) — one input to A.8.16 diff --git a/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx b/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx index cd0bb162a..d6f2b2031 100644 --- a/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx +++ b/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx @@ -124,6 +124,7 @@ Your obligations live in your member state's transposition, which may differ on - [Incident severity matrix](/guides/incident-severity-matrix) — for defining "significant" in advance - [Security incident response template](/guides/security-incident-response) — wording for recipient notification - [What is incident management](/guides/what-is-incident-management) — the process underneath Article 21 +- [Incident records for audits](/use-case/incident-records) — the source material for the 24h/72h/one-month reports ## Frequently asked questions diff --git a/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx b/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx index 3da64c9d8..850603104 100644 --- a/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx +++ b/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx @@ -159,6 +159,7 @@ Read the criteria before taking any vendor's mapping — including this one — - [SLA vs SLO vs SLI](/guides/sla-vs-slo-vs-sli) — needed if you carry the Availability category - [Incident severity matrix](/guides/incident-severity-matrix) — the documented threshold that decides what gets communicated - [What is incident management](/guides/what-is-incident-management) — the process CC7.4 tests +- [Incident records for audits](/use-case/incident-records) — the record CC7.3 to CC7.5 sample - [Security incident response template](/guides/security-incident-response) — wording for the communication itself - [ISO 27001 incident communication](/guides/iso-27001-incident-communication) — if you are pursuing both diff --git a/apps/web/src/content/pages/guides/what-is-incident-management.mdx b/apps/web/src/content/pages/guides/what-is-incident-management.mdx index e9901568e..54b1e17bf 100644 --- a/apps/web/src/content/pages/guides/what-is-incident-management.mdx +++ b/apps/web/src/content/pages/guides/what-is-incident-management.mdx @@ -175,7 +175,7 @@ The process above does not need a dedicated tool. It needs four things to exist - **A timeline that writes itself.** Every status change, note and public update timestamped as it happens, so the postmortem is built from the record and not from memory. ([Internal status, public update](/incident-management#internal-status-public-update)) - **A postmortem that starts drafted.** From the timeline and the channel, with the unknowns marked as unknown, so the team edits instead of reconstructs. ([A postmortem with a first draft](/incident-management#a-postmortem-with-a-first-draft)) -That is what [incident management in openstatus](/incident-management) is: those four things next to the monitors and the status page they belong to. +That is what [incident management in openstatus](/incident-management) is: those four things next to the monitors and the status page they belong to. The same record is what an auditor samples: see [incident records for audits](/use-case/incident-records). ## The Bottom Line diff --git a/apps/web/src/content/pages/product/incident-management.mdx b/apps/web/src/content/pages/product/incident-management.mdx index 3a44b504a..eb76212a1 100644 --- a/apps/web/src/content/pages/product/incident-management.mdx +++ b/apps/web/src/content/pages/product/incident-management.mdx @@ -15,7 +15,7 @@ faq: - question: "What is the difference between an incident and a status report?" answer: "An incident is internal: severity, commander, timeline notes and the postmortem are for your team. A status report is public: it is what customers read on your status page and receive as a subscriber. You link the two, and each keeps its own status, so the team can mark an incident mitigated while the status report still says monitoring." - question: "Do I need Slack to manage incidents?" - answer: "No. You can declare, update, resolve and write the postmortem from the dashboard. Connecting Slack adds the channel per incident, slash commands, pinning messages to the timeline, stale-incident reminders and agent drafting." + answer: "No. You can declare, update, resolve and write the postmortem from the dashboard. On Starter and above the agent drafts the postmortem for you. Connecting Slack adds the channel per incident, slash commands, pinning messages to the timeline and stale-incident reminders, and the channel history becomes part of the postmortem draft." - question: "How does the postmortem draft work?" answer: "Once an incident is resolved, the agent drafts a blameless postmortem from the incident's fields, its timeline, the public status report updates and the history of the incident's Slack channel. The draft has seven sections: summary, impact, timeline, root cause, what went well, what went wrong and action items. Where it has no facts it says what is unknown. You edit the draft, approve it and close the incident." - question: "Which severities and statuses are there?" @@ -66,7 +66,7 @@ The team works with severities, notes and a commander. Customers read a [status **The record writes itself** -Every status change, note and public update is timestamped as it happens. The postmortem and the [audit trail](/use-case/compliance) are built from it, not from memory. +Every status change, note and public update is timestamped as it happens. The postmortem and the [audit trail](/use-case/incident-records) are built from it, not from memory. @@ -182,7 +182,7 @@ Once the incident is resolved, the agent drafts a blameless postmortem from the Edit it in markdown, approve it, and close the incident. - [Slack agent](/docs/guides/how-to-setup-slack-agent) -- [Status pages for compliance](/use-case/compliance) +- [Incident records for audits](/use-case/incident-records)
@@ -248,7 +248,7 @@ An incident is internal: severity, commander, timeline notes and the postmortem
-No. You can declare, update, resolve and write the postmortem from the dashboard. Connecting Slack adds the channel per incident, slash commands, pinning messages to the timeline, stale-incident reminders and agent drafting. +No. You can declare, update, resolve and write the postmortem from the dashboard. On Starter and above the agent drafts the postmortem for you. Connecting Slack adds the channel per incident, slash commands, pinning messages to the timeline and stale-incident reminders, and the channel history becomes part of the postmortem draft.
diff --git a/apps/web/src/content/pages/use-case/compliance.mdx b/apps/web/src/content/pages/use-case/compliance.mdx index 75ea08eb8..2b1c0fda3 100644 --- a/apps/web/src/content/pages/use-case/compliance.mdx +++ b/apps/web/src/content/pages/use-case/compliance.mdx @@ -14,7 +14,7 @@ faq: - question: "Can I use openstatus alongside Vanta or Drata?" answer: "Yes. openstatus handles the incident communication side of compliance while Vanta or Drata manage the broader audit automation. Your status page URL and incident history can be referenced in your compliance platform as evidence of your communication controls." - question: "How quickly can I be compliant?" - answer: "You can have a branded status page with custom domain, incident history, and subscriber notifications live in under 10 minutes. That covers the incident communication side — CC2.3 and parts of CC7 — not your whole SOC 2 scope. Check that your plan's data retention spans your audit period: a Type II observation window runs 3 to 12 months." + answer: "You can have a branded status page with custom domain, incident history, and subscriber notifications live in under 10 minutes. That covers the incident communication side, CC2.3, not your whole SOC 2 scope. The incident record supports parts of the CC7 incident response series: your triage decisions and the response and recovery program stay yours. See our incident records use case. Check that your plan's data retention spans your audit period: a Type II observation window runs 3 to 12 months." --- ## Why SOC 2 auditors care about incident communication @@ -22,7 +22,7 @@ faq: SOC 2's CC2.3 criteria (Communication with external parties) requires you to demonstrate incident communication processes — a mechanism for external users to report failures, open communication channels, and documentation of how incidents are communicated. Your auditor will ask: _"How do you notify stakeholders when something goes wrong?"_ SOC 2 doesn't prescribe a specific tool — you could use email, a support portal, or other channels. But a status page is the **fastest, most auditor-friendly** answer. It provides **timestamped, documented evidence** that you proactively inform users about outages, maintenance, and degraded performance. @@ -147,7 +147,7 @@ Yes. openstatus handles the incident communication side of compliance while Vant
-You can have a branded status page with custom domain, incident history, and subscriber notifications live in under 10 minutes. That covers the incident communication side — CC2.3 and parts of CC7 — not your whole SOC 2 scope. Check that your plan's data retention spans your audit period: a Type II observation window runs 3 to 12 months. +You can have a branded status page with custom domain, incident history, and subscriber notifications live in under 10 minutes. That covers the incident communication side, CC2.3, not your whole SOC 2 scope. The incident record supports parts of the CC7 incident response series: your triage decisions and the response and recovery program stay yours. See [incident records for audits](/use-case/incident-records). Check that your plan's data retention spans your audit period: a Type II observation window runs 3 to 12 months.
diff --git a/apps/web/src/content/pages/use-case/enterprise-sales.mdx b/apps/web/src/content/pages/use-case/enterprise-sales.mdx index b3c275ca7..292a8b842 100644 --- a/apps/web/src/content/pages/use-case/enterprise-sales.mdx +++ b/apps/web/src/content/pages/use-case/enterprise-sales.mdx @@ -8,7 +8,7 @@ faq: - question: "Do enterprise customers require a status page?" answer: "Increasingly, yes. Enterprise security and procurement teams evaluate vendor reliability as part of their due diligence. A public status page with uptime history, incident reports, and subscriber notifications demonstrates operational maturity. Many vendor questionnaires explicitly ask for a status page URL." - question: "What do security questionnaires ask about incident communication?" - answer: "Common questions include: How do you communicate incidents to customers? Do you have a public status page? How are customers notified of outages? What is your incident response process? A status page with subscriber notifications and timestamped incident history answers all of these." + answer: "Common questions include: How do you communicate incidents to customers? Do you have a public status page? How are customers notified of outages? What is your incident response process? A status page with subscriber notifications and timestamped incident history answers the communication questions. For the incident response process, point to your incident records: declared with a severity, a commander, a timestamped timeline and an approved postmortem." - question: "Can I create a private status page for enterprise clients?" answer: "Yes. Use password protection to create private status pages for specific enterprise customers. Show them only the components and services relevant to their account. This gives them dedicated visibility without exposing your full infrastructure." - question: "Can I host my status page on a custom domain?" @@ -64,7 +64,7 @@ Increasingly, yes. Enterprise security and procurement teams evaluate vendor rel
-Common questions include: How do you communicate incidents to customers? Do you have a public status page? How are customers notified of outages? What is your incident response process? A status page with subscriber notifications and timestamped incident history answers all of these. +Common questions include: How do you communicate incidents to customers? Do you have a public status page? How are customers notified of outages? What is your incident response process? A status page with subscriber notifications and timestamped incident history answers the communication questions. For the incident response process, point to your [incident records](/use-case/incident-records): declared with a severity, a commander, a timestamped timeline and an approved postmortem.
diff --git a/apps/web/src/content/pages/use-case/incident-records.mdx b/apps/web/src/content/pages/use-case/incident-records.mdx new file mode 100644 index 000000000..b26456838 --- /dev/null +++ b/apps/web/src/content/pages/use-case/incident-records.mdx @@ -0,0 +1,175 @@ +--- +title: "Incident Records for SOC 2, ISO 27001, NIS2 and DORA" +hero: "Audit evidence for every incident, written while it happens" +publishedAt: "2026-10-23" +author: "openstatus" +description: "Auditors and regulators ask who declared the incident, when, who was in charge, what was decided and what changed afterwards. Openstatus writes that record as the incident runs: timestamped timeline, severity, commander, postmortem, frozen on close." +category: "Compliance" +seo: + title: "Incident Records for SOC 2, ISO 27001, NIS2 and DORA" + description: "The incident evidence auditors ask for, written while the incident runs: timestamped timeline, severity, commander, approved postmortem, frozen on close." +faq: + - question: "What evidence does a SOC 2 auditor ask for on incident response?" + answer: "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." + - question: "Does openstatus satisfy SOC 2 CC7.4?" + answer: "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." + - question: "How do I prove when we detected an incident versus when we declared it?" + answer: "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." + - question: "Can an incident record be edited after the fact?" + answer: "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." + - question: "Is a postmortem drafted by an AI agent acceptable audit evidence?" + answer: "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." + - question: "Does openstatus file NIS2 or DORA reports for us?" + answer: "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." + - question: "Which plan do I need?" + answer: "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." + - question: "Can I reference the record in Vanta, Drata or a GRC tool?" + answer: "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." +--- + +## "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. + + + +## 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. + + + +## Frequently asked questions + +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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 + +--- -- 2.54.0