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.

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

Out of scope: school‑owned devices, networks, identity systems and premises. Endpoint security, network filtering and supervision of students remain the school's responsibility.

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 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

Both 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 and the NAPLAN 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 No self‑registration

There is no public sign‑up on either Trainer. Every account is created by a teacher or administrator, so the attack surface of an open registration flow — automated account creation, enumeration, spam — does not exist.

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, not 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. The per‑username limit is the control that actually stops password guessing.

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.

Schools should tell students to sign out on shared devices — a token left on a classroom machine stays valid until it expires. 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 both Trainers. 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

Both 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 and GitHub all hold SOC 2 Type II or equivalent attestations. We will not add a sub‑processor receiving personal information without updating this policy and the Privacy Policy and giving schools 30 days' notice.

11.1 Data residency

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 both 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 both Trainers are practice tools rather than systems of record, a school's essential records do not depend on them. We still recommend exporting class 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 affected schools.

16.2 Notification commitments

16.3 If a school suspects 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, deactivate the affected accounts yourself straight away — do not wait for us.

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 instruction or within 90 days of the school ceasing to use the Trainer.
• 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 can decide with its eyes open.

19.1 Data is stored offshore OPEN

Singapore for OLNA, Tokyo for NAPLAN, US for AI marking (§11.1). Where an authority requires Australian residency, a database can be migrated to the platform's Sydney region — 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. Until then, schools should ensure staff use strong unique passwords and change them on any suspicion. Priority: high.

19.3 OLNA Trainer security headers incomplete PARTIAL

The homepage and the NAPLAN 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

Neither 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 should weigh it. It is inherent to an operation this size, and disclosed rather than engineered away.

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).

Contact hello@r2education.com.au.