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.

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 Outcome 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 (Everyshot staff), RTO admin, trainer, assessor, student. Permissions are enforced both at the API layer and in RLS policies.

Multi-factor authentication for super admins is on the near-term roadmap. Single sign-on (SSO/SAML) for enterprise RTOs is on request.

Daily automated backups of the primary database, retained on a rolling 7-day window with weekly snapshots held longer. Backups are encrypted at rest and never leave Australia.

Student records and assessment evidence are retained for 7 years after course completion in line with the Standards for Registered Training Organisations 2015 (clause 3.4) and the Privacy Act. The retention job is automated and runs as a Vercel cron — no manual purge cycle to forget.

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

Full list and purposes: see our Privacy Policy. We do not sell data. We do not use Anthropic's API to train models on your data.

What we are not (yet):

• Not SOC 2 Type II certified • Not ISO 27001 certified • No published SLA with uptime guarantees • No third-party penetration test report (engagement planned)

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 • Designed to support RTO obligations under the Standards for RTOs and the 2025 Outcome Standards

Formal certification is on the roadmap as we scale to mid-market RTOs that require it.

If we discover a security incident affecting your data, we will tell you. Notification within 72 hours of confirmed impact, in line with the Notifiable Data Breaches scheme under the Privacy Act.

On-call engineer is the founder. 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.