From c0f6cc33b58cc167144b783162685e469a9bc316 Mon Sep 17 00:00:00 2001 From: Maximilian Kaske <56969857+mxkaske@users.noreply.github.com> Date: Mon, 27 Jul 2026 08:42:21 +0200 Subject: [PATCH] chore: compliance guide content (#2449) * chore: compliance guide content * fix: hero --- .../dora-incident-reporting-requirements.mdx | 147 +++++++++++++++ .../iso-27001-incident-communication.mdx | 119 ++++++++++++ .../nis2-incident-reporting-requirements.mdx | 132 ++++++++++++++ .../guides/soc-2-status-page-requirements.mdx | 169 ++++++++++++++++++ .../src/content/pages/use-case/compliance.mdx | 59 +++++- 5 files changed, 623 insertions(+), 3 deletions(-) create mode 100644 apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx create mode 100644 apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx create mode 100644 apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx create mode 100644 apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx 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 new file mode 100644 index 00000000..5d9eb298 --- /dev/null +++ b/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx @@ -0,0 +1,147 @@ +--- +title: "DORA Incident Reporting Requirements" +hero: "DORA Incident Reporting: The 4h/24h/72h Clock and the Duty to Inform Clients" +description: "DORA's 4h/24h/72h reporting clock, how classification starts it, and the Article 19(3) duty to inform clients." +author: "openstatus" +publishedAt: "2026-07-26" +category: "compliance" +faq: + - question: "What are the DORA incident reporting deadlines?" + answer: "Three stages. An initial notification no later than 4 hours after classifying an incident as major, and in any case no later than 24 hours from becoming aware of it. An intermediate report within 72 hours of the initial notification, submitted even if there is no change in status. A final report no later than one month after the most recent intermediate report. The detail sits in Commission Delegated Regulation 2025/301, with reporting templates in Implementing Regulation 2025/302." + - question: "Does DORA require me to tell clients about incidents?" + answer: "Yes, where client interests are affected. Article 19(3) requires financial entities to inform clients without undue delay when a major ICT-related incident has an impact on their financial interests, including the measures taken to mitigate adverse effects. Article 14 separately requires crisis communication plans providing for responsible disclosure of major incidents to clients, counterparts, and the public." + - question: "When does the 4-hour clock start?" + answer: "At classification, not at detection. You have up to 24 hours from becoming aware of an incident, and once you classify it as major you have 4 hours from that moment — whichever comes first binds. This makes your classification decision and its timestamp a regulated artifact, and it means a slow classification does not buy you time." + - question: "Who does DORA apply to?" + answer: "Financial entities across the EU — credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and intermediaries, trading venues, central counterparties, fund managers, and more — plus ICT third-party service providers designated as critical. If you sell software to financial entities, DORA reaches you contractually through Chapter V rather than directly." + - question: "Can a status page satisfy DORA reporting?" + answer: "It can serve the Article 19(3) client information duty and support the Article 14 communication plan. It cannot serve the regulator reports — those go to your competent authority on prescribed templates through a designated channel. The two are different audiences with different content and different clocks." +--- + +DORA — [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) — has applied since 17 January 2025. Unlike NIS2 it is a regulation, not a directive: it is directly applicable across the EU without national transposition, so the text itself binds you, supplemented by the technical standards. + +Like NIS2, its incident obligations split into two that are frequently conflated: + +- **Reporting to your competent authority**, on prescribed templates, on a tight clock. +- **Informing your clients**, under Article 19(3), where their financial interests are affected. + +The second is where a status page belongs. The first is a regulatory filing, and no status page discharges it. + +## Who is in scope + +Chapter I lists twenty categories of financial entity — credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, **crypto-asset service providers and issuers of asset-referenced tokens**, central securities depositories, central counterparties, trading venues, trade repositories, alternative investment fund managers, management companies, data reporting service providers, insurance and reinsurance undertakings and intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories. + +Plus **ICT third-party service providers designated as critical**, who fall under a direct EU oversight framework. + + + +## Classification comes first + +You cannot report until you have classified, and classification is what starts the tightest clock. The criteria in [Commission Delegated Regulation (EU) 2024/1772](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj) cover: + +- Clients, financial counterparts, and transactions affected +- Reputational impact +- Duration and service downtime +- Geographical spread +- Data losses — availability, authenticity, integrity, confidentiality +- Criticality of services affected +- Economic impact + +Two of those — **duration and service downtime**, and **criticality of services affected** — are the ones monitoring data speaks to directly. Being able to state precisely when a service became unavailable, from where, and for how long is an input to classification, not merely a nicety after the fact. + +## The reporting clock + +| Stage | Deadline | Notes | +| --- | --- | --- | +| Initial notification | No later than 4 hours after classification as major, and no later than 24 hours from becoming aware | Whichever binds first applies | +| Intermediate report | Within 72 hours of the initial notification | Required even if status is unchanged | +| Final report | No later than one month after the most recent intermediate report | Root cause, remediation, impact | + + + +The stage deadlines and report contents are set by [Commission Delegated Regulation (EU) 2025/301](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj); the templates and submission formats by [Commission Implementing Regulation (EU) 2025/302](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj). Voluntary notification of significant cyber threats is also provided for under Article 19(2). + +## The client-facing duty — Article 19(3) + +> Where a major ICT-related incident has an impact on the financial interests of clients, financial entities shall, without undue delay as soon as they become aware of it, inform their clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incident. + +Two conditions worth reading precisely: the incident must be **major**, and it must have an **impact on financial interests**. Not every major incident triggers client notification, and not every client-visible degradation is a major incident. + +Article 14 sits alongside it, requiring communication plans that enable responsible disclosure of major incidents to clients, counterparts, and the public, with a designated person or role responsible for implementing the strategy. + +Article 11(2) also requires response and recovery procedures that include communication actions toward staff, external stakeholders, and the media. + + + +## What a status page serves, and what it does not + +**Serves:** + +- Article 19(3) client information, with a timestamped record of what was said and when. +- Article 14 crisis communication, as the channel the plan names. +- Article 11(2) communication toward external stakeholders during response and recovery. +- Duration and downtime evidence feeding the classification criteria. +- Article 10 detection, as one input — DORA requires mechanisms to promptly detect anomalous activities, explicitly including ICT network performance issues. + +**Does not serve:** + +- The initial, intermediate, or final regulator reports. Prescribed templates, designated channel, different audience. +- Classification itself. That is your process and your judgement. +- **Chapter IV — digital operational resilience testing.** Vulnerability assessments, scenario-based testing, and threat-led penetration testing for entities that meet the criteria. +- **Chapter V — ICT third-party risk.** The register of information, concentration risk analysis, contractual requirements, exit strategies. +- **Most of Chapter II — ICT risk management.** Governance, the risk framework, protection, backup and recovery policies, learning and evolving. +- Board accountability. Article 5 places ultimate responsibility on the management body, which cannot be delegated to a tool. + +The honest summary: DORA has five pillars, and a status page is one implementation detail inside part of one of them. + +## Retention + +DORA expects records sufficient to support reporting and supervisory review, and Article 13 requires post-incident reviews that feed back into your risk framework. Your ability to reconstruct an incident months later — including the availability record behind classification — depends on what you retained. + +Openstatus retention runs 14 days on Hobby, 3 months on Starter, 12 months on Pro, and 24 months on Scale. For a financial entity, the two short tiers are unlikely to be adequate; supervisory questions rarely arrive within a fortnight. + +## A practical setup + +1. Confirm your category and your competent authority. Know the submission channel before you need it — the [ESMA DORA hub](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora) collects the joint ESA material if you are unsure where to start. +2. Write the classification procedure against the 2024/1772 criteria, with a named decision-maker and a recorded timestamp for the decision. +3. Pre-fill what you can of the 2025/302 templates. Four hours is not long to compose a filing from scratch. +4. Define what "impact on the financial interests of clients" means for your business, so the Article 19(3) trigger is decided in advance rather than under pressure. +5. Name the status page in your Article 14 communication plan and keep clients subscribed to it. +6. Retain monitoring and incident data long enough to answer supervisory questions. +7. Drill the whole path. The 4-hour clock does not accommodate a first attempt. + +Openstatus covers steps 5 and 6, and contributes evidence to step 2 through its availability record — 28 monitoring regions, timestamped incident history, email and RSS/Atom/JSON subscriber notification, and a full in-transaction audit log on Pro and Scale. Steps 1, 3, 4, and 7 are yours, and that is where supervisory exposure concentrates. + +## Primary sources + +DORA is a regulation, so the EUR-Lex text is the operative law — there is no national act to chase. The technical standards carry most of the detail. + +- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) — Article 11 for response and recovery, Article 14 for communication, Articles 17–20 for incident management and reporting, Chapter V for third-party risk. +- [Commission Delegated Regulation (EU) 2024/1772](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj) — classification criteria and materiality thresholds for major incidents and significant cyber threats. +- [Commission Delegated Regulation (EU) 2025/301](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj) — content of the initial, intermediate, and final reports, and the time limits. +- [Commission Implementing Regulation (EU) 2025/302](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj) — the standard forms, templates, and reporting procedures. +- [ESMA's DORA hub](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora) — joint ESA guidance, Q&As, and implementation material. + + + +## Related reading + +- [NIS2 incident reporting](/guides/nis2-incident-reporting-requirements) — the general regime; where both apply, reporting under DORA can satisfy the NIS2 duty +- [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 +- [Status pages for crypto exchanges and DeFi protocols](/use-case/crypto) — if you are a CASP or token issuer + +--- + +Start your status page + +--- 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 new file mode 100644 index 00000000..471001f0 --- /dev/null +++ b/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx @@ -0,0 +1,119 @@ +--- +title: "ISO 27001 Incident Communication" +hero: "ISO 27001 Incident Communication: The Annex A Controls That Touch Your Status Page" +description: "Which ISO 27001:2022 Annex A controls a status page evidences, what an auditor samples, and the far larger part it cannot cover." +author: "openstatus" +publishedAt: "2026-07-26" +category: "compliance" +faq: + - question: "Does ISO 27001 require a status page?" + answer: "No. No Annex A control names a status page. A.5.26 requires incident response according to documented procedures, and those procedures normally include communication to affected parties. A status page is one way to implement and evidence that communication step." + - question: "Which Annex A controls does a status page relate to?" + answer: "Mainly A.5.26 (response to information security incidents) and A.5.28 (collection of evidence), with supporting relevance to A.5.24, A.5.25, A.5.27, A.5.29, A.5.30, and A.8.16. It is one implementation detail inside a handful of the 93 controls." + - question: "What is the difference between ISO 27001 and SOC 2 for incident communication?" + answer: "SOC 2 tests whether your stated controls operated effectively over a period. ISO 27001 certifies that you run a management system — the emphasis is on documented procedures, defined responsibilities, and demonstrable continual improvement. Practically, ISO auditors care more about whether your procedure exists and is followed than about sampling a large incident population." + - question: "Are Annex A controls mandatory?" + answer: "No. Annex A is a reference set. You select applicable controls through risk assessment and justify inclusions and exclusions in your Statement of Applicability. If you exclude a control, you must be able to explain why." + - question: "How long should I retain incident records for ISO 27001?" + answer: "The standard does not set a number; your own retention policy does, and the auditor checks that you follow it. Certification cycles run three years with annual surveillance audits, so evidence spanning at least twelve months is a practical floor." +--- + +ISO 27001 is a management system standard. That distinction shapes everything about how it treats incident communication, and it is why advice written for SOC 2 transfers only partially. + +A SOC 2 auditor asks: did this control operate effectively across the period? An ISO auditor asks: do you have a documented procedure, is it owned, is it followed, and can you show it improving? A status page is a small implementation detail inside that. Worth being precise about where it fits. + +## The scope boundary, stated first + +[ISO/IEC 27001:2022](https://www.iso.org/standard/27001) has 93 Annex A controls plus clauses 4 through 10, which are the actual management system — context, leadership, planning, support, operation, performance evaluation, improvement. **The clauses are mandatory. Annex A is a reference set you select from via risk assessment.** + + + +## The controls it does touch + +
+Requires you to plan and prepare for incident management: define roles, responsibilities, and procedures before anything happens. Your status page is part of the *preparation* — having the channel already provisioned, branded, and subscribed-to is the difference between communicating in fifteen minutes and standing up a channel mid-incident. The control is about the plan, not the tool. +
+ +
+You must assess events and decide whether they are incidents. This is triage, and it is entirely yours. A monitoring alert is an *event*; deciding it is an incident worth publishing is a judgement your procedure must define. Auditors like to see a documented severity threshold that determines what gets communicated externally. +
+ +
+The central one. Incidents must be responded to in accordance with documented procedures, which typically include notifying relevant interested parties. If your procedure says "we publish to the status page for severity 1 and 2," the auditor will check that you did, for the incidents you had. +
+ +
+Knowledge from incidents must be used to reduce future likelihood or impact. Public postmortems are a natural artifact here, though internal ones satisfy the control equally. What matters is that learning is captured and acted on, not that it is published. +
+ +
+Requires procedures for identifying, collecting, and preserving evidence. Timestamped, immutable-by-default incident records are directly relevant — as is being able to show who changed what. This is where an audit log earns its place. +
+ +
+A.5.29 covers maintaining information security during disruption. A.5.30 requires ICT readiness for business continuity — planned, implemented, maintained, and tested against defined recovery objectives (RTO/RPO). Your uptime record and incident timelines are supporting evidence that you measure real recovery against those objectives, rather than only asserting them on paper. +
+ +
+A.8.15 covers logging; A.8.16 requires networks, systems, and applications to be monitored for anomalous behaviour with appropriate action taken. External synthetic monitoring is one legitimate input. It is not sufficient on its own — A.8.16 expects security-relevant monitoring, not just availability checks. +
+ +## What an ISO auditor asks for + +Certification audits are lighter on sampling than SOC 2 Type II fieldwork and heavier on procedure. Expect: + +1. **Show me your incident management procedure.** A document, versioned, owned, approved. +2. **Show me it being followed.** Two or three real incidents traced end to end against the procedure. +3. **Show me the decision.** For an incident you did *not* communicate externally, why not? Which criterion in your own procedure justified that? This is A.5.25 being tested, and it catches teams who only prepared the "we told everyone" story. +4. **Show me the learning.** What changed as a result. +5. **Show me evidence handling.** How records are captured and preserved, per A.5.28. + + + +## Retention and the certification cycle + +ISO certification runs on a three-year cycle with annual surveillance audits. The standard sets no retention period for incident records; your documented retention policy does, and the auditor checks conformance with your own policy. In practice, evidence covering at least the last twelve months is the working floor for a surveillance audit. + +Openstatus retention runs 14 days on Hobby, 3 months on Starter, 12 months on Pro, and 24 months on Scale. If your policy says you keep operational records for a year, the plan needs to back that up — a policy you cannot honour is itself a nonconformity. + +## What openstatus contributes + +- **A.5.24** — a channel provisioned in advance, with subscribers already attached, so communication is a preparation item rather than an incident-time scramble. +- **A.5.26** — timestamped status reports through the full lifecycle: investigating, identified, monitoring, resolved. +- **A.5.28** — durable records, plus a full audit log of every workspace mutation, recorded in-transaction with the actor attached. Pro and Scale. +- **A.5.30** — a real availability record to test recovery objectives against, from 28 regions. +- **A.8.16** — synthetic monitoring as one monitoring input, with alerting into Slack, Discord, PagerDuty, or email. + +## What it does not contribute + +Everything else. The ISMS itself — scope, risk assessment, Statement of Applicability, internal audits, management review — is the substance of certification, and no monitoring tool produces it. Compliance automation platforms such as Vanta and Drata manage that layer; openstatus produces evidence you reference from inside it. + +If you are choosing where to spend effort before a certification audit, the procedure document and the Statement of Applicability matter more than the tooling. Get those right, then make sure the tool can retain what your policy promises. + +## Primary sources + +ISO standards are not free, which is worth knowing before you go looking. The catalogue pages describe scope and contents without paywalling that summary. + +- [ISO/IEC 27001:2022](https://www.iso.org/standard/27001) — the certifiable standard. Clauses 4–10 are the requirements; Annex A is the reference control set. +- **ISO/IEC 27002:2022** — implementation guidance for the Annex A controls. This is the document that actually explains what A.5.26 or A.5.30 expect of you; 27001 only names them. +- **ISO/IEC 27035-1:2023** — information security incident management, part 1: principles and process. Defines the five-phase model (plan and prepare, detect and report, assess and decide, respond, learn lessons) that the A.5.24–A.5.28 controls compress into five lines. + +If you are writing the incident procedure that A.5.26 tests, 27035-1 is the more useful purchase of the three. + +## Related reading + +- [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 +- [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 + +--- + +Start your status page + +--- 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 new file mode 100644 index 00000000..347dbb39 --- /dev/null +++ b/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx @@ -0,0 +1,132 @@ +--- +title: "NIS2 Incident Reporting Requirements" +hero: "NIS2 Incident Reporting: The 24/72/One-Month Cascade, and What You Owe Your Users" +description: "NIS2 Article 23: the 24h/72h/one-month cascade to your CSIRT, and the separate duty to notify your own service recipients." +author: "openstatus" +publishedAt: "2026-07-26" +category: "compliance" +faq: + - question: "What are the NIS2 incident reporting deadlines?" + answer: "Three stages under Article 23(4). An early warning within 24 hours of becoming aware of a significant incident. A full incident notification within 72 hours of becoming aware, updating the early warning with an initial assessment of severity, impact, and any indicators of compromise. A final report within one month of the incident notification, covering root cause and remedial measures. If the incident is still ongoing when the final report is due, you submit a progress report instead and the final report follows within one month of the incident being handled." + - question: "Does NIS2 require me to tell my customers about incidents?" + answer: "Yes, separately from regulator reporting. Article 23(1) requires entities to notify the recipients of their services, without undue delay, of significant incidents likely to adversely affect the provision of that service. Article 23(2) adds that where a significant cyber threat exists, you inform recipients of measures or remedies they can take." + - question: "Can a status page satisfy NIS2 reporting obligations?" + answer: "It can serve the Article 23(1) obligation to notify service recipients. It cannot serve the 24-hour, 72-hour, or one-month reports — those go to your CSIRT or competent authority through a designated national channel, usually a specific portal or form. Publishing to a status page is not notifying a regulator." + - question: "What counts as a significant incident under NIS2?" + answer: "Article 23(3) sets the baseline: an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Implementing acts add quantitative thresholds for certain digital infrastructure and digital provider sectors, and national transpositions may add detail." + - question: "When did NIS2 take effect?" + answer: "The directive entered into force in January 2023 with a member state transposition deadline of 17 October 2024. Because it is a directive rather than a regulation, the binding rules are in each member state's national law, and transposition ran late in a number of countries. Check the national implementation that applies to you rather than the directive text alone." +--- + +[NIS2](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) — Directive (EU) 2022/2555 — gets discussed as though it were one obligation. It is at least two, they run on different clocks, and they go to different audiences. Conflating them is the most common mistake in vendor content on this topic. + +- **Reporting to the state.** A three-stage cascade to your CSIRT or competent authority. 24 hours, 72 hours, one month. +- **Notifying your own users.** A separate duty under Article 23(1), owed to the recipients of your services, with no fixed clock — "without undue delay." + +A status page addresses the second. It has nothing to do with the first. + +## Are you in scope? + +NIS2 covers **essential** and **important** entities, generally medium-sized or larger (50+ staff, or turnover and balance sheet above €10M), operating in listed sectors. Annex I covers energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration, and space. Annex II adds postal services, waste management, chemicals, food, manufacturing, digital providers, and research. + +For software companies the relevant hooks are usually **digital infrastructure** (cloud computing service providers, data centre services, CDNs, DNS, trust services) and **ICT service management** (managed service and managed security service providers). Some entities are in scope regardless of size — DNS providers, TLD registries, and trust service providers among them. + +If you land in one of those sectors, [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj) is the one to read next: it sets out the technical and methodological requirements for Article 21 measures **and** the quantitative thresholds that define a significant incident for digital infrastructure and digital providers. It is where the vague word "significant" becomes numbers. + + + +## The cascade — Article 23(4) + +| Stage | Deadline | Content | +| --- | --- | --- | +| Early warning | 24 hours from becoming aware | Whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have cross-border impact | +| Incident notification | 72 hours from becoming aware | Updates the early warning; initial assessment of severity and impact; indicators of compromise where available | +| Intermediate report | On request from the CSIRT or authority | Status updates | +| Final report | One month from the incident notification | Detailed description, type of threat and root cause, applied and ongoing mitigation, cross-border impact where applicable | + +Two details that matter operationally. + +**The clock starts at awareness, not at occurrence.** An incident that began on Friday and was recognised on Monday starts its 24-hour clock on Monday. This makes your detection timestamp a regulated artifact — you should be able to say precisely when you became aware, and back it up. + +**Ongoing incidents get a progress report.** If the incident is not handled by the one-month mark, you submit a progress report and the final report is due within one month of the incident actually being handled. + +## The obligation people miss — Article 23(1) + +Buried at the end of Article 23(1): + +> Where appropriate, entities shall notify, without undue delay, the recipients of their services of significant incidents that are likely to adversely affect the provision of that service. + +And Article 23(2): where a significant cyber threat exists, you inform recipients of any measures or remedies they can take in response, and where appropriate, of the threat itself. + +This is a customer-communication duty with regulatory force. It is the part a status page genuinely serves — and the part with no template, no portal, and no deadline other than "without undue delay," which is exactly the kind of standard you want a documented, timestamped process for. + + + +## Where a status page fits, and where it does not + +**Serves:** + +- Article 23(1) notification of service recipients, with a timestamped record of what was said and when. +- Article 23(2) communication of measures recipients can take, where a threat affects them. +- Evidence that your Article 21 incident handling measures include a functioning external communication step. +- The detection timestamp that anchors your 24-hour clock, if your monitoring is what surfaced the incident. + +**Does not serve:** + +- The 24-hour early warning, the 72-hour notification, or the one-month final report. These go through your national channel — typically a designated CSIRT portal or form. There is no scenario in which publishing to a status page discharges them. +- Incident classification. Deciding an incident is "significant" under Article 23(3) is a judgement call your procedure must define. +- The Article 21 risk-management measures more broadly — supply chain security, cryptography, access control, vulnerability handling, business continuity, and the rest. +- Management-body accountability under Article 20, including the requirement that management bodies approve the measures and undergo training. + +## Article 21, briefly + +The reporting duties sit on top of Article 21's baseline measures: risk analysis and information system security policies, incident handling, business continuity and crisis management, supply chain security, security in acquisition and development, effectiveness assessment, cyber hygiene and training, cryptography, human resources security and access control, and multi-factor authentication. + +**Incident handling and business continuity** are where monitoring and status communication live. That is two items on a list of ten, and the other eight are unaffected by any status page. + +## Penalties, for calibration + +Essential entities: up to €10 million or 2% of total worldwide annual turnover, whichever is higher. Important entities: up to €7 million or 1.4%. Member states can also suspend certifications and impose temporary management bans on essential entities. National transpositions vary in how they apply this. + +The reason to note it is proportion: the enforcement risk sits with the risk-management measures and the regulator reporting, not with how attractive your status page is. + +## A practical setup + +1. Establish whether you are in scope under your national law, and as essential or important. +2. Identify your reporting channel — the specific CSIRT portal or form — **before** you need it. Finding it at hour 20 of a 24-hour window is not a plan. ENISA maintains the [CSIRTs Network](https://www.enisa.europa.eu/topics/eu-incident-response-and-cyber-crisis-management/csirts-network) and a [map of national cybersecurity organisations](https://www.enisa.europa.eu/topics/national-cyber-security-strategies/ncss-map/national-cyber-security-strategies-interactive-map/national-cybersecurity-organisations) if you need to find yours. +3. Define, in writing, what makes an incident significant for you, with someone named to make the call. +4. Set a target for notifying service recipients and record against it. +5. Retain evidence for both duties. Openstatus retention runs 3 months on Starter, 12 months on Pro, and 24 months on Scale; regulator correspondence should be kept alongside it. +6. Run the whole path once as a drill. The 24-hour clock is short, and the first time should not be a real incident. + +Openstatus covers step 4 and the evidence half of step 5 — a branded status page with timestamped incident history, email and RSS/Atom/JSON subscriber notification, and monitoring across 28 regions to anchor detection. Steps 1, 2, 3, and 6 are yours, and they are where the regulatory risk actually sits. + +## Primary sources + +All EU legislation is free to read on EUR-Lex, in every official language. Given how much secondary commentary on NIS2 is imprecise, go to the text. + +- [Directive (EU) 2022/2555 (NIS2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) — Article 21 for measures, Article 23 for reporting, Annexes I and II for sectors. +- [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj) — technical requirements and the quantitative significance thresholds for digital infrastructure and digital providers. +- [ENISA CSIRTs Network](https://www.enisa.europa.eu/topics/eu-incident-response-and-cyber-crisis-management/csirts-network) and the [national cybersecurity organisations map](https://www.enisa.europa.eu/topics/national-cyber-security-strategies/ncss-map/national-cyber-security-strategies-interactive-map/national-cybersecurity-organisations) — for locating your competent authority and reporting channel. + + + +## Related reading + +- [DORA incident reporting](/guides/dora-incident-reporting-requirements) — the financial-sector regime, with a tighter clock +- [SOC 2 and your status page](/guides/soc-2-status-page-requirements) — voluntary attestation rather than regulation +- [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 + +--- + +Start your status page + +--- \ No newline at end of file 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 new file mode 100644 index 00000000..25d939d4 --- /dev/null +++ b/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx @@ -0,0 +1,169 @@ +--- +title: "SOC 2 Status Page Requirements" +hero: "SOC 2 and Your Status Page: What Auditors Actually Ask For" +description: "Which SOC 2 criteria a status page can evidence, which it cannot, and the artifacts an auditor requests during Type II fieldwork." +author: "openstatus" +publishedAt: "2026-07-26" +category: "compliance" +faq: + - question: "Does SOC 2 require a status page?" + answer: "No. No Trust Services Criterion names a status page. CC2.3 requires you to communicate relevant information to external parties, including how they can report failures and how you inform them of incidents. A status page is one way to evidence that control — email distribution lists and support portals are others. What the auditor tests is whether the process exists, is followed, and produces records." + - question: "Which SOC 2 criteria does a status page help with?" + answer: "Primarily CC2.3 (communication with external parties) and CC7.4/CC7.5 (incident response and recovery), plus A1.1 if you carry the Availability category. It contributes evidence to those controls. It does not satisfy CC1 (control environment), CC3 (risk assessment), CC5 (control activities), CC6 (logical access), or CC8 (change management)." + - question: "What evidence will an auditor actually request?" + answer: "A population of incidents for the audit period, and for a sample of those, timestamped proof of when each was detected, when customers were notified, what was said, and when it was resolved. They will compare your status page timeline against your internal ticket or alert record to confirm the two agree." + - question: "How far back does a SOC 2 Type II audit look?" + answer: "A Type II observation window is typically 3 to 12 months. Your evidence must cover the entire window, which means retention matters more than most teams expect — if your monitoring data expires after 14 days, you cannot produce availability evidence for a 12-month period." + - question: "Can a status page replace Vanta or Drata?" + answer: "No. Compliance automation platforms track your whole control set, collect evidence across dozens of systems, and manage the audit workflow. A status page produces evidence for one narrow slice of that — external incident communication. They are complementary, not alternatives." +--- + +Most SOC 2 content aimed at status pages stops at "auditors want incident communication, buy a status page." That is not wrong, but it is not enough to walk into fieldwork with. + +This guide covers what the [Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) actually say, what an auditor requests when they test those controls, and — importantly — the large majority of SOC 2 that a status page has nothing to do with. + +Criteria are quoted from the AICPA's 2017 Trust Services Criteria with revised points of focus (2022), which is the current version and is free to download. + +## First, the scope boundary + +A status page is evidence for a handful of criteria. SOC 2 has around sixty criteria across five categories, with several hundred points of focus beneath them. Being precise about the boundary is what makes the rest of this guide useful. + + + +Here is the honest mapping. + +| Criterion | What it asks | Status page role | +| --- | --- | --- | +| CC2.3 | Communicate objectives and relevant information to external parties, including a channel to report failures and how incidents are communicated | **Primary evidence** | +| CC7.2 | Monitor system components for anomalies indicating malicious acts or failures | Supporting — synthetic monitoring is one input | +| CC7.3 | Evaluate security events to determine whether they constitute an incident | No — this is your triage process | +| CC7.4 | Respond to identified incidents by executing a defined program | Supporting — external comms is one step in that program | +| CC7.5 | Restore operations and communicate resolution | Supporting evidence | +| A1.1 | Maintain, monitor, and evaluate current processing capacity and use of system components (Availability only) | Supporting — the uptime and latency record | +| A1.2 | Backup, recovery infrastructure, and environmental protections (Availability only) | Minimal — recovery evidence at most | +| CC1, CC3, CC5, CC6, CC8 | Control environment, risk assessment, control activities, logical access, change management | **None** | + +If you carry only the Security category, a status page touches CC2.3 and parts of CC7. If you carry Availability — most infrastructure vendors do, because customers ask for it — it also feeds A1.1. + +## What CC2.3 actually says + +The criterion is about communication with external parties. The points of focus that matter for incident work: + +- You communicate objectives and changes to external users. +- You provide a channel for external parties to **report failures, incidents, concerns, and complaints**. +- You communicate relevant information about incidents to affected external parties. +- You have a process for considering and responding to what comes back through that channel. + +Read that list carefully — it is bidirectional. Most teams evidence the outbound half (we told customers) and forget the inbound half (customers can tell us). An auditor asking "how does a customer report that your service is broken?" is testing CC2.3, and "they email support" is a valid answer only if you can show the process exists and is monitored. + +## What the auditor requests during fieldwork + +For a Type II engagement, expect roughly this sequence. + +**1. The population.** "List every incident during the observation period." This is the request that catches teams out. If your incidents live partly in Slack threads, partly in a ticketing system, and partly in someone's memory, you cannot produce a defensible population — and an auditor who does not trust the population does not trust the sample drawn from it. + +**2. A sample.** They will pick a handful, usually weighted toward the severe ones. + +**3. Per-incident evidence.** For each sampled incident: + +- When was it detected, and by what? +- When were external parties notified, and through which channel? +- What was communicated at each stage? +- When was it resolved, and was resolution communicated? + +**4. Corroboration.** They will compare your customer-facing timeline against your internal record — alerts, tickets, on-call pages. Two sources that disagree is a finding. A status page updated three days after the fact, with a backdated timestamp that contradicts your PagerDuty record, is worse than no status page. + + + +## The retention trap + +A Type II observation window runs 3 to 12 months. Your evidence has to cover all of it. + +This is where teams get surprised: incident write-ups persist indefinitely, but the *monitoring data* behind availability claims usually does not. If you assert 99.9% availability for the period and your check history only goes back two weeks, you have an assertion without evidence. + +Openstatus retention by plan: + +| Plan | Data retention | +| --- | --- | +| Hobby | 14 days | +| Starter | 3 months | +| Pro | 12 months | +| Scale | 24 months | + +Match the plan to your observation window, not to your monitor count. A 12-month Type II on 14-day retention does not work regardless of how many endpoints you are checking. + +## What openstatus provides, concretely + + +
+ +**Timestamped incident history** + +Every status report, update, and resolution is stored with its timestamp. This is the artifact behind the CC2.3 sample — a durable record you did not have to assemble by hand at audit time. + +
+
+ +**Subscriber notification** + +Email, RSS, Atom, and JSON feeds. Evidences the proactive half of CC2.3: you pushed information out rather than waiting to be asked. Available from Starter up. + +
+
+ +**Maintenance windows** + +Scheduled maintenance shows advance communication of planned disruption, which is a distinct point of focus from incident response. + +
+
+ +**Audit log** + +Every mutation across your workspace is recorded in-transaction, including who or what made the change. Useful for CC7 evidence and for showing your own controls over the status page. Pro and Scale. + +
+ + +## Where openstatus is not the answer + +- **Control tracking and evidence collection across your stack.** That is what compliance automation platforms like Vanta and Drata do. Reference your status page from within them as evidence for CC2.3; do not expect one to substitute for the other. +- **Policies, risk register, vendor reviews, access reviews.** Entirely out of scope. +- **The inbound half of CC2.3.** Openstatus gives you the outbound channel. You still need a documented, monitored route for customers to report problems to you. +- **A formal availability SLA report.** You have the underlying uptime record within your retention window; producing a signed periodic SLA report against a contractual commitment is a separate exercise. + +## A workable sequence + +1. Decide which Trust Services categories you carry. Availability changes what evidence you need. +2. Write down your incident communication process — severity thresholds, who publishes, how fast. An undocumented process cannot be tested for operating effectiveness. +3. Make the public record and the internal record agree, every time. +4. Set retention to cover your full observation window before the window starts, not after. +5. Keep the inbound channel real and monitored. +6. Reference the status page as evidence inside whatever platform tracks your control set. + +Steps 2, 3, and 5 are the ones auditors actually fail teams on. The tooling is the easy part. + +## Primary sources + +- [2017 Trust Services Criteria (with revised points of focus, 2022)](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) — AICPA & CIMA. The criteria themselves, free. CC2.3 and the CC7 series are what this guide draws on. +- [2018 SOC 2 Description Criteria (with revised implementation guidance, 2022)](https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report) — AICPA & CIMA. Governs how you describe your system, which is a separate document from the criteria. + +Read the criteria before taking any vendor's mapping — including this one — at face value. They are shorter than their reputation suggests. + +## Related reading + +- [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 +- [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 + +--- + +Start your status page + +--- \ No newline at end of file diff --git a/apps/web/src/content/pages/use-case/compliance.mdx b/apps/web/src/content/pages/use-case/compliance.mdx index e1abf0a1..4815dbdc 100644 --- a/apps/web/src/content/pages/use-case/compliance.mdx +++ b/apps/web/src/content/pages/use-case/compliance.mdx @@ -14,13 +14,17 @@ 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. Every paid plan includes everything you need for SOC 2 incident communication compliance." + 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." --- ## Why SOC 2 auditors care about incident communication 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. ## What auditors look for @@ -32,7 +36,7 @@ When reviewing your incident communication controls, SOC 2 auditors typically ve - **Subscriber management**: Do affected parties have a way to receive updates? - **Consistent process**: Is your incident communication repeatable and reliable? -Openstatus checks every box automatically. +Openstatus covers all four. That is the incident communication control — the rest of your SOC 2 scope is a separate exercise. ## How openstatus helps @@ -64,7 +68,56 @@ For internal services or client-specific deployments, protect your status page w 4. Enable subscriber notifications 5. You're audit-ready -Every paid plan includes custom domain, incident history, subscriber notifications, and password protection — everything you need to satisfy SOC 2's incident communication requirements. +Every paid plan includes custom domain, incident history, subscriber notifications, and password protection — the pieces SOC 2's incident communication criteria ask for. One thing to get right before you choose: + + + +## Not just SOC 2 + +SOC 2 is the most common trigger, but it is not the only regime with an incident communication requirement — and the others are regulation rather than voluntary attestation. + + +
+ +**SOC 2** + +CC2.3 for external communication, plus the CC7 incident response series and A1.1 if you carry Availability. + +[Read the guide](/guides/soc-2-status-page-requirements) + +
+
+ +**ISO 27001** + +Annex A controls A.5.24 through A.5.30 for incident management and ICT readiness, and A.8.16 for monitoring. + +[Read the guide](/guides/iso-27001-incident-communication) + +
+
+ +**NIS2** + +Article 23(1) requires notifying the recipients of your services of significant incidents — separately from the 24h/72h/one-month reports to your CSIRT. + +[Read the guide](/guides/nis2-incident-reporting-requirements) + +
+
+ +**DORA** + +Article 19(3) requires informing clients where a major incident affects their financial interests, and Article 14 requires a communication plan naming the channel. + +[Read the guide](/guides/dora-incident-reporting-requirements) + +
+ + +Each guide maps the requirement to specific evidence, and is explicit about where a status page stops and your own process, procedures, and regulator filings begin. --- -- 2.51.2