An incident workflow that will not let you skip the aftermath.
Incident registers usually live in a ticketing tool that closes the moment service is restored, which is exactly where the regulatory questions begin: impact, root cause, lessons, evidence. On this platform an incident is a structured record that moves through intake, assessment, response, resolution, and review, and cannot be closed without a second pair of eyes.
An incident record built backwards from the questions that come afterwards.
An incident on this platform is a coded record (INC-001, per tenant) with severity from low to critical, a status lifecycle (open, investigating, contained, closed), and a classification from a tenant-configurable set: unauthorised access, data disclosure, malware, denial of service, service outage, vulnerability, policy violation, suspicious activity.
The record carries the fields a supervisor asks about, as fields rather than free-text afterthoughts: detection and reporting timestamps, confidentiality-integrity-availability impact flags, assessment summary, response plan, containment, impact, root cause, lessons learned, follow-up actions, and a closure review. An owner and a response lead are named people, not initials in a spreadsheet.
Around the record runs a six-step response workflow (intake, assess, plan, execute, resolve, review) where each step's completion is measured by health checks on the record itself: an incident with no response plan, an unexecuted plan, or an incomplete resolution is visibly not done, whatever the ticket status says.
Closure is a gated decision, not a status change.
The failure mode of incident management is not the response; operations teams are good at restoring service. It is the aftermath: the review that never happens, the root cause written as "resolved", the lessons-learned section pasted from the last incident. Ticketing tools permit all of that, because their job ends when the service is back.
This module makes the aftermath structural. The closure transition passes through an approval gate: someone proposes closure, and a designated approver (by default the compliance officer role) signs it off, in code, with the decision on the record. Health checks refuse to consider the workflow complete while the assessment, plan, execution, or resolution fields are empty, and an incident marked closed before it was reported is a validation error, not a curiosity.
The specific claim: on this platform an incident cannot quietly disappear into "done". The record either carries its aftermath, or it visibly does not.
Ticketing restores service. This record answers the supervisor.
Service-management tools are optimised for the first hour: routing, paging, restoring. Their records are conversation logs. When the supervisor asks, six months later, what the impact was, who led the response, and what changed afterwards, someone reconstructs a narrative from chat history.
This record is the narrative structure, filled in while the incident runs. It lives on the same platform that holds your suppliers, functions, and policies (the compliance context sits next door rather than in another system), and it carries the platform's standard discipline: tenant isolation enforced at the database, audit trail on every change, version locking, named accountability.
It is deliberately not a monitoring or alerting tool. Nothing here watches your infrastructure; incidents arrive from your operations stack and your people. What this module adds is the part your operations stack does not have: the regulatory record and the enforced aftermath.
The record is in product. The regulatory filings are not yet.
The DORA Articles 17–23 outputs (major-incident classification against the ESA criteria and the initial, intermediate, and final reports on their submission clock) are not generated in product today. The record is built to hold what those reports need, and our specialists prepare the filings from it; the packaged report generation is planned for the same reporting runtime that produces the Register of Information and AIFMD packages.
Links from an incident to the suppliers, assets, and functions involved are labels today, not structured references. The traversal a supervisor eventually wants ("show me every incident touching this critical provider") waits on that structured link, which is why the Suppliers module still lists the incident-linked view as roadmap.
There is no notification engine: the module does not page anyone, and GDPR or NIS2 notification templates are not built. Notification duties run through your existing channels, with the record as the source.
A discovery call, not a product demo.
You describe the compliance problem consuming the most of your team's time. We walk the platform through an example close enough to your operation that you can judge whether this way of modelling compliance fits how you want to work.
Book a discovery call →