Free NDIS Incident Report Template (Word, PDF + Online Form) — 2026 Compliance-Checked

An NDIS incident report template only earns its place in your system if it captures what an NDIS Commission auditor actually wants to see — not just what happened, but the reportable classification, the notification deadline, and the corrective actions that followed. This page gives you that template, ready to use, plus the reportable-incident rules that determine how you fill it in.

Why this isn’t just paperwork

Incident management for registered NDIS providers isn’t a nice-to-have policy — it’s a condition of registration under section 73Y of the National Disability Insurance Scheme Act 2013. Every registered provider must have and maintain an incident management system as a condition of staying registered, covering both internal incidents and NDIS Commission reportable incidents.

The practical consequence: when the NDIS Quality and Safeguards Commission audits you at renewal, auditors don’t just check whether you have an incident management policy sitting in a folder. They check your actual incident records — do they exist, are they complete, were reportable incidents actually reported, and were they reported within the required timeframe. A polished policy document with no real incident history behind it is a red flag, not a pass.

With roughly 20,000 providers registered under the NDIS, incident management has become one of the most common — and most consequential — areas where audit findings turn up gaps.

Source: Verified NDIS Act s73Y registration condition context; NDIS Quality and Safeguards Commission — Reportable incidents and incident management

The template: NDIS Incident Report Form

Copy this structure into Word, Google Docs, or your own system. Every field below reflects what a reportable-incident record needs to contain to stand up to an NDIS Commission audit.

═══════════════════════════════════════════════════════════
NDIS INCIDENT REPORT
═══════════════════════════════════════════════════════════

SECTION 1 — REPORT METADATA
─────────────────────────────────────────────────────────
Report ID / reference number:      _______________________
Date report completed:             _______________________
Report completed by (name, role):  _______________________
Provider registration number:      _______________________

SECTION 2 — PARTICIPANT DETAILS
─────────────────────────────────────────────────────────
Participant name:                  _______________________
NDIS number:                       _______________________
Date of birth:                     _______________________
Support worker(s) involved:        _______________________
Others present/involved:           _______________________

SECTION 3 — INCIDENT DETAILS
─────────────────────────────────────────────────────────
Date of incident:                  _______________________
Time of incident:                  _______________________
Location of incident:              _______________________
Date/time provider became aware
(if different from above):         _______________________

Incident type (select all that apply):
  ☐ Death
  ☐ Serious injury
  ☐ Abuse or neglect
  ☐ Unlawful sexual or physical contact/assault
  ☐ Sexual misconduct (including grooming)
  ☐ Use of a restrictive practice NOT in line with
     the participant's behaviour support plan
  ☐ Use of a restrictive practice NOT in line with
     state/territory authorisation requirements
  ☐ Other incident (non-reportable but recordable —
     describe below)

Description of incident (factual, objective, what
happened — avoid opinion or speculation):
  ___________________________________________________
  ___________________________________________________
  ___________________________________________________
  ___________________________________________________

Injuries or harm sustained (if any):
  ___________________________________________________

Witnesses (name, contact, brief statement or note that
a statement was taken separately):
  ___________________________________________________

SECTION 4 — IMMEDIATE ACTIONS TAKEN
─────────────────────────────────────────────────────────
First aid / medical attention provided:  ☐ Yes  ☐ No
  Details: __________________________________________

Participant's immediate needs addressed: ☐ Yes  ☐ No
  Details: __________________________________________

Scene/environment made safe:             ☐ Yes  ☐ No
  Details: __________________________________________

Family/guardian/support network notified: ☐ Yes ☐ No
  Who, when, how: ___________________________________

Police notified:                          ☐ Yes  ☐ No
  Details: __________________________________________

SECTION 5 — NOTIFICATIONS & REPORTABLE STATUS
─────────────────────────────────────────────────────────
Is this incident NDIS-reportable?         ☐ Yes  ☐ No
  (See reportable vs non-reportable table below)

If YES, reportable category ticked in Section 3 determines
deadline. Confirm and record:

  Category requires 24-hour notification:   ☐ Yes  ☐ No
    → Deadline (date/time): _________________________
    → Actually notified (date/time): ________________
    → Notified by (name): ___________________________
    → NDIS Commission reference number: _____________

  Category requires 5-business-day notification: ☐ Yes ☐ No
    → Deadline (date): ______________________________
    → Actually notified (date): _____________________
    → Notified by (name): ___________________________
    → NDIS Commission reference number: _____________

  ⚠ If a restrictive practice incident caused harm,
    treat as 24-hour, not 5-business-day. Confirm:
    Did it cause harm?  ☐ Yes → use 24-hour deadline
                        ☐ No  → 5-business-day deadline

If NOT NDIS-reportable, record internally per your
incident management system and note why it falls outside
reportable categories:
  ___________________________________________________

SECTION 6 — CORRECTIVE & PREVENTATIVE ACTIONS
─────────────────────────────────────────────────────────
Root cause / contributing factors identified:
  ___________________________________________________
  ___________________________________________________

Corrective actions taken or planned:
  Action                          Owner        Due date
  _____________________________   __________   ________
  _____________________________   __________   ________
  _____________________________   __________   ________

Follow-up review date:             _______________________
Behaviour support plan reviewed
(if applicable):                   ☐ Yes  ☐ N/A

SECTION 7 — SIGN-OFF
─────────────────────────────────────────────────────────
Report prepared by:      _____________  Date: __________
Reviewed by (manager):   _____________  Date: __________
Final approval by:       _____________  Date: __________

Register updated:  ☐ Yes  (record ID: _________________)
═══════════════════════════════════════════════════════════

This structure works as a static Word or PDF form. If you’re filling these out on paper or in a document at the end of a shift, you’re already behind — the fields above (particularly the notification deadline fields in Section 5) are far easier to get right in a system that calculates the deadline for you the moment you select the incident category. More on that below.

Reportable vs non-reportable: quick reference table

Reportable incident category	Notification deadline	Notes
Death of a person with disability	Within 24 hours of becoming aware	Report as soon as practicable within the 24-hour window
Serious injury of a person with disability	Within 24 hours of becoming aware	Applies whether the injury occurred during service delivery or is linked to it
Abuse or neglect of a person with disability	Within 24 hours of becoming aware	Covers both alleged and confirmed abuse/neglect
Unlawful sexual or physical contact / assault	Within 24 hours of becoming aware	Includes contact by staff, other participants, or third parties during service delivery
Sexual misconduct (including grooming)	Within 24 hours of becoming aware	Broader than unlawful contact — includes conduct that doesn’t meet a criminal threshold but is still reportable
Restrictive practice NOT in line with the participant’s behaviour support plan	Within 5 business days of becoming aware — unless it caused harm, then within 24 hours	Check the harm trigger every time; don’t default to 5 days without confirming
Restrictive practice NOT in line with state/territory authorisation	Within 5 business days of becoming aware — unless it caused harm, then within 24 hours	Same harm-trigger check applies

Not NDIS-reportable, but still worth recording: near misses, minor first-aid incidents with no lasting harm, complaints that don’t meet a reportable threshold, and general service-quality issues. These belong in your internal incident register even though they don’t go to the Commission — auditors will still expect to see that your system captures them, because a healthy internal register is evidence your incident management system is actually working, not just handling worst-case events.

Source: NDIS Quality and Safeguards Commission — Reportable incidents; cross-referenced against NDIS Act reportable incident categories

6 common audit findings related to incident management

Based on the patterns that consistently surface in NDIS Commission audit and compliance activity, these are the gaps that most often catch providers out:

1. Policy exists, but no incident history to demonstrate it works. A provider can produce a well-written incident management policy but has zero or near-zero recorded incidents over a multi-year registration period — implausible for any provider delivering real support hours, and a strong signal to auditors that incidents aren’t being captured.

2. Reportable incidents notified late, with no record of why. Notifications made after the 24-hour or 5-business-day deadline, with no documentation of when the provider actually became aware versus when the incident occurred — a distinction auditors specifically probe, because “became aware” starts the clock, not the incident date itself.

3. Restrictive practice incidents defaulted to 5 days without checking the harm trigger. Providers assume all restrictive practice notifications get 5 business days, missing that harm caused by the practice shifts the deadline to 24 hours.

4. No documented corrective action following an incident. A report describes what happened but stops there — no root cause analysis, no corrective action assigned to an owner, no follow-up review date. Auditors look for the loop being closed, not just opened.

5. Behaviour support plans not reviewed after a related incident. When a restrictive practice incident occurs, the behaviour support plan itself often isn’t revisited — a missed opportunity to show the incident actually changed practice.

6. Inconsistent records between internal registers and Commission notifications. Details in the internal incident register (dates, description, actions taken) don’t match what was actually submitted to the Commission, undermining confidence in the whole system when auditors cross-check.

Every one of these findings shares a root cause: the incident record wasn’t built as a living, checkable document from the start. It was written up after the fact, inconsistently, without a system enforcing the fields and deadlines that matter.

Why a digital system beats a Word document

A Word template like the one above is a solid starting point, and free to use as-is. But it has structural limits once you’re managing incidents at real volume, across multiple support workers, over years of registration cycles:

• No audit trail. A Word document shows the final version, not who changed what and when. If a corrective action field was edited after the fact, there’s no record of the original entry.
• Deadline calculation is manual. Nothing stops a report sitting in a drafts folder past the 24-hour window if a human forgets to check the clock — and “we forgot” is not a defence an auditor accepts.
• No evidence export. When an auditor asks for every reportable incident from the last two years, cross-referenced against notification timestamps, pulling that together from individual Word files is slow and error-prone — exactly when you most need to move fast.
• Field reporting is hard. Support workers in the field, often on a phone between visits, are unlikely to open and correctly fill in a multi-section Word document in the moments after an incident.

A lightweight digital incident system addresses each of these directly: the incident category you select automatically determines and displays the correct notification deadline (including the harm-trigger check for restrictive practices), every entry and edit is timestamped and attributable, and the full evidence chain — from initial report through corrective action to sign-off — exports in the format an auditor or inspector actually wants to review. Reporting from a phone in under a minute, at the point of the incident, closes the biggest real-world gap: incidents that happen in the field but never get properly captured because writing them up later is too much friction.

That’s a genuinely different proposition to a static template, even a well-designed one — which is exactly why we built ours around 30-second mobile incident reporting, with reporters able to log incidents free and unlimited, and management/audit features starting from A$39 per manager seat.

---

Sources

• NDIS Quality and Safeguards Commission — Reportable incidents and incident management
• NDIS Quality and Safeguards Commission — Reportable incidents
• National Disability Insurance Scheme Act 2013 (Cth), section 73Y — incident management system as a condition of registration

---

This template and guidance provide general information for registered NDIS providers and do not constitute legal advice. Confirm current reportable incident categories and timeframes directly with the NDIS Quality and Safeguards Commission, as requirements can be updated.