A forklift clips a rack on the night shift. Nobody is hurt, the driver is behind on picks and the rack is still standing. Three days later the dent is a crack, and nothing on file shows the event ever happened.

After a serious event, the questions that follow are usually the same: when did the organization first know, and what did it do about it? An organization that can answer with dates, owners and closed actions is in a very different position from one that relies on memory. That record is what incident management produces, and it is why the record matters well beyond the safety team.

What is incident management?

Incident management is the process an organization uses to report, record, assess, respond to and learn from events that harm or could harm people, property, services or compliance.

ISO 45001:2018, clause 3.35, defines an incident as an “occurrence arising out of, or in the course of, work that could or does result in injury and ill health.” The definition covers events that could cause harm as well as events that did, which is why near misses belong in the process.

In everyday terms, incident management is the habit of writing down what went wrong, deciding how serious it is, fixing the immediate problem and then finding out why it happened so it does not happen again. Three examples show the range. A worker slips on a wet floor and catches a rail, which is a near miss that still needs a record. A supplier delivers a batch that fails an inspection, which is a quality incident. A shared drive is exposed to the wrong group of people, which is a data incident. The process is the same in each case even though the people involved differ.

Incident management belongs to the whole organization. Safety, quality, IT and compliance teams each handle incidents in their own area, and each needs the same basic record: what happened, who was affected, how serious it was, what was done and who owns the follow up. It can run on paper forms, spreadsheets or incident management software. It does not prevent incidents on its own. It limits the damage of the events that occur and reduces the chance that the same cause produces another one.

Why it matters: protecting people, meeting reporting duties and stopping repeat events

  • Early warning from small events: near misses show weak controls before anyone is hurt, meaning the fix costs less and nobody pays for it with an injury.
  • Reporting duties met on time: some regulators set fixed deadlines. US employers must notify OSHA within 8 hours of a work-related death and within 24 hours of a work-related in-patient hospitalization, amputation or loss of an eye, meaning a team without a working process can miss a legal deadline.
  • Audit evidence on file: a dated record of the event, the investigation and the closed actions gives auditors something to inspect, meaning compliance can be demonstrated on request.
  • Fewer repeat events: ISO 45001:2018 clause 3.36 defines corrective action as “action to eliminate the cause(s) of a nonconformity or an incident and to prevent recurrence,” meaning the goal is to remove the cause so the event does not return.
  • Visible trends: consistent categories let teams count events by type, site and cause, meaning repeat patterns surface before they become serious.

The six stages of the incident lifecycle

Every incident moves through the same stages, whatever its type. The table shows what happens at each stage and the record it should leave behind.

Stage What happens Record it produces
Detect and report Someone notices an event and tells the right person Initial report with date, time and location
Record and classify The event is logged and given a type and severity Classified incident record with a reference number
Contain and respond Immediate steps make the area or service safe Log of immediate actions and who took them
Investigate and find the root cause Investigators establish what happened and why Investigation findings and root cause statement
Agree corrective actions Actions remove the cause, each with an owner and due date Action list with owners and due dates
Review and close The team checks the actions worked and closes the record Closure sign off and lessons learned

Detect and report

Detection is the point at which a person or system notices an event and tells someone who can act. It matters because every later stage depends on it: an event nobody reports cannot be classified, investigated or corrected. For example, a warehouse operator photographs a cracked pallet rack and submits a report from a phone before the end of the shift.

Record and classify

Classification gives the event a type, such as injury, near miss, property damage, environmental release or data exposure, and a severity. It matters because severity decides how much investigation follows and which reporting duties apply. For example, a dropped load with no injury is logged as a near miss with high potential severity because someone could have been underneath it.

Contain and respond

Containment covers the immediate steps that stop a situation getting worse, such as isolating equipment, treating an injury or shutting off a system. It matters because harm can continue while the paperwork is completed. For example, a supervisor cordons off the aisle and tags the rack out of use.

Investigate and find the root cause

Investigation establishes what happened and why, using interviews, evidence and a structured method such as the five whys. It matters because fixing the visible symptom leaves the cause in place. For example, an investigator finds that locking pins were removed during maintenance and never refitted.

Agree corrective actions

A corrective action removes the cause of an incident. ISO 45001:2018 clause 3.36 defines it as “action to eliminate the cause(s) of a nonconformity or an incident and to prevent recurrence.” It matters because an action without an owner and a due date has nobody accountable for finishing it. For example, the team replaces the pins, adds a pin check to the post maintenance checklist and assigns the site engineer a two week deadline.

Review and close

Closure confirms that the actions were completed and that they worked. It matters because a closed record is only useful if the fix has been checked. For example, the team inspects the rack 30 days later, finds no recurrence and records the lesson in the next toolbox talk.

Example of incident management in practice: a dropped pallet in a distribution warehouse

The scenario below is illustrative. At 9:40 pm on a night shift, a pallet slips from the second level of a rack and lands in an empty aisle. Nobody is hurt. The operator reports it on a phone form within ten minutes. The supervisor classifies it as a near miss with high potential severity because the aisle is normally in use.

The area is cordoned off and the rack is tagged out of use. The next morning the safety lead investigates and finds that locking pins were removed during a maintenance change and not refitted. A search of earlier records shows two similar reports at another site that were closed without investigation.

Three corrective actions are agreed: refit the pins, add a pin check to the post maintenance checklist and add the same check at the second site. Each has an owner and a due date. After 30 days the safety lead inspects the racks, confirms the checks are being completed and closes the record. In this scenario no regulator notification was triggered because nobody was injured, and the classification record shows how that decision was reached. The full chain from first report to closure is on file with dates and names.

Incident management vs incident response vs corrective action: how do they differ?

The three terms overlap, and teams often use them as if they were interchangeable. They cover different parts of the same effort, and a risk assessment sits alongside them as the activity that happens before an event.

Term Purpose Typical owner Timing
Incident management Run the whole process from first report to review Safety, quality, IT or compliance lead, depending on incident type Continuous, from first report through closure
Incident response Contain and fix a specific event Responders such as a supervisor, an emergency team or an IT security team During and immediately after the event
Corrective action Remove the cause so the event does not recur The named action owner After the investigation, until the fix is verified
Risk assessment Identify hazards and weak controls before events occur Risk or safety lead Before work starts and when conditions change

Where incident management falls short and how to check it works

Incident management depends on people reporting. An event that nobody raises never enters the process, so the records can look healthy while real events go unseen. Inconsistent classification makes trends unreliable, and actions closed without verification leave causes in place. Software can route records and track deadlines, but people still investigate and decide.

Five checks show whether the process works in practice:

  • Compare reports with events: ask a sample of staff about recent events and confirm each one appears in the records.
  • Measure the delay: calculate the time between an event and its report for the last 20 records.
  • Sample closed records: check that each has an owner, a root cause and a verified action.
  • Look for repeats: search for the same cause across more than one record or site.
  • Run a reporting drill: simulate a serious event and confirm who notifies the regulator and by when.

What a complete incident record shows when an auditor asks

A complete incident record answers an auditor’s first questions before they are asked: what happened, when the organization knew, who acted and whether the fix held. Each stage above adds one piece of that evidence, from the first report to the checked closure, and a gap at any stage leaves a gap in the story. The practical step is to take the last five incidents on file and trace each from report to closure against the six stages, then add any missing stage to the process now. Teams that want a structured way to capture incidents and follow up on actions can look at Ideagen incident management software.

Frequently asked questions

What is the difference between an incident and an accident?

An accident is an incident in which injury or ill health occurs. ISO 45001:2018 notes that an incident with no injury but the potential for it may be called a “near-miss,” “near-hit” or “close call.” Using one agreed set of terms across sites keeps reports comparable, so each term should be defined in the procedure and applied the same way everywhere.

Does incident management apply outside workplace safety?

Yes. NIST SP 800-61 Rev. 3 defines a cybersecurity incident as “an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” The lifecycle stages stay recognizable across safety, quality, environmental and IT incidents, although the owners and reporting duties differ.

Who is responsible for incident management?

Top management holds ultimate responsibility for the management system, and each incident record needs a named owner. ISO 45001:2018 clause 3.12 notes that top management can delegate authority and provide resources, provided ultimate responsibility for the OH&S management system is retained. A safety, quality or compliance lead usually runs the process day to day.

What is a root cause?

A root cause is the underlying condition that, if removed, stops the same event happening again. In the warehouse example the visible problem was a falling pallet and the root cause was a missing check after maintenance. Finding it usually takes more than one question, which is why structured methods such as the five whys are common.