Incidents

The Incidents module governs the lifecycle of operational incidents in your organization: declaration, classification, response, containment, recovery, post-incident review, and closure. It is the governance layer above the incident response runtime (ticketing tools, paging systems, on-call rotations, war rooms).

This module is not your incident response platform. It does not page on-call engineers, run war room consoles, or coordinate live response. It captures the governed record of each incident so that an auditor, regulator, customer, or board can see the full lifecycle with evidence.

When you would reach for this

You set up incident governance when:

• A regulator or framework requires an audit-grade incident record beyond operational tooling.
• Customer agreements require formal incident notification with documented outcome.
• Material incidents need a structured post-incident review with action items that flow into the governance program.
• An incident touches multiple governed areas (privacy, security, vendor) and needs a single coordinating record.

You don’t reach for this for live incident response itself. The live response happens in operational tooling. This module captures the governed record that sits alongside.

What lives in the module

A composite set of record types around the incident:

• Incident is the central record: scope, classification, severity, declaration time, current status, owner.
• Incident timeline entries capture significant events during the incident (detection, declaration, escalation, containment, recovery, closure).
• Impact assessment captures the structured impact: customers affected, services impacted, data involved (if any), financial impact, regulatory implications.
• Containment and recovery records capture the actions taken and their outcomes.
• Post-incident review captures the structured retrospective: root cause analysis, contributing factors, lessons learned, action items.

A worked example: a maritime shipping company governs incidents across its fleet and ports

A maritime shipping company operates a fleet of vessels carrying containerized cargo across global trade routes, plus dock operations at several owned and chartered terminals. Incidents range from cargo damage events to vessel-system failures, port-side mishaps, customs incidents, and IT outages affecting the booking system. The director of operational risk, Linnea, sets up Incidents like this.

Step 1: declaration discipline. Each incident is declared promptly: operational issues by the duty officer, IT outages by the SOC, port-side events by the port manager, vessel-side events by the master. Each declaration creates an incident record: scope, classification (cargo, vessel, port, IT, customs, environmental), severity, owner.

Step 2: timeline. As the incident progresses, timeline entries capture significant events:

• Detection time.
• Declaration time.
• Initial response actions.
• Escalation to senior management (for higher-severity events).
• Customer or regulator notification (when triggered by severity).
• Containment actions.
• Recovery actions.
• Closure.

The timeline is the chronological record.

Step 3: impact assessment. Each incident’s impact is assessed structurally: which customers affected, which services, which data (if applicable), financial impact, regulatory implications. For a cargo damage event, customers and financial impact dominate. For a vessel-system failure, operational impact and (if a customer notification trigger applies) regulatory implications.

Step 4: containment and recovery. Actions taken to contain (stop the bleeding) and recover (restore service) are recorded. For the booking-system outage, containment was rerouting bookings to a backup process; recovery was restoring the primary system. Both are captured.

Step 5: post-incident review. For higher-severity incidents, a structured review is conducted within a defined window: root cause analysis, contributing factors, lessons learned, action items. Action items become findings tracked through remediation.

Step 6: closure. Incident is closed when containment is complete, recovery is verified, and (where applicable) the post-incident review has been completed and signed off.

After a year:

• The incident register is the full history of operational events.
• Trends emerge: which routes have more cargo events, which IT systems have more outages, which customers are most affected.
• Post-incident actions flow into remediation through findings.
• A regulator can be shown the incident lifecycle on any specific event.

What you’ll see in the product

Incidents lives under Governance → Incidents in the workspace.

Multiple tabs: Active Incidents, Recent Closed, By Classification, By Severity. Inside an incident: the timeline, impact assessment, containment and recovery records, post-incident review.

Every change is captured in the workspace Audit Log.

Common workflows

Declaring an incident

1. Incidents → Declare. Scope, classification, severity, owner.
2. Live response begins in operational tooling.
3. As events occur, timeline entries are added.

Conducting a post-incident review

1. From the incident, create a post-incident review.
2. Walk root cause, contributing factors, lessons learned.
3. Capture action items.
4. Action items become findings.
5. Sign off and close the incident.

Linking to violations and submissions

1. If the incident triggers a notification obligation, create a submission package linked to the incident.
2. If the incident reveals a compliance breach, declare a violation linked to the incident.

Related

• Violations - incidents may surface violations.
• Submissions - incidents may trigger notification submissions.
• Findings - post-incident action items become findings.
• Resilience - major incidents inform resilience reviews.
• Risks - recurring incidents may become risks.
• Security Operations - security alerts that escalate become incidents.