NDIS Incident Management Policy: What It Must Include and How to Write It

Why Incident Management Is Critical for NDIS Registration

Every registered NDIS provider will experience incidents. A participant falls. A staff member acts inappropriately. A restrictive practice is used without the required approval. The question auditors are asking is not whether incidents occur — it is whether your organisation has the systems, culture, and documentation to detect, respond to, and learn from them.

Incident management sits at the intersection of participant safety, legal compliance, and organisational accountability. Under the National Disability Insurance Scheme Act 2013 and its subordinate legislation, registered providers bear specific obligations that attach the moment they become aware of a qualifying event. Getting this wrong carries serious consequences: civil penalties, compliance notices, registration suspension, and in serious cases, referral to other regulatory bodies such as police or state child protection agencies.

For providers undergoing initial registration or re-registration audits, the incident management policy is one of the first documents a Quality Auditor will request. A weak or generic policy signals systemic risk and will almost always result in a finding. A well-constructed policy — one that reflects how your organisation actually operates — demonstrates the kind of mature governance the Commission expects at every registration tier.

What the NDIS Commission Requires (Practice Standard Outcome 2.4)

The primary compliance anchor for incident management is Practice Standard Outcome 2.4: Incidents, complaints and feedback, contained in the NDIS Practice Standards (Quality Indicators). Outcome 2.4 requires that registered providers have and implement a system for:

• Receiving, recording, and acting on incidents, complaints, and feedback
• Ensuring participants know how to report and are supported to do so
• Investigating incidents and complaints in a timely and thorough manner
• Using incident data to drive continuous improvement
• Complying with reportable incident obligations under the Rules

Alongside the Practice Standards, the governing legislation is the NDIS (Incident Management and Reportable Incidents) Rules 2018 (the Rules). The Rules define what a reportable incident is, who must report it, to whom, and within what timeframe. They also establish the Commission's powers to require further information, conduct investigations, and take compliance action.

The Rules are not aspirational — they are law. Your incident management policy must be explicitly drafted to give effect to both the Practice Standards (which set the quality benchmark for your systems) and the Rules (which set the legal obligations for notifications).

The Two-Layer Framework

Think of NDIS incident management as having two layers. The first layer is your internal incident management system — the policies, procedures, forms, and registers that govern how your organisation identifies, documents, investigates, and learns from incidents. The second layer is your external notification obligations — the specific, time-bound duty to notify the NDIS Commission of reportable incidents through the Commission portal.

Both layers must be present and functional for your organisation to be compliant. A provider that investigates incidents diligently but fails to notify the Commission on time is still non-compliant. A provider that notifies promptly but has no internal system for investigation and improvement is also non-compliant.

Reportable Incidents vs Non-Reportable Incidents — The Difference and Why It Matters

One of the most common sources of confusion for providers — and one of the most common points of audit failure — is the distinction between incidents that must be reported to the NDIS Commission and incidents that are managed internally.

Not every incident is a reportable incident. An incident is any event that has caused or has the potential to cause harm to a participant. This includes near misses, medication errors with no adverse outcome, property damage, service delivery failures, and interpersonal conflicts. These must all be captured in your incident management system and may trigger internal investigation and corrective action, but they do not automatically require Commission notification.

A reportable incident is a specific subset of incidents defined exhaustively in the Rules. The Rules contain a closed list — only those events that match the definitions in the Rules are reportable to the Commission. Everything else is an internal incident.

The practical importance of this distinction is twofold. First, knowing which incidents require Commission notification prevents providers from either over-reporting (consuming resources on non-qualifying events) or under-reporting (missing mandatory notifications). Second, the distinction shapes your procedure: reportable incidents trigger a mandatory notification pathway with tight timeframes, whereas non-reportable incidents follow your internal investigation and review process.

The 6 Types of NDIS Reportable Incidents

The NDIS (Incident Management and Reportable Incidents) Rules 2018 define six categories of reportable incidents. Each involves a serious risk to participant safety or rights. Your policy must name and define all six.

A Special Note on Restrictive Practices

Restrictive practices occupy a unique position in the incident management framework. Approved restrictive practices — those authorised through a behaviour support plan and meeting all state or territory requirements — are not, by definition, a reportable incident by virtue of being used. However, providers must separately report the use of restrictive practices to the NDIS Commission through the behaviour support reporting pathway, on a monthly basis for regulated restrictive practices.

If an approved restrictive practice is used in a manner that exceeds its authorisation — wrong type of restraint, applied outside the defined circumstances, used by an untrained worker — it becomes an unapproved use and is immediately a reportable incident under Type 05. Your policy must address both scenarios explicitly, and your staff must understand that "we have a behaviour support plan" does not automatically mean a use of restraint is approved or reportable-incident-free.

What Your Incident Management Policy Must Cover (The 12 Required Elements)

A compliant NDIS incident management policy is not a single-page statement of intent. It is a structured governance document covering every aspect of how your organisation manages incidents from the moment they occur to the moment the file is closed. Based on Practice Standard Outcome 2.4 and the Rules, auditors expect to find all of the following elements.

1. Purpose A clear statement of why the policy exists — to protect participant safety, meet legal obligations under the NDIS Act and Rules, and drive continuous improvement. The purpose statement anchors the rest of the document.
2. Scope Who and what the policy applies to — all workers (employees, contractors, volunteers), all registered supports and services, all participants, and all locations where supports are delivered. Be explicit that scope includes incidents occurring after hours or in community settings.
3. Definitions Plain-language definitions of: incident, near miss, reportable incident, serious reportable incident, restrictive practice, and worker. These must align with the definitions in the Rules — do not create definitions that contradict or narrow the legislative meaning.
4. Types of Incidents A classification framework covering: minor/low-risk incidents, moderate incidents, serious incidents, and reportable incidents (with the six categories listed). Each classification should indicate the response pathway it triggers.
5. Reporting Obligations Clear statements of who must report, to whom, and through what channel — including the obligation to report to the NDIS Commission via my.ndiscommission.gov.au for reportable incidents. Also address mandatory reporting obligations to other bodies (police, child protection) where applicable.
6. Notification Timeframes Exact timeframes from the Rules: serious reportable incidents within 24 hours; all other reportable incidents within 5 days. Internal timeframes for completing the incident report form (typically 24 hours from the event) should also be specified.
7. Investigation Process How your organisation investigates incidents — who conducts investigations, what their authority is, how evidence is gathered, what the investigation report must contain, and how findings are escalated. For serious incidents this should reference external investigation where internal conflict of interest exists.
8. Corrective Actions The mechanism for translating investigation findings into actionable change — who assigns corrective actions, how implementation is tracked, and how completion is verified. Corrective actions without accountability and follow-through are a common audit finding.
9. Root Cause Analysis For moderate-to-serious incidents, the policy should require a structured root cause analysis (not just a description of what happened). Methods such as the 5 Whys or fishbone analysis should be referenced, and the outcome of root cause analysis must feed into corrective actions.
10. Staff Training A commitment to training all workers in incident identification, internal reporting obligations, completion of the incident report form, and awareness of reportable incident categories. Training frequency, format, and records must be specified.
11. Review Cycle The policy must specify how often it will be reviewed — at minimum annually, or following a significant incident, regulatory change, or audit finding. The review process must include who is responsible and what triggers an out-of-cycle review.
12. Document Control Version number, effective date, document owner, approval authority, and review date. A document without version control cannot demonstrate it is the current, approved version — a basic but common audit failure.

The Incident Reporting Timeline — What the Commission Requires

The Rules prescribe specific timeframes that are non-negotiable. Your policy must reproduce these timeframes precisely and your procedure must make it operationally possible to meet them.

How to Write the Incident Management Procedure (Step by Step)

The policy sets out what your organisation does and why. The procedure sets out how. Both documents are required and they must be consistent with each other. Here is a practical structure for your incident management procedure.

Step 1: Immediate Response (0–4 Hours)

The procedure must specify what happens first. For any incident: ensure the participant's immediate safety, provide first aid if required, contact emergency services if the situation warrants it, and notify the on-call manager or supervisor. Staff should not attempt to investigate or document the incident before ensuring the participant is safe. The immediate response checklist should be laminated and posted in all support environments — it is not something staff should need to recall from memory under stress.

Step 2: Initial Notification to Management (Within 4 Hours)

The worker who witnessed or discovered the incident must notify their direct supervisor or the incident reporting contact within four hours. Notification can be verbal at this stage, but must be followed by the completed incident report form. The manager receiving the notification must immediately assess whether the incident is a reportable incident requiring Commission notification within 24 hours.

Step 3: Complete the Incident Report Form (Within 24 Hours)

The incident report form must be completed in full — not just the headline fields. A compliant incident report form captures: date, time, and location of the incident; the participant(s) involved (by identifier, not full name in shared systems); the worker(s) present; a factual description of what occurred; the immediate actions taken; the classification of the incident; and the name of the person completing the form. Avoid speculation about cause at this stage — that is for the investigation.

Step 4: Commission Notification (If Reportable)

If the incident is a reportable incident, the procedure must specify who is responsible for submitting the Commission notification, through what portal, and using what reference documents. The preliminary notification for serious incidents must go in within 24 hours, so this step cannot wait for internal approvals. Designate a primary and backup person authorised to submit Commission notifications and ensure they have portal access at all times.

Step 5: Investigation

Assign an investigator — someone with no direct involvement in the incident. For minor incidents, the direct supervisor may investigate. For serious or reportable incidents, a more senior person or independent investigator is preferable. The investigation must gather evidence (witness statements, documentation, physical evidence where relevant), establish what happened, identify contributing factors, and reach findings on root cause. Every step of the investigation must be documented.

Step 6: Corrective Action Plan

The investigation findings must be translated into specific, measurable corrective actions. Each action requires an owner and a due date. Actions might include additional training, policy or procedure changes, environmental modifications, supervision changes, or referrals to external agencies. The corrective action plan must be signed off by management.

Step 7: Review and Close

Once corrective actions are implemented and verified, the incident file can be closed. The closure must be documented in the incident register. Aggregated incident data should be reviewed by management at least quarterly to identify trends — a single incident may not reveal a pattern, but ten incidents involving the same worker, location, or support type will.

What Auditors Look For in Your Incident Management System

Understanding the auditor's perspective is the most efficient way to close gaps before your audit date. NDIS Quality Auditors assess incident management against the Practice Standards Quality Indicators — specific, measurable criteria linked to Outcome 2.4. Here is what they examine in practice.

Document Review

Auditors will request your incident management policy and procedure, your incident register for the preceding 12 months (at minimum), a sample of individual incident report forms, any Commission notification acknowledgements, and evidence of corrective action completion. They are looking for consistency between the policy, the procedure, and the actual practice evidenced in records.

Staff Interviews

Auditors interview frontline workers — not just managers. The questions are practical: "What would you do if you witnessed a participant being harmed?" "How do you submit an incident report?" "Who do you notify first?" "What is a reportable incident?" If staff cannot answer these questions, the policy is failing its primary purpose. Training records alone will not satisfy this requirement — workers must be able to demonstrate knowledge.

Participant and Family Input

Auditors may speak with participants or their families about whether they know how to report an incident or complaint, and whether they feel safe doing so without fear of negative consequences. Your policy must address participant access to the incident system, including for people with communication support needs.

Commission Notification Records

If your incident register contains events that appear to meet the reportable incident threshold, auditors may cross-check whether a Commission notification was submitted. Unexplained gaps — incidents in the register that look serious but have no notification record — are a significant finding. The Commission also has access to notification records submitted by your organisation, so any discrepancy between what you've submitted and what your register shows is visible to the auditor.

Trend Analysis Evidence

Sophisticated auditors look for evidence that you are using incident data, not just collecting it. Management meeting minutes that reference incident trends, or a quarterly incident analysis report, demonstrate that your system is functioning as intended. Absence of any analysis is a finding even if the underlying records are complete.

Common Incident Management Policy Failures (and Fixes)

Incident Register Requirements

The incident register is the operational backbone of your incident management system. It is a contemporaneous log of every incident captured by your organisation, maintained in a format that allows management to monitor trends and auditors to verify compliance. The register is not a Commission reporting tool — it is an internal governance document that should contain more detail than what you submit to the portal.

What the Register Must Contain

• Unique incident reference number
• Date and time of the incident
• Date and time the provider became aware of the incident
• Location where the incident occurred
• Participant identifier (not always full name — check your privacy framework)
• Worker(s) involved (by role or identifier)
• Incident classification (minor / moderate / serious / reportable)
• Incident type (from the six reportable categories, or internal classification)
• Summary description of the incident
• Immediate actions taken
• Whether the incident was reported to the NDIS Commission (Y/N)
• Commission notification date and reference number (if applicable)
• Investigation status and responsible person
• Investigation completion date
• Corrective actions assigned (with owner and due date)
• Corrective action completion status
• Date the incident file was closed

Format and Access

The register can be maintained in a purpose-built system, a spreadsheet, or a document management platform — the format is less important than the integrity and completeness of the data. Whatever system you use, it must be backed up, access-controlled, and able to be exported for audit purposes. Auditors will typically ask for the register in a format they can review during the audit process — a locked PDF that cannot be searched or sorted is not acceptable.

Record Retention

The NDIS Commission's record-keeping requirements specify that incident-related records must be retained for a minimum of 7 years from the date of the record. Where a record relates to a person who was a child at the time of the incident, records must be kept until that person turns 25 years of age, or for 7 years — whichever is the longer period. This applies to the register, individual report forms, investigation notes, corrective action plans, and Commission notification receipts.

Establish a document retention schedule and a destruction procedure that includes a review step before any incident records are destroyed. Many providers keep incident records indefinitely in a secure archive — given the relatively low volume of serious incidents at most small providers, this is often the simplest approach.