Serious incident under KSC – 24h and 72h reporting

Serious incident under KSC — 24h and 72h reporting

A serious incident under Article 2(7) of the KSC Act is assessed by its significant, or potentially significant, adverse impact on services, service recipients or other entities. The Act does not create one fixed numerical threshold that applies to every organisation. Assess the facts, affected service, operational consequences and context; do not invent a rule such as “a certain number of records always means a serious incident.”

Legal status checked: 27 July 2026. This article is informational, not legal advice. For an uncertain classification, involve appropriate legal advice and CSIRT GOV through the applicable procedure.

The reporting rhythm for an entity entered in the Register is an early warning within 24 hours, a notification within 72 hours, and a final report generally within one month of notification, subject to statutory exceptions and the progress of handling. These are regulatory clocks that must run alongside containment and recovery.

Contents

• Meaning of a serious incident
• Early warning: 24 hours
• Notification: 72 hours
• Final report
• Operational checklist
• Roles and S46
• FAQ

Meaning of a serious incident

Evaluate availability, confidentiality and integrity impacts on the relevant services, customers, dependencies and wider safety consequences. A ransomware event, compromised privileged account, outage at a critical supplier or data exposure may all require analysis, but none can be classified safely by a generic numeric threshold alone. Maintain internal criteria based on service impact, risk analysis, continuity objectives and contracts, while recognising that the authority can review the assessment.

The point at which the organisation becomes aware matters. It is not necessarily the first automated SIEM alert; it is when responsible personnel can reasonably identify that the event may be serious. That distinction is not a reason to delay: escalate uncertain material events quickly so the decision and time are recorded.

Early warning: 24 hours

Submit an early warning through S46 within 24 hours of becoming aware of a serious incident. It can contain incomplete information. Record the preliminary assessment, affected services or systems, likely impact, immediate containment steps and a 24/7 contact. Do not wait for a completed forensic report if the impact already supports the serious-incident path.

Keep a short pre-approved template, a duty roster and access to S46. The person preparing the report needs only the information that is known and defensible at that point; technical investigation continues in parallel.

Notification: 72 hours

Within 72 hours, provide the fuller notification in S46. Develop the incident timeline, known attack vector, affected assets or data, impact on service recipients, service status, mitigations and cooperation with suppliers or other CSIRT teams. Be explicit about uncertainty rather than filling gaps with guesses. Preserve evidence such as logs, tickets, decision records and relevant communications.

If subsequent analysis changes the preliminary classification, document the reasoning and follow the system’s procedure for updating or closing the earlier notification. A good playbook assigns an owner for the regulatory timeline separately from the technical incident commander.

Final report

The final report is generally due within one month of notification. It should describe the established cause to the extent known, complete chronology and service impact, measures taken, preventive actions, and changes to risk assessment or controls. If handling remains ongoing, follow the applicable process rather than presenting an unfinished investigation as closed.

Operational checklist

Before an incident, maintain active S46 access, critical-service owners, 24/7 escalation, templates for each reporting stage, a legal and communications contact, and a tested playbook. In the first 24 hours, stabilise the service, preserve minimum evidence, assess significant impact, notify internal leadership and submit the early warning when the threshold is met. Between 24 and 72 hours, deepen technical and business analysis, coordinate suppliers and submit the notification. Afterward, complete the report, conduct a review and update risk treatment and the playbook.

Roles and S46

The accountable information-security manager remains responsible for the process despite delegation to a SOC, IT team or provider. S46 is the required channel after entry; a separate email does not automatically replace the required submission. SIEM, EDR and logging tools help detect and investigate, but they do not themselves assess, decide or submit a report.

FAQ

Must every ransomware event be reported?

No automatic rule applies. Assess the incident’s impact under Article 2(7); a service-affecting event can require the 24/72-hour path.

Do important entities report too?

Yes. The serious-incident obligations apply to key and important entities entered in the Register.

Can DevSentinel submit the report?

DevSentinel can support playbooks and technical response. An authorised representative of the entity submits in S46, and DevSentinel does not guarantee compliance.