Written to be checked.

Four fields, plus reading activity: name, school email, year level, and what they save, finish, and rate. All of it comes from the school roster or the student’s own use of the app.

Not collected: date of birth, home address, phone number, photographs, health information, government identifiers, location data, or any free text written by a student. There is nowhere in the product for a student to type free text at all.

• No contact surface. No messaging, chat, comments, forums, or profiles. There is no channel through which a student can be contacted inside WellRead, so the primary online-harm vectors have no surface to occur on.
• Age gating on the server.Every book sits in an age tier; a student’s tier comes from their year level on their authenticated session, resolved server-side. Editing a URL cannot reach older content. Signed-out requests default to the most restrictive tier.
• Identity-safe peer signals.The only student feedback is a thumbs up or down. Peer favourites are aggregate counts within the student’s own school and tier, suppressed until at least five ratings exist.

Student and staff records are stored in Australia: a Postgres database operated by Neon on AWS Sydney infrastructure, encrypted at rest. The application is delivered by Netlify’s edge network; the book catalogue is a separate database holding no personal information. The full sub-processor table, including the two Google services used for book metadata only, is in the privacy policy; the draft Data Processing Agreement is part of the due diligence pack below.

There is no analytics, advertising, or telemetry anywhere in the product children use, and no third-party requests from either site: fonts and assets are served from our own domain.

Application-layer hardening and privilege separation are strong: passwords hashed with scrypt, cryptographically signed sessions with server-side revocation, single-use sign-in links that expire in 15 minutes, rate limiting, enforced Content Security Policy, five role tiers guarded server-side on every administrative API, and a persistent audit log.

The outstanding gap is multi-factor authentication for school users. It arrives with school single sign-on (Entra ID, Google), so your own MFA policy will apply. We say this up front because you will find it anyway, and we would rather show you the plan.

• In. The school imports staff, students, and classes by CSV. Every import writes an audit row.
• Through. Students read and rate; teachers see their own classes; librarians see the school.
• End of year. One transactional promote / graduate / archive flow, guarded against double-runs.
• Out. A school admin can export everything the school holds, in one file, at any time, without asking us. Departed students are anonymised in place after a 365-day window (configurable): name and email replaced, credentials deleted, aggregate signals retained.

• School-user MFA and SSO: on the roadmap, not shipped (see above).
• Temporary-password CSVs from provisioning need documented handling and expiry on the school side; we are building expiry in.
• Our patch cadence and backup-restore practice exist but their formal documentation is in progress; the Essential Eight self-assessment provided to schools states this.
• A third-party WCAG audit has not been commissioned yet; the accessibility conformance above is based on internal testing. Screen-reader passes are ongoing, and a dyslexia-friendly reading mode is on the roadmap.

On request we provide: the draft Data Processing Agreement (as a signable document), the current sub-processor list, the security overview, and our ACSC Essential Eight self-assessment with gaps stated. We respond to standard sector questionnaires. Security researchers: see security.txt.

info@wellreadreader.com