Operations Practice

Open and run an internal incident record

Give responders one current account of impact, roles, evidence, decisions, actions, recovery, and the next update.

Preparation
Start immediately after declaration and continue until the authorised incident lead closes recovery.
Difficulty
Advanced
Task
Coordinate incident response
Back to the Task: Coordinate incident response

Before you start

Get what you need before you start

  • Use the organisation’s incident policy and emergency contacts.
  • Identify qualified security, privacy, legal, insurance, technical, and communications owners as applicable.
  • Have qualified owners choose an access-controlled incident system, evidence repository, retention period, audit requirements, and evidence-handling route.
  • Use Jira Service Management only for assigned actions, states, and approvals when the organisation has approved it. Keep sensitive incident evidence in the approved evidence repository and link to it under existing access controls.

Steps

Work through the method

Use the listed inputs and tools. Check the evidence when you need to verify a step.

  1. Declare and assign roles

    Open a timestamped record in the approved incident system. Select qualified role groups from the organisation’s policy and this incident’s needs, such as leadership, incident handlers, technical specialists, legal or privacy, communications, affected asset owners, and relevant third parties. Record decision authority, responsibilities, observed impact, affected systems, confidence, and the next update time.

    Why it matters: Explicit roles and observed facts reduce conflicting decisions while the situation changes.

    Input
    The detection record, incident policy, current responders, and observed service or security impact.
    Output
    A restricted incident record with roles, impact, confidence, scope, and next update.
    Tools in this step

    Evidence for this step

  2. Coordinate containment and evidence

    Log each proposed containment action, authority, owner, time, expected effect, evidence to preserve, and risk in the approved incident system. Keep sensitive evidence in the approved repository and use restricted links. Require authorised human approval before execution.

    Why it matters: Containment can destroy evidence, expand harm, or interrupt critical service when responders act from different assumptions.

    Input
    The incident record, technical evidence, qualified-owner advice, and containment options.
    Output
    An approved containment log with preserved evidence and checked effects.
    Tools in this step

    Evidence for this step

  3. Test recovery before restoration

    Record restricted links to eradication or repair evidence, recovery criteria, validation owner, monitoring plan, rollback condition, and approval. Restore only after the authorised owners inspect and accept the evidence.

    Why it matters: Service availability alone does not show that the incident cause is removed or operation is safe.

    Input
    Containment state, repair evidence, backups, validation checks, and recovery authority.
    Output
    A tested and approved recovery record with monitoring and rollback conditions.
    Tools in this step

    Evidence for this step

  4. Close updates and improvements

    Confirm the final internal status, hand approved facts to Customer Support, preserve the record and evidence under the approved retention and audit rules, and assign post-incident actions with owners and dates.

    Why it matters: Recovery leaves future risk when decisions and improvement work disappear after service returns.

    Input
    The complete incident record, approved communications facts, monitoring evidence, and open risks.
    Output
    A closure decision, communications handoff, preserved record, and owned improvement set.
    Tools in this stepJira Service Management

    Evidence for this step

Success checks

Check the result before you finish

  • One restricted record holds current roles, facts, confidence, decisions, and timestamps.
  • Sensitive evidence stays in the approved repository under defined access, retention, and audit rules.
  • Qualified owners approve evidence handling, notification, containment, and recovery.
  • Recovery criteria are tested before restoration closes.
  • Customer Support receives approved facts and post-incident work has owners.

Failure modes

Watch for these problems

  • Responders edit facts without timestamps. Restore an append-only decision and change record.
  • A containment action lacks authority. Pause it and escalate through the authorised incident lead.
  • Evidence moves through an unapproved tool. Stop and follow the qualified evidence-handling route.
  • Responders copy sensitive evidence into an action ticket. Remove the copy, keep a restricted source link, and review access and retention with the qualified owner.
  • Service returns and the incident closes without monitoring. Keep recovery open until the agreed checks pass.

Tools

Choose the tools you need

Sources

Read the sources behind this practice

Check what each source supports and where the advice has limits.