If you operate an Australian RTO, you sit on top of a stack of data that is bigger than most RTO managers realise. RTO data is not just student records and AVETMISS reports — it is a layered set of obligations to ASQA, NCVER, state training authorities, the USI registry, the Privacy Act and (for funded RTOs) the contracts attached to specific subsidies.
This post is a working map of what that data actually contains, where each piece is supposed to live, and what to look for in any platform that claims to manage it.
One thing up front: the RTO is responsible for compliance with all data obligations, not the software. ASQA, NCVER, your privacy regulator and your funding contracts hold the RTO accountable. Software is a tool that helps you meet those obligations — it does not transfer them.
The five data layers in every RTO
Most RTOs run as if their data is one thing: "the system." It is actually five overlapping layers, each with different rules.
1. AVETMISS reporting data
The NCVER-defined dataset that flows to AVS today (and to STARS via the VDS Program by 31 December 2028). Includes Client (NAT00080), Enrolment (NAT00120), Subject, Program, Disability, Prior Education and related files. Coded fields, defined value lists, strict validation.
2. USI registry data
What appears on the student's national transcript. Outcomes per unit per RTO per year. The RTO submits via API or via the USI Transcript Service; the registry is the single source of truth for the student.
3. ASQA evidence data
Whatever ASQA can ask for at audit: pre-enrolment information versions, signed acknowledgements, marketing material claims, assessment tools, evidence per student per unit, validation records, moderation decisions, complaints handling, trainer/assessor matrices, RPL and Credit Transfer evidence.
4. State / funded program data
For RTOs delivering government-funded training, additional reporting to state training authorities — TAC in WA, Department of Education in NSW, Skills First in Victoria, etc. Each has its own dataset, its own format, and its own audit cycle.
5. Operational data
Everything else: marketing leads, prospect emails, finance records, employee records, supplier data. Subject to the Privacy Act 1988 and the Australian Privacy Principles.
A platform that only covers layer 1 — AVETMISS — is not managing your RTO data. It is managing one slice of it.
Records retention obligations vary by category
Different layers have different retention rules, and the rules do not always pull in the same direction. Some highlights:
- Assessment evidence — retained for periods specified by ASQA; these are long, vary by qualification type, and apply regardless of whether the student finished
- Student records — retained per ASQA's general direction and the requirements of any relevant funding contract
- AVETMISS submission records — retained per NCVER guidance
- Privacy-Act-covered personal information — retained only as long as needed for the stated purpose, then securely destroyed
A platform that does not enforce retention by data category — that just keeps everything forever — is putting your privacy obligations at risk in the same breath that it tries to help your records obligations. In the other direction, a platform that auto-deletes everything after a fixed period is putting your evidence obligations at risk. The right answer is category-aware retention, not "delete everything" or "keep everything."
Data security and the 2025 Outcome Standards
The 2025 Outcome Standards expect systematic management of student information, including security. Practical implications for RTO data platforms:
- Encryption in transit and at rest
- Access control — staff see only the data their role requires
- Audit logs showing who accessed and modified what
- Backups and disaster recovery with documented RPO and RTO targets
- Hosting location — for some funded contracts, Australian-hosted is required
If your RTO data lives on a single laptop or in a shared Dropbox folder, you are not meeting these expectations even before ASQA looks at your training delivery.
Data ownership and exit rights
This is the question most RTOs do not ask until they want to leave. When you sign with an RTO platform, what happens to your data when the contract ends?
- Can you export all of it — including evidence files, signed forms, assessment submissions, audit logs — not just CSV of metadata?
- In what format? Will the export be readable without the original platform?
- Who owns the data while it sits in the system?
- What is the deletion timeline after exit?
A vendor that is vague on these is one you do not want to be locked into.
What to ask any vendor
Before signing with any platform that holds your RTO data, ask:
- Which of the five data layers above do you actually cover, and where do the gaps fall?
- Is records retention enforced by data category, or do you keep everything indefinitely?
- Where is the data hosted, and is it Australian-hosted for funded contracts that require it?
- Can we export our full data — including evidence files in human-readable form — at any time, with no exit fee?
- Who owns the data while it is in the system, and how is that worded in the contract?
Where RTO Grow fits
RTO Grow is designed around the full RTO data picture, not just AVETMISS. Enrolment, evidence, USI flows, audit packs, finance and operational data live in one schema, with category-aware retention rules and full export rights. Australian-built, mapped to AVETMISS today and the VDS STARS API for 2028.
We do not certify your compliance — your team does. What we do is give you a single, exportable, auditable home for the data your obligations are tied to.
See our security and trust page or book a demo to walk through which RTO data layers your current setup is missing.