Help Center

SHARD Incident Management - Help

SHARD Incident Management

Incident reporting, investigation, and close-out in SHARD

SHARD Incident Management

The Incident Management module in SHARD is where your organization records safety and operational events, runs investigations, assigns corrective actions, and closes records with evidence — from first report through to verified close-out.

Purpose

Incidents provide a controlled record when something goes wrong or could have gone wrong seriously. The module keeps facts, timelines, investigation outputs, and follow-up actions in one place so HSE, supervision, and management can coordinate response without losing context between shifts or teams.

Who uses this

  • Reporters — raise the initial incident with type, severity, location, and immediate facts
  • HSE / investigators — triage, investigate, and document causes and controls
  • Supervisors and area owners — implement immediate controls and support the investigation
  • Action owners — complete corrective tasks linked to the incident
  • Management — review open incidents, overdue actions, and close-out readiness

Typical workflow

  1. Report the incident with what happened, when, where, and who is involved.
  2. HSE reviews severity and decides the investigation level required for your site rules.
  3. Immediate controls are applied on site; the record moves through review and investigation statuses.
  4. Investigators capture evidence, timeline, and findings in the incident workspace (including structured investigation tools where enabled).
  5. Corrective and preventive actions are raised — often linked to the Action Tracker for ownership and due dates.
  6. Actions are completed and verified; the incident moves toward close-out.
  7. The record is closed when investigation and agreed actions are complete.

Investigation depth and status names may vary by configuration. Cerb.works aligns the incident workflow with your pilot scope during setup — do not assume every analytics or lessons-learned feature is enabled on day one.

How to report an incident

From the reported queue through classification, details, submit, and the saved incident record.

  1. 1

    Step 1

    Step 1

    Incidents overview

    The Reported tab lists new and open incidents awaiting triage — your starting point before reporting a new event.

  2. 2

    Step 2

    Step 2

    Start new incident

    Use Create Incident to open the ISO 45001-aligned reporting form.

  3. 3

    Step 3

    Step 3

    Type and severity

    Select incident type, actual severity, and potential severity to route the correct investigation level.

  4. 4

    Step 4

    Step 4

    Incident details

    Describe what happened with a clear title and narrative. Demo captures use the deterministic title “Demo incident for help documentation”.

  5. 5

    Step 5

    Step 5

    Location and context

    Record where the event occurred and optional work activity or weather context for investigators.

  6. 6

    Step 6

    Step 6

    Submit incident

    Create Incident Report saves the record and routes it into the reported queue and investigation workflow.

  7. 7

    Final step

    Final step

    Incident record detail

    The saved incident shows number, status, severity, location, and links to start investigation — the controlled record after submission.

How to start an incident investigation

Open a reported incident, start the investigation workspace, document scope and findings, and save the investigation record.

  1. 1

    Step 1

    Step 1

    Open incident

    Open the reported incident from the queue to review facts before starting or continuing an investigation.

  2. 2

    Step 2

    Step 2

    Start investigation

    From the incident detail page, open Investigation to assign scope, triage level, and initial facts.

  3. 3

    Step 3

    Step 3

    Investigation scope

    The investigation workspace guides triage, evidence, root cause, and actions. Complete scope and initial facts before deeper analysis.

  4. 4

    Step 4

    Step 4

    Findings and actions

    Document root cause hypotheses, linked hazards, and corrective actions as the investigation progresses.

  5. 5

    Final step

    Final step

    Investigation detail record

    The saved investigation workspace shows cycle status, assigned steps, and links back to the parent incident record.

Roles and responsibilities

  • Reporter — notifies HSE promptly with accurate initial facts; preserves scene evidence where safe to do so.
  • HSE lead — owns triage, investigation assignment, and close-out criteria.
  • Investigator — documents an evidence-based account; separates facts from assumptions.
  • Action owner — delivers assigned corrective work by the agreed due date and provides proof of completion.
  • Approver / closer — confirms actions are effective before the incident is closed.

Evidence / attachments

Build a defensible record as the incident progresses:

  • Initial notification details — type, severity, location, people involved, immediate actions taken
  • Photos, documents, witness notes, and investigation workspace outputs
  • Linked observations or permits when the event relates to prior safety signals or controlled work
  • Corrective actions with owners, due dates, and completion evidence
  • Status history showing who advanced the record and when

Status lifecycle

Incidents move through controlled statuses from report to close-out. Your pilot may show legacy labels or an extended status set; common stages include:

  • Reported / Draft — initial record created
  • Under review — HSE triaging severity and next steps
  • Investigation in progress — formal fact-finding underway
  • Action plan pending / in progress — corrective work assigned and tracked
  • Pending effectiveness review — verifying actions before close-out (when configured)
  • Closed — investigation and agreed actions complete

Rejected or invalid reports may be closed administratively with documented rationale. Escalation from observations should create a new incident rather than overloading an observation record.

What pilot users should do

  • Report recordable and high-potential events in REACTOR as soon as practical — do not wait for a perfect investigation narrative.
  • Separate immediate scene control (physical response) from record updates (who updates REACTOR and when).
  • Link follow-up work to named owners in the Action Tracker; avoid informal-only action lists for pilot-scope incidents.
  • Use investigation tools enabled for your pilot; ask Cerb.works before assuming advanced analytics or automated KPI reporting is live.
  • Feed lessons back to supervision and toolbox talks even when formal lessons-learned publishing is not yet enabled.

Where to open it in REACTOR