The most common audit finding: you can't prove you did it

The most common audit finding isn't "you didn't do the thing." It's "you can't prove you did the thing."

Most RTOs have the policies, the assessments, the moderation meetings. What they often can't produce on demand is the record of who changed what, when, and why. A student is marked competent. Six months later an auditor asks who marked them, against which version of the assessment tool, on what evidence. If the answer is a guess, or a scramble through inboxes and spreadsheets, that's the finding.

The 2025 Outcome Standards sharpen this. The shift from process compliance ("did you tick the box?") to outcome-based standards ("show me how you know this works") makes the audit a conversation about evidence, not paperwork. And evidence you can't reconstruct is evidence you don't have.

What an auditor actually asks

Three questions catch RTOs out, and underneath they're the same question, can your system remember?

1. When a competency outcome changes, is there a record of the old value, the new value, the user, and the timestamp? Not in an email, not in a screenshot, in a system that can produce it without anyone scrambling. A result that moved from Not Yet Competent to Competent with no trace of who changed it, or why, is a result an auditor can't trust.

2. When an assessment tool is updated, can you tell which students were assessed against which version? Versioning matters the moment an auditor asks why two students sat different question sets. "We think it was the current one" is not an answer.

3. When a trainer's qualification or industry currency lapses, do you find out before or after they keep marking? "After" is a finding, and a retrospective one, because every result they signed in the meantime is now in question.

The trail you assemble vs the trail that already exists

Here's the quiet problem: most RTOs' "audit trail" is assembled under pressure. The competency change is in the student management system, the email approving it is in someone's inbox, the assessment version is on a shared drive, the expired credential is in a folder nobody checked. The evidence exists, it's just scattered across four tools, and stitching it together is the week before audit that everyone dreads.

A single-record system flips that. When every change to a student, an enrolment, an assessment, a trainer or an attendance record is logged automatically, old value, new value, the user who made it, the timestamp, the audit trail isn't a document you build. It already exists. In RTObase the audit log captures exactly that across every core record, and resolves the user behind each change automatically, so "who did this" is never a guess.

Why this follows from one record

An audit trail is only as complete as the system underneath it. A standalone tool logs its own changes and nothing else, so the trail has holes exactly where the cross-tool handoffs are, which is exactly where findings live.

Because the student, the enrolment, the assessment, the trainer and the outcome all sit on one record, a change to any of them lands in the same log, in the same shape: what changed, from what to what, by whom, when. The credential that expired last Tuesday, the outcome that flipped in March, the record edited the day before audit, they're not three investigations. They're one query.

The RTOs that breeze through audits aren't doing more compliance. Their systems simply remember everything, automatically, so they don't have to. The difference shows up as an audit that takes a week instead of a month.

If that's the kind of trail you'd like behind every record, come and have a look.