Security and trust

RTO Grow holds personal information about real students. We treat it accordingly. Data is hosted in the Sydney AWS region, encrypted in transit and at rest, isolated per RTO at the database layer, and access-logged. We have no certifications to brag about yet, we describe below what is actually in place, not what we wish was.

Two things on this page can be checked without asking us.

RTO Grow is listed on NCVER's AVETMISS Compliant Software Register — AVETMISS release 8.0, available in all states and territories, listed 4 June 2026. NCVER lists a system once it produces correctly formatted AVETMISS files.

USI verification runs against the Australian Government USI Registry System, using the web services published for system developers, and the verification result is stamped on the student record for audit.

Links to both government sources are on our Integrations page.

All RTO Grow data, student records, assessments, evidence files, audit logs, sits in Supabase, hosted on AWS in the Sydney region (ap-southeast-2). Student personally identifiable information never leaves Australia.

Application code runs on Vercel, with global edge delivery for static assets. API requests for tenant data terminate in Sydney.

In transit: TLS 1.2 or higher for every request. HTTPS enforced; HTTP redirects to HTTPS. Modern cipher suites only.

At rest: AES-256 (AWS-managed keys) for the primary database, file storage buckets, and backups.

Every RTO operates inside a strict data boundary. The database enforces this with PostgreSQL row-level security (RLS) policies that check the caller's active RTO before returning rows.

This means even with the correct API key, an authenticated user from RTO A cannot read or write data belonging to RTO B. Service-role queries (used by trusted server code) bypass RLS but are limited to a small set of audited code paths.

This is the single most important control in a multi-tenant SMS. It is enforced in the database, not just in application code.

Every meaningful action is logged. Three layers:

1. Activity log, semantic events (enrolment created, assessment marked, document published) with actor, target, and timestamp. 2. Super-admin audit log, separate immutable trail for cross-RTO administrative actions, including impersonation events. 3. Row-level audit trail, database triggers capture before/after snapshots on 20+ critical tables.

Logs are append-only and tied to user identity. Designed to support evidence requirements under the 2025 Standards for RTOs and to give your ASQA audit team a clear answer to who changed this.

Authentication is handled by Supabase Auth (industry-standard JWT-based sessions). Passwords are bcrypt-hashed; we never see them.

Roles are role-based: super admin (RTO Grow staff), RTO admin, trainer, assessor, student. Permissions are enforced both at the API layer and in RLS policies.

Single sign-on (SAML 2.0) is available on request for staff logins: your IT sends us your identity provider's metadata (Microsoft Entra ID, Google Workspace, Okta) and we register it against your email domain, so your own MFA and access policies apply. Connecting it does not by itself disable password sign-in — ask us and we will remove password logins for your staff so single sign-on is the only route. Multi-factor authentication is enforced for RTO Grow staff accessing the platform administration surface, which is where cross-tenant access lives. Customer-facing MFA for your own users is on our near-term roadmap and is not available today — see the Integrations page for what connects right now.

Assessment authority is enforced by the platform, not by a process document. A person whose credential tier does not permit making an assessment judgement cannot record one, regardless of what they click, and that block holds even under an administrative override.

Point-in-time recovery is enabled on the production database, alongside daily automated backups retained on a rolling 7-day window with weekly snapshots held longer. Point-in-time recovery means we can restore the database to a specific moment rather than only to last night's copy. Backups are encrypted at rest and never leave Australia.

Records are never automatically deleted. A scheduled job moves long-inactive evidence records from active to archived status; archived records stay in the database, still queryable for audits. Retention follows the 2025 Standards for RTOs and the Privacy Act: records of AQF certification documentation are kept for 30 years.

We use a small number of vetted third-party services to run the platform: Supabase (database, auth, storage), Vercel (hosting), Stripe (payments), AWS SES (transactional email, sent from the Sydney region), and Anthropic (AI-assisted draft generation, only when explicitly invoked).

Student records and assessment evidence are never sent to AI services. Where a trainer uses an AI authoring feature, only the course content involved in that task is processed, it is not retained, and it is never used to train any model.

The full named list, with each vendor's own certifications and the region they operate in, is published on our Integrations page.

We design against WCAG 2.1 Level AA. Our public site currently returns zero violations on automated WCAG 2.1 A and AA testing across every page.

We are deliberately careful about what that proves. Automated testing covers only part of the standard — it cannot judge whether alternative text is meaningful or whether a workflow can be completed with a keyboard alone. We have not commissioned an independent accessibility audit, published a VPAT, or completed structured assistive-technology testing of the signed-in experience.

Our full accessibility statement sets out the scope, the limits, and what we fixed and when.

What we are not (yet):

• Not SOC 2 Type II certified • Not ISO 27001 certified • No third-party penetration test report (engagement planned) • No independent accessibility audit or VPAT

What we are:

• Built on infrastructure that is independently SOC 2 Type II certified (Supabase, Vercel, AWS) • Operating the controls a SOC 2 audit examines: access control, change management, audit logging, encryption, backups, incident response • Compliant with the Privacy Act 1988 (Cth) and the Australian Privacy Principles • Publishing service commitments rather than leaving them to a sales conversation: a 99.9% monthly uptime target, same business day support response, and five business days notice before disruptive maintenance. Those are set out in full on our service commitments page. • Independently listed on the NCVER AVETMISS Compliant Software Register, and integrated with the Australian Government USI Registry System

Every change to the platform is independently reviewed by a senior engineer before release.

If we discover a security incident affecting your data, we will tell you. We notify affected customers within 24 hours of becoming aware of a breach affecting their data, with a full written report to follow - and we meet the Notifiable Data Breaches scheme under the Privacy Act where it applies.

A named on-call engineer is rostered at all times. Email security@rtogrow.com.au, alerts route to mobile after hours.

If you find a security issue, please email security@rtogrow.com.au with details. We will acknowledge within 2 business days and keep you updated on the fix.

Please do not test against production tenant data or attempt to access other RTOs records. We do not currently run a paid bug-bounty program but we will publicly credit researchers (with permission) for valid disclosures.

For procurement security questionnaires, data-processing agreements, or detailed control narratives: security@rtogrow.com.au.

General support: hello@rtogrow.com.au.