Closing an Incident

Closing an incident is a deliberate process that ensures the response is fully documented, lessons are captured, and improvement actions are tracked. CrownSync Playbooks enforces a structured closure workflow to prevent incidents from being closed prematurely or without adequate post-incident review.

Incident Status Flow

Every incident in CrownSync progresses through a defined series of statuses. The incident lead controls status transitions, and each change is recorded in the incident timeline.

• Active— The incident is ongoing and the response team is actively working through the playbook phases. This is the initial status when an incident is declared.
• Contained— The immediate threat has been isolated and is no longer spreading or causing additional damage. The response team is working on eradication and recovery. Moving to this status signals that the urgency level has reduced but work continues.
• Resolved— The root cause has been eradicated, affected systems have been restored, and normal operations have resumed. Monitoring is in place to confirm the threat has not returned. The incident is functionally over but has not yet been formally reviewed and closed.
• Closed— The post-incident review has been completed, lessons learned have been documented, and improvement actions have been assigned. The incident record is finalised and becomes a permanent part of your organisation's incident history.

Status transitions must follow this sequence. You cannot skip from Active directly to Closed, for example. Each transition requires the incident lead to confirm the move and optionally provide a note explaining the rationale.

Root Cause Documentation

Before an incident can be moved to the Closed status, the incident lead must document the root cause. The root cause field captures the underlying reason the incident occurred, going beyond the immediate technical cause to identify systemic factors.

The root cause entry should address:

• What happened — A factual description of the technical failure or exploit
• Why it happened — The underlying conditions that allowed the incident to occur (e.g., unpatched vulnerability, misconfigured access control, lack of MFA)
• Contributing factors — Environmental or organisational factors that made the incident more severe (e.g., delayed detection, insufficient monitoring, unclear escalation paths)

The root cause is included in the incident report and serves as the foundation for improvement actions.

Lessons Learned

The lessons learned section captures what the organisation should take away from the incident. This is typically completed during a post-incident review meeting held within 10 working days of the incident being resolved. The review should involve all members of the response team and relevant stakeholders.

Effective lessons learned documentation covers:

• What worked well — Aspects of the response that were effective and should be maintained or reinforced
• What could be improved — Areas where the response was slow, unclear, or ineffective
• Gaps identified — Missing capabilities, tools, or procedures that would have improved the response
• Communication effectiveness — Whether internal and external communications were timely, accurate, and helpful
• Playbook accuracy — Whether the playbook content was relevant, up to date, and useful during the response

Improvement Actions

The final component of incident closure is creating tracked improvement actions. Each improvement action is a specific, measurable task that addresses a gap or weakness identified in the lessons learned review.

Each improvement action includes:

• Description — What needs to be done
• Owner — The person responsible for completing the action
• Deadline — When the action should be completed
• Priority — How urgent the action is relative to others
• Status — Open, in progress, or completed

Improvement actions remain visible on the dashboard until they are completed, ensuring they are not forgotten once the immediate pressure of the incident has passed. They are also included in executive summary reports so senior leadership has visibility of outstanding actions.

Reopening a Closed Incident

In rare cases, a closed incident may need to be reopened — for example, if the threat resurfaces or new information comes to light. Only organisation owners and admins can reopen a closed incident. Reopening changes the status back to Active and creates a timeline entry recording the reopening with a mandatory reason.