Incidents
Incident lifecycle with the regulatory clock running.
What it does
The hard part of incident response in a regulated environment is not the technical response. It is proving afterwards that you classified it correctly, ran the playbook, and notified the regulator inside the statutory window.
This module runs the lifecycle and the clock at the same time. Intake, routing, SLA, playbook execution and post-incident review all happen against one record, and every playbook step is timestamped as it is completed.
Statutory notification deadlines count down in the interface, with escalating notifications as the deadline approaches. The 72-hour clock is not something someone has to remember.
Incident register
Classify, assign and track actions to closure, with attachments held against the incident record.
The register is what an auditor reads. Everything else in this module exists to make sure it is complete without anyone writing it up afterwards.
INC-2026-0088
Intake
Multiple channels, including a per-tenant email intake address and an API endpoint for tools that raise incidents automatically.
Incidents that arrive by whatever route people already use get logged. Incidents that require a new portal login do not.
Routing rules
Auto-assign by incident type, severity or organizational scope.
Minutes spent deciding who owns an incident are minutes off the notification clock.
SLA policies
Response and resolution targets per severity, with breach visibility on the record and in reporting.
Internal SLA breach is an early signal that the statutory deadline is also at risk.
IR playbooks
Step-by-step response playbooks, run against a live incident, with each step logged and timestamped as it completes.
A playbook in a document is a plan. A playbook executed in the record is evidence you followed it, which is the thing the regulator asks for.
Regulatory clocks
Countdown timers for statutory notification deadlines, with escalating notifications as the deadline approaches.
The 72-hour breach clock is one of the most commonly missed obligations in privacy enforcement. Making it visible in the interface is the whole control.
71:14:52 remaining
Incident
Notify regulatorStatutory notification deadline
71:14:52
INC-2026-0088 · Oman PDPL
- Contain08:52
- Assess scope09:31
- Identify data categories10:47
- Notify regulator--:--
Post-incident review
A structured review after closure, with the actions it produces carried into the register rather than into a document.
Lessons learned that live in a slide deck are not lessons learned. Actions with owners and due dates are.
How a day looks
A phishing report arrives at the tenant intake address at 08:40. A routing rule assigns it to the security operations lead by type. They classify it as a personal-data breach, which starts the statutory clock and pins it to the top of the record. The playbook runs: contain, assess scope against the asset inventory, identify the data categories from the linked RoPA entry. At 11:02 the DPO has what they need for the regulator notification, with two and a half days still on the clock and every step timestamped.
Roles that live here
- Security Operations
- Incident Manager
- Data Protection Officer
- CISO
- Business Unit Head
Drawn from sixteen built-in roles, each scoped along the org tree. Access control
Related frameworks
See Incidents on your notification obligations.
A 45-minute working session focused on the frameworks and requirements that matter to your organization.