SECURITY POLICY

1 Purpose and scope

This policy describes how R2 Education protects the confidentiality, integrity and availability of information in the OLNA Trainer and the NAPLAN Trainer. It is published so schools and education authorities can assess us without having to send a questionnaire first — and so a parent subscribing directly can see the same detail rather than a reassuring paragraph.

In scope: all three Trainers, the homepage, the three databases, the server functions, hosting and CDN, the AI provider integration, the payment integration, the source repositories and deployment pipelines, and the operator's own practices.

Out of scope: school‑owned and family‑owned devices, networks, identity systems and premises. Endpoint security, network filtering and supervision of students remain the school's or the parent's responsibility. Payment card processing is out of scope because it happens entirely inside Stripe and never touches our systems — §11.2 explains what that means.

2 Posture at a glance

3 Governance and accountability

R2 Education is run by a single principal, accountable for every security decision and the contact point for every security and privacy matter. There is no separate security team and this policy does not pretend otherwise.

Personnel

• Only the principal holds administrative credentials to either database, the hosting platform, the AI provider account or the source repositories.
• There are no employees, contractors or offshore support staff with access to student data.
• If that changes, this policy is updated before anyone else is granted access, and schools and subscribing parents are notified as a material change under the Privacy Policy.
• Administrative access happens from a device with full‑disk encryption, automatic screen lock, an up‑to‑date operating system, and unique credentials in a password manager.

4 Data classification

The full inventory of what is held, and what is deliberately not, is in sections 4 and 5 of the Privacy Policy.

5 Architecture

All three Trainers have three tiers, with one deliberate security property: the browser never talks to the database.

1. Browser — a static web application holding no database credentials. It cannot issue a database query; everything goes through tier 2.
2. Server functions — small server‑side functions that are the only path to data. Each independently verifies the caller's signed token, decides what that caller is entitled to, and returns only that.
3. Database — managed PostgreSQL, every table closed to anonymous and public access. Only the server functions, holding a privileged key that never leaves the server environment, can read or write.

5.1 The Trainers are separated

The OLNA Trainer, the NAPLAN Trainer and the Scholarship Trainer run on entirely separate databases, with separate credentials, separate server functions and separate hosting projects. A compromise of one does not reach the other, and a school using only one Trainer has data in only one system.

6 Authentication

6.1 Registration is payment‑gated

School accounts are created by a teacher or administrator — there is no public registration on that route, and never has been. A family subscription now starts from a sign‑up form on the Trainer's website, and rather than pretend that adds nothing, here is exactly what that surface is and is not.

6.2 Password storage

Passwords are stored only as bcrypt hashes with a per‑password salt. Plaintext is never written to a database or a log, and cannot be recovered by us or by anyone holding a copy of the database. A forgotten password is reset by a teacher, or by us on a family subscription, and never recovered.

6.3 Brute‑force protection

Every sign‑in attempt, successful or failed, is recorded with username, role, source IP, timestamp and outcome. Over a rolling 15‑minute window:

• after 10 failed attempts on one username, further attempts on that username are rejected;
• after 100 failed attempts from one IP, further attempts from that address are rejected.

The per‑IP limit is deliberately generous because a whole class typically shares one school IP through network address translation, and a tighter limit would lock out a classroom. It is more generous than a home connection needs, but the per‑username limit is the control that actually stops password guessing, and it applies identically to every account.

Failures return a single generic message that does not reveal whether the username exists, and internal error detail never reaches the browser.

6.4 Sessions

• A successful sign‑in issues a token signed with HMAC‑SHA256 using a secret held only in the server environment; it cannot be forged or altered without that secret.
• The token carries only the account identifier, the role and the administrator flag — no name, no password material.
• Tokens expire after seven days and are then rejected.
• The token lives in the browser's local storage, bound to our origin and unreadable by any other website, and is cleared on sign‑out.
• Every request is re‑verified server‑side. An expired or revoked token grants nothing, whatever the browser believes.

Students should sign out on shared devices — a token left on a classroom machine, or on the family laptop, stays valid until it expires. Schools and parents should both make that a habit. See §19.2.

7 Authorisation and access control

7.1 Deny by default at the database

Every table has row‑level security enabled with no permissive policies — in PostgreSQL that denies access to every role except the privileged service role. No table is readable by an anonymous or public client, and there is no way around the server functions.

7.2 Identity comes from the token, never the request

This is the single most important control in every Trainer. When a student records an answer, flags a question, submits writing or asks for their results, the student identifier is taken from the verified token on the server and any identifier in the request body is ignored. A modified client cannot read or write another student's records by changing an ID.

Where a request refers to a child object — an answer belonging to a particular practice test, say — the server checks that object belongs to the calling student before accepting the write.

7.3 Role scoping

Scoping happens in the server function, not the interface. Hiding a button is not access control; removing the data from the response is.

7.4 Minimal responses

Responses carry only the fields the caller needs. The leaderboard, for instance, returns display names and aggregate accuracy only — deliberately excluding usernames, account identifiers, teacher notes, adjustment settings and individual answers, so a feature every student can see cannot become a data leak.

7.5 Privileged key handling

Each database's service key lives in its server function environment. It is never sent to a browser, never built into the application bundle, and never committed to source control.

8 Encryption

8.1 In transit

All traffic — browser to site, browser to server functions, server functions to database, server functions to the AI provider — uses HTTPS with TLS 1.2 or higher. HTTP is redirected to HTTPS by the hosting platform, and certificates are issued and renewed automatically.

8.2 At rest

All three databases and their backups are encrypted at rest by the platform using AES‑256, with keys managed by the underlying cloud provider. Static site files contain no personal information.

8.3 Application layer

Passwords carry the additional one‑way bcrypt protection in §6.2, so they stay unusable even to someone with full database access.

9 Application security controls

9.1 HTTP response headers

Security response headers are configured per hosting project, and are currently uneven across the three:

Bringing the OLNA Trainer up to the same configuration is a small change to a static header file and is our next scheduled security task (§19.3). These headers are defence in depth: the controls in §7 do not depend on them.

10 AI service controls

10.1 Data minimisation

Requests to the AI provider carry only what the task needs: for generation, a year level, topic and difficulty; for writing feedback, the response text, the prompt and the year level. No student name, username, account identifier, class or school name goes into any AI request. The provider receives student writing without knowing whose it is.

10.2 Fair‑use caps

Each account has a daily cap on each AI endpoint, calculated on the Perth calendar day — 20 writing responses per account per day, with lower caps on generation endpoints. If the cap check itself fails the request is allowed, so a database hiccup never locks a student out mid‑lesson.

10.3 Output validation

Model responses must match a strict predefined schema before display. A malformed or refused response is discarded and the failure logged rather than rendered. Generated content is HTML‑escaped like any other untrusted input.

10.4 Metering

Every AI call is logged with function, model, outcome, token counts, cost, duration and calling account — and no question content, answers or writing. It exists for cost control and abuse detection.

10.5 Model training

Our AI provider's commercial API terms state that customer inputs and outputs are not used to train its models. We have not enabled and will not enable any arrangement under which student work trains a model.

10.6 Availability

AI features are non‑essential. If the provider is unavailable, the fixed question banks, practice tests and all reporting keep working.

11 Infrastructure and sub‑processors

We choose providers that publish enterprise security programmes and independent audit reports — Supabase and its underlying AWS infrastructure, Cloudflare, GitHub and Stripe all hold SOC 2 Type II or equivalent attestations, and Stripe is additionally certified as a PCI DSS Level 1 service provider. We will not add a sub‑processor receiving personal information without updating this policy and the Privacy Policy and giving schools and subscribing parents 30 days' notice.

Stripe was added in version 1.1, when family subscriptions began; it receives no student data. Resend was added in version 1.3, when the Trainers began sending parents a welcome email and password‑reset links. Resend is the first sub‑processor to receive anything about a student — a child's first name, username and year level, in an email addressed to that child's own parent — which is why it is called out here as well as in the Privacy Policy (section 9).

11.1 Data residency

11.2 Payment security

Payment applies only to family subscriptions; school subscriptions are invoiced and involve no card at all.

• PCI DSS scope. Because the card fields are Stripe's and never ours, we fall in the lightest self‑assessment category (SAQ A). We make no claim to be independently PCI certified — that certification is Stripe's, and it is a Level 1 service provider.
• Refunds and cancellations are performed through Stripe, using an account protected by a unique password in a password manager with multi‑factor authentication enabled. Note that this is a place where MFA is in force — §19.2 concerns sign‑in to the Trainers themselves.
• Webhook integrity. Messages from Stripe telling us a payment succeeded or a subscription was cancelled are verified against Stripe's signature before we act on them, so a forged request cannot activate an unpaid account or deactivate a paid one.
• Payment state is not access control on its own. Access is still decided by the authorisation checks in §7 against the account record; a billing event only updates that record.
• The two systems are kept apart. Stripe receives no student name, username, results or writing (§11), and student‑facing systems hold no financial data. A compromise on either side does not hand over the other.

12 Secrets management

• All secrets — each database's service key, each token signing secret, the AI provider key — are held as managed environment configuration in the hosting platform, encrypted at rest there.
• No secret appears in a source repository, in any bundle delivered to browsers, or in any log.
• Deployment pipelines use a scoped access token stored as an encrypted repository secret, masked in all build output.
• Secrets are rotated on device change, on suspected exposure, and on any credible report of compromise. Rotating a token signing secret immediately invalidates every session on that Trainer.
• Provider administrative accounts use unique, randomly generated passwords in a password manager, with multi‑factor authentication enabled wherever the provider supports it.

13 Change management

13.1 Source control

All code lives in private repositories. Every change is attributable to an author and a time, giving a full audit trail of what changed and why.

13.2 Review and release

• Changes are developed on a branch and merged through a pull request, leaving a written record of the change and its rationale.
• Server functions deploy automatically from the main branch through a defined pipeline — no manual uploads, no undocumented production hot‑fixes.
• Database schema changes are versioned migration files kept in the repository, so schema history is reproducible.
• Any change touching authentication, authorisation or personal data gets a deliberate security review before merge.

13.3 Dependencies

Third‑party libraries are pinned to specific versions rather than floating ranges, so a compromised upstream release cannot be pulled in silently. The footprint is intentionally minimal. We watch advisories for what we use and patch on the timeline in §19.5.

14 Logging and monitoring

14.1 What we log

Logs never contain passwords, tokens, secrets or writing responses.

14.2 Monitoring

We review sign‑in failure patterns for credential attacks, AI usage for anomalous volume, and platform error rates for malfunction or probing. Provider alerting notifies the principal of platform incidents.

15 Backup and recovery

• The managed database platform takes automated daily backups with point‑in‑time recovery inside its retention window, for all three Trainers.
• Backups are encrypted at rest and held in the same region as their database.
• Applications and server functions are fully reproducible from source control, so losing a hosting environment is a redeployment, not a rebuild.
• Objectives: RPO 24 hours and RTO 24 hours for total platform failure.
• Restore procedures are tested at least annually.

Because the Trainers are practice tools rather than systems of record, no school's or family's essential records depend on them. We still recommend exporting results at the end of each term.

16 Incident response and breach notification

16.1 Process

1. Detect and triage — assess severity immediately on becoming aware.
2. Contain — rotate affected secrets, invalidate sessions, disable the affected function or account, close the vulnerability. Containment beats investigation.
3. Assess — what information, whose, how exposed, what harm is likely. Target 72 hours.
4. Notify — see 16.2.
5. Remediate — fix the root cause and verify the fix.
6. Review — a written post‑incident review with timeline, root cause and preventive changes, provided to everyone affected: schools, and parents holding a family subscription.

16.2 Notification commitments

16.3 If you suspect an incident

Email hello@r2education.com.au with "SECURITY" in the subject. We aim to acknowledge within one business day, immediately for anything reported as critical. If credentials may be compromised, a school should deactivate the affected accounts straight away rather than wait for us; a parent should email us and we will reset or disable the account the same day.

17 Retention and secure deletion

Full periods are in section 12 of the Privacy Policy. In summary:

• Accounts and practice records are held while the account exists, deleted on the school's or the parent's instruction, or within 90 days of the subscription ending.
• Billing records are the one exception to deletion on request: Australian tax law requires records of a sale to be kept for five years, so an amount, a date and who paid survive a deletion request. Nothing about the student's practice does.
• Deleting a student cascades to every linked record — attempts, sessions, statistics, practice tests, writing submissions, group memberships, access grants — so nothing orphaned is left behind. Enforced by the database schema, not by a cleanup script someone might forget to run.
• NAPLAN Writing responses are never stored in the first place.
• Sign‑in logs are deleted after 12 months, AI usage records after 24.
• Deletion from live systems completes within 30 days of a request; records then age out of encrypted backups as the window rolls forward.
• We provide written confirmation of deletion on request.

18 Reporting a vulnerability

We welcome reports from researchers, teachers, students and anyone else. We will not pursue legal action against someone who reports a vulnerability in good faith under this section.

Please do

• Report privately and give us reasonable time to fix it before going public.
• Include enough detail to reproduce.
• Use only your own test account.

Please do not

• Access, change, download or keep any real student's data. If you encounter student data, stop immediately and tell us what you saw so we can assess it as a potential breach.
• Run denial‑of‑service, load or brute‑force testing against production.
• Use social engineering against us, a school, a teacher or a student.
• Run automated scanning that degrades the service during school hours.

We will keep you posted, fix confirmed issues as fast as we reasonably can, and credit you if you want credit. There is no paid bug bounty.

19 Known limitations

Every security policy should be read alongside what it does not claim. These are our current limitations, so a school or a parent can decide with their eyes open.

19.1 AI marking is processed offshore PARTIAL

All three databases run in Sydney, so stored student information stays in Australia. Writing sent for AI marking still goes to the United States (§11.1). Where an authority cannot accept that, any Trainer can run with AI writing marking switched off — raise it before deployment. Priority: high, on request.

19.2 No multi‑factor authentication OPEN

Sign‑in is username and password only. MFA is impractical for students, many of whom have no personal device — but a teacher or administrator account is a higher‑value target, seeing a whole class or a whole school. Optional MFA for staff accounts is on the roadmap, and a parent account will be offered it on the same release. Until then, schools should ensure staff use strong unique passwords and change them on any suspicion, and parents should do the same on their own account. Priority: high.

This limitation concerns sign‑in to the Trainers. It does not apply to payments: the Stripe account is protected by multi‑factor authentication today (§11.2), and a parent's card details are not reachable from a Trainer account in any case.

19.3 OLNA Trainer security headers incomplete PARTIAL

The homepage, the NAPLAN Trainer and the Scholarship Trainer send a full set including a content security policy; the OLNA Trainer sends three headers and no CSP (§9.1). Levelling it up is a small static‑file change and is the next scheduled security task. Note the inherent limit on both Trainers' policies described in §9.1. Priority: high, near term.

19.4 Server functions accept any origin PARTIAL

The server functions send a permissive cross‑origin policy. This does not grant access to data — every request is still authenticated and authorised server‑side, and a browser on another site cannot obtain a valid token. It does mean endpoints can be called from any origin by a client already holding a valid token. Restricting the allowed origin to our own domains is planned. Priority: medium.

19.5 Patch management is manual PARTIAL

Database and hosting platforms are managed services patched by the provider; application dependencies are updated by hand. Targets: 7 days for critical, 30 days for high, next release for medium and low. Automated dependency scanning is on the roadmap. Priority: medium.

19.6 No independent penetration test OPEN

No Trainer has been penetration tested by an independent third party. Security has been addressed by design (§5, §7) and by internal review, but that is not the same thing. We will commission one as the service grows and share results with schools that need them. Priority: medium.

19.7 Monitoring is periodic PARTIAL

See §14.2. No automated 24/7 alerting on anomalous access, so a slow intrusion could be detected late. Priority: medium.

19.8 Single‑operator concentration risk ACCEPTED

R2 Education is one person. That is good for access control — exactly one human can reach student data — but it means no separation of duties, no peer review of every change, and a single point of failure for incident response. Schools and parents should weigh it. It is inherent to an operation this size, and disclosed rather than engineered away.

One practical consequence for families: account creation, password resets and cancellations by email are handled by one person, so they are same‑ or next‑business‑day, not instant. Cancelling through the billing portal is the exception — that is self‑service and immediate, and it never waits on us (Terms §14.3).

20 Review and assurance

20.1 Review cycle

Reviewed every six months, and additionally after any security incident, significant architectural change, or change of sub‑processor. The version and date at the top always reflect the current version.

20.2 Certifications

R2 Education holds no ISO 27001, SOC 2, IRAP or other formal security certification, and will not imply otherwise. Our platform providers hold independent attestations (§11), but that is assurance over their infrastructure, not over our applications.

20.3 Supporting school assessments

Free of charge, we will:

• complete a school's or department's security or online‑services questionnaire;
• provide additional architectural detail under a confidentiality agreement;
• sign a written data processing or information security agreement;
• accept contractual breach‑notification obligations, including timeframes tighter than §16.2 where a department requires them;
• discuss migrating a school's data to an Australian region (§11.1).

20.4 Questions from parents

A parent subscribing directly has no procurement team to lean on, so ask us instead. We will answer any question in this policy in plain terms, tell you exactly what we hold about your child (Privacy Policy §14.2), and say so if the honest answer is that a control is not in place — section 19 exists for that reason and we would rather point you at it than talk around it.

Contact hello@r2education.com.au.