Student data.
Protected at every layer.

All data at rest is stored in AWS Sydney (ap-southeast-2). Writing submissions sent for assessment are processed via Anthropic's API, which may execute outside Australia. For typed submissions no student, class, or school identifiers are included. For scanned submissions (Writeiq Vision add-on), the scanned page is sent to Anthropic along with whatever the student wrote at the top (typically a name, or a student ID if the school prefers). Anthropic's DPA prohibits training on API data and states that data is not retained beyond request processing. Databases, file storage, and all stored school data remain in AWS Sydney.

All data is encrypted at rest using AES-256 managed by AWS. All data in transit uses TLS 1.2 or higher. HTTPS is enforced on every endpoint - no unencrypted connections are accepted at any layer. Database connections use TLS with certificate verification.

Every school's data is isolated at the database layer using Supabase row-level security (RLS). Nine tables are fully locked - no open policies exist. Data isolation is enforced by the database itself, not by application logic alone. No school can access another school's data under any circumstances.

All staff and coordinator PINs are hashed using PBKDF2-SHA-256 with a unique random salt generated per account at the time the PIN is set. Iteration count is 600,000 (OWASP 2023 baseline). Plaintext PINs are never stored, logged, or transmitted after hashing. PIN verification happens server-side in dedicated edge functions — the client never reads stored hashes. Brute-force protection enforces a five-attempt lockout per account, scoped by IP. Session tokens are server-signed JWTs; clients cannot forge or extend them.

Students access Writeiq via class code only - no personal account, no email address, no password is required or collected. Only first name and year level are stored unless the school provides additional identifiers. Student writing submissions are stored per school and are not accessible across schools.

Student submissions, Education Support Specialist records, writing assessment data, and all school data are never used to train any machine learning or AI model - internal or external, including Anthropic models. This is a hard contractual commitment in the Data Processing Agreement, not a policy subject to revision.

All pages are served with HSTS (2 years, includeSubDomains, preload), Content Security Policy, X-Frame-Options (DENY), X-Content-Type-Options (nosniff), Referrer-Policy (strict-origin-when-cross-origin), and Permissions-Policy. These headers are enforced at the CDN layer (Netlify) before requests reach the application.

NCCD data includes student disability categories (QDTP, Supplementary, Substantial, Extensive), specialist assignments, and program records. This constitutes sensitive information under the Privacy Act. Allocateiq treats all NCCD data as sensitive - access is role-based, data is encrypted, and no NCCD data is shared with third parties.

Writeiq is designed for whole-school simultaneous marking. Each school has a dedicated traffic allocation sized to its licence tier, which means one school's peak traffic cannot affect another school's service. In the rare event of an unusual spike — for example, every staff member submitting at the same moment during a large assessment event — requests queue briefly and display a progress indicator rather than failing. No staff action is required; the platform recovers automatically within seconds.

Writeiq scans student writing submissions for content that may indicate the student is at risk. Submissions flagged by safeguarding detection are held for teacher review before feedback is shown to the student. Teachers cannot disable this check.

Students access Writeiq via a class code. No Google account, no email, no personal login is required. This means no Google or Microsoft account data is associated with student submissions. First name only - collected from the student themselves at the point of access.

Disability categories in Allocateiq (QDTP, Supplementary, Substantial, Extensive) are sensitive information under the Privacy Act. Access to NCCD data is role-restricted to coordinator and leader roles. Student NCCD data is not visible to Education Support Specialists in their day-view schedule.

Both products operate on a multi-role model. In Writeiq: student, teacher, leader, and admin roles have separate access scopes. In Allocateiq: coordinator, learning support, and read-only roles are separated. Cross-school data isolation is enforced at the database layer by Supabase row-level security. Intra-school role separation (for example, a teacher not being able to read a coordinator's PIN) is enforced by server-side edge functions that verify PINs with the service-role key — PIN hashes are never returned to the browser.

Authentication sessions are server-signed JWTs with a short expiry (8 hours for staff and LSO sessions, 24 hours for admin panel operators). Tokens are issued fresh on every successful login. Clients store the token but cannot forge or extend it — the signing key lives only on the server. PIN hashes are never returned to the client. Brute-force lockout is enforced server-side at five failed attempts and cannot be cleared by the user.