NDIS reportable incidents: categories, timelines, and what your software must do

The NDIS (Incident Management and Reportable Incidents) Rules 2018 divide incidents into two categories: those that must be managed internally under the provider's incident management system, and reportable incidents that must be notified to the NDIS Quality and Safeguards Commission. The reportable incident categories are specific: the death of a participant while receiving supports from the provider; serious injury of a participant; abuse or neglect of a participant; unlawful physical or sexual contact or assault of a participant; the use of a restrictive practice that has not been authorised under the relevant state or territory law; and circumstances where a participant is missing or their whereabouts are unknown.

The notification timeline is non-negotiable and tightly prescribed. Once a registered NDIS provider becomes aware of a reportable incident, it must notify the Commission within 24 hours. This is not 24 hours from when the incident occurred — it is 24 hours from when the provider (meaning any staff member, including those who are not compliance officers) becomes aware. The trigger is awareness at the organisational level, not awareness by the compliance team. A support worker who witnesses an incident at 6pm on a Friday has triggered the 24-hour clock. Providers who design their workflows on the assumption that incidents are reported to the Commission during business hours will fail this requirement.

The initial 24-hour notification is not the final obligation — it is the beginning of a structured investigation and reporting process. Within five business days of the initial notification, the provider must submit a preliminary follow-up report to the Commission documenting what steps have been taken in response to the incident. The final report, which must document the complete investigation outcome, findings, and any changes to practice, must be submitted within timeframes that vary depending on the category of incident and the Commission's case management decision. Each of these stages requires status tracking, documented evidence, and a clear chain of custody for the investigation record.

Software must support this workflow end-to-end, not just record that an incident occurred. The minimum requirements are: structured incident capture with category classification; an automated escalation pathway that alerts the appropriate person within a timeframe that allows the 24-hour notification to be met; a tracking status that distinguishes between 'identified', 'notified to Commission', 'under investigation', 'preliminary report submitted', and 'closed'; and the ability to generate a complete incident record — including all notes, evidence attachments, and status changes — that can be provided to the Commission on request. Providers whose incident management system is a shared folder with PDF forms will find themselves unable to demonstrate compliance with the investigation documentation requirements.

The Commission's approach to reportable incidents has become more systematic. Incident data is used to identify patterns across providers, to flag providers for focused audit, and to identify systemic risks in specific support categories or geographic areas. A provider that reports incidents promptly and documents thorough investigations is demonstrating a compliance culture that the Commission recognises. A provider whose incident reports are consistently late, incomplete, or whose investigations are superficial is a provider that the Commission will look at more closely. Incident management capability is not only a compliance obligation — it is an indicator of organisational maturity that regulators use to allocate their oversight attention.