Building an NDIS Incident Management System That Works

by | 3 Apr, 2026

Incident management is assessed in every NDIS audit. This article covers what a compliant incident management system needs to include, how reportable incidents work, and what good implementation looks like in practice.

What the requirement is

Every registered NDIS provider must implement and maintain an incident management system. This is a complete set of processes for identifying, recording, managing, resolving, and learning from incidents that occur in connection with delivering supports to participants.

The legislation (which is worth reading) sets out what that system must include: procedures for identifying and recording incidents, who incidents must be reported to internally, how participants affected by an incident will be supported, when investigation is required, when corrective action is needed, and how the system itself will be periodically reviewed.

It also sets out specific obligations around reportable incidents, the subset of incidents that must be notified to the NDIS Commission within strict timeframes.

Your documented system needs to cover all of these areas.

What counts as an incident

An incident under the NDIS rules is any act, omission, event or circumstance that occurs in connection with providing supports or services to a participant and has caused, or could have caused, harm to that participant. It also includes acts by a participant that cause serious harm or risk of serious harm to another person, in connection with service delivery.

The scope is broad, and it includes near misses (i.e. things that could have caused harm but didn’t). It also includes things that happen away from your premises, if they’re connected to the supports you’re providing, and situations you become aware of after the fact.

A participant disclosing harm by someone outside your service, while you were providing supports, may still be an incident. A near-miss medication error is an incident. A participant falling during a community access activity is an incident.

A good rule of thumb is if in doubt, record it.

Reportable incidents

Within the broader category of incidents, some must be notified to the NDIS Commission. These are called reportable incidents, and there are six categories:

  1. The death of a participant
  2. Serious injury of a participant
  3. Abuse or neglect of a participant
  4. Unlawful sexual or physical contact with, or assault of, a participant
  5. Sexual misconduct committed against or in the presence of a participant, including grooming
  6. The use of a restrictive practice that is not authorised in accordance with the relevant state or territory requirements

The first five categories must be notified to the Commission within 24 hours of your key personnel becoming aware of the incident. The use of an unauthorised restrictive practice must be notified within 5 business days, unless the use also caused harm to the participant, in which case the 24-hour timeframe applies instead.

For incidents requiring 24-hour notification, a written follow-up is required within 5 business days covering witness details and any further proposed actions. For incidents in the 5-day category, the written notification itself must include the full details from the outset. In either case, the Commission may subsequently request a final report, to be provided within 60 business days.

The most common issue is providers who aren’t sure where the line is, and who err toward not reporting. If you’re uncertain whether an incident is reportable, report it. Notifying the Commission of something that turns out not to meet the threshold is not a breach.

Common gaps in incident management systems

Recording workplace incidents but not participant incidents

Providers who come from a workplace health and safety background often have reasonable processes for recording worker injuries and near misses, but don’t have a specific process for recording incidents affecting participants. The NDIS incident management requirement is specifically about participants, and a WHS system doesn’t substitute for it.

Blank registers

An incident register with no entries isn’t automatically a non-conformance. A provider who has just started delivering services, or who delivers something very low-risk like supplying assistive products, might truly have nothing to record. But for any provider who has been operating for a meaningful period and working directly with participants, an empty register warrants closer attention. Auditors will look further, because the more likely explanation is that incidents aren’t being recognised or recorded rather than that none have occurred.

Recording what happened but not what was done about it

The legislation requires each incident record to include the actions taken in response, any consultation with the participant, an assessment of whether the incident could have been prevented, and what corrective action has been taken. A record that describes the event but stops there is incomplete. For anything of significance, there should be some analysis of contributing factors and documentation of what changed as a result.

No trend analysis

Your incident management system must provide for the collection of statistical information to enable you to identify systemic issues. In practice, this means someone is periodically looking across your incident data and asking whether there are patterns (e.g. participants, workers, times of day, or service types appearing repeatedly). Managing incidents individually without ever looking at the larger picture might mean you’re missing the continuous improvement function the system is designed to serve.

What your system needs to include

An incident management system for a registered NDIS provider should include at a minimum:

  • An incident management policy explaining your approach and obligations
  • procedure describing the step-by-step process for identifying, reporting, assessing, investigating where required, and resolving incidents
  • A specific procedure for reportable incidents covering the six categories, notification timeframes, and how notifications are submitted through the Commission portal
  • An incident report form that captures all required information at the time of the incident
  • An incident register providing an ongoing record of all incidents and their resolution status
  • Information for participants about how the incident management system works
  • Evidence that the system is being followed (e.g. completed forms, records of follow-up, documentation of corrective actions taken and reviewed)

The system also needs to be accessible. Workers need to know it exists and understand how it works, and participants need to informed about how incidents involving them will be managed. Both are legislative requirements, not optional additions.

Records must be kept for seven years

Incident records must be kept for seven years from the date the record is made, and reportable incident records must be kept for seven years from the date of notification to the Commission.

A note on proportionality

Your system needs to be appropriate for the size of your organisation and the complexity of your services. For example, a solo operator delivering therapy to a handful of participants doesn’t need the same systems as a large provider with many staff across multiple sites. But the core requirements always apply, regardless of your size.

If you’re building your incident management system from scratch, our free Incident Management System Builder generates a complete policy, procedure, forms, and register based on how your service operates.

RECENT ARTICLES

Penny Halpin

Penny Halpin

Penny is the founder of Paperbark Quality Collective and has a passion for quality, messy data, and working together to make improve the human services sector in Australia. She’s a qualified lead auditor and previously held a senior management role at a highly-regarded Approved Quality Auditor.