Security & Privacy

Student data.
Protected at every layer.

Writeiq is designed to align with the principles of the Australian Framework for Generative AI in Schools. Teacher confirmation, evidence, audit, data-residency and privacy controls are documented for school review - request the assurance pack at hello@edsthetic.com.au.

Edsthetic was built in and for Australian schools. Every security and privacy decision reflects the obligations and expectations of the Australian education sector - from the Privacy Act 1988 (Cth) to the sensitivity of NCCD disability data.

Australian data storage AES-256 encryption Row-level isolation ✅ Privacy Act 1988 (Cth) No model training use Supabase Auth · per-user

Writeiq: at a glance

English writing assessment platform for Years 3–12. Built and operated from Australia.

Marketing · edsthetic.com.au Application · app.writeiq.com.au Hosting · AWS Sydney (ap-southeast-2)

This page is the public security summary for Writeiq, the English writing assessment platform from Edsthetic (ABN 70 939 441 240). It is written to help school IT coordinators and Privacy Officers complete their own Privacy Impact Assessment (PIA) and Safer Technologies for Schools (ST4S) review. The full reference is the Writeiq Security & Privacy Overview v1.7; this page mirrors it. Edsthetic does not complete or sign PIAs on a school’s behalf; the PIA remains the school’s responsibility, and we provide the underlying facts to populate it.

Edsthetic-wide context. Writeiq and Allocateiq (Edsthetic’s separate learning-support allocation platform) run on the same Australian infrastructure, but they are distinct products with separate data. This page describes Writeiq only. Allocateiq: including its handling of NCCD disability data ) is assessed separately and is documented on its own. Where a control below is genuinely shared at the infrastructure layer, it is noted as such.

Architecture overview

Security is the default at every layer of Writeiq. The architecture is designed for the Australian school context: data stays in Australia, every school’s data is isolated from every other school’s at the database layer, and no human or model uses student writing for any purpose other than producing feedback for that school.

Australian data storage

All customer data is stored in Sydney, Australia, on AWS ap-southeast-2, via Supabase (managed PostgreSQL). Data is held in Australia under a data residency commitment and is not replicated, mirrored, or backed up to any non-Australian location. AWS Sydney is ISO/IEC 27001 certified and hosts data for Australian Government, banking, and university workloads.

Encryption at rest and in transit

Data at rest is encrypted with AES-256 (keys protected by FIPS 140-2 compliant HSMs). Data in transit uses TLS 1.2 or higher with modern ciphersuites on every connection: browser, app, and server-to-sub-processor. HTTPS is enforced on every endpoint; no unencrypted connection is accepted at any layer.

Per-school isolation (RLS + SECURITY DEFINER)

Writeiq runs a single PostgreSQL database shared across schools, with each school’s data isolated by PostgreSQL Row-Level Security (RLS) enforced inside the database engine itself, not by application code alone. Every read and write to school data also passes through a SECURITY DEFINER function that re-checks the user’s school against the data’s owner. Two independent controls; no school can ever see another school’s rows.

Cloudflare edge protection

All public traffic routes through Cloudflare, which provides a Web Application Firewall (blocking SQL injection, cross-site scripting and request smuggling), DDoS mitigation at the edge, bot management, and rate limiting on sensitive endpoints (login, password reset). TLS is terminated at the edge and re-encrypted to origin. No school firewall changes are required: Writeiq is reachable on standard HTTPS port 443.

Per-user staff accounts

Every staff member has their own individual account. Staff email/password authentication is handled by Supabase Auth (Edsthetic never stores or sees a staff password), or staff sign in via their school’s Google Workspace or Microsoft 365 Single Sign-On (OAuth 2.0 with PKCE), where the school’s identity provider remains the source of truth and Edsthetic never sees the user’s Google or Microsoft password. TOTP multi-factor authentication is available to all staff and is mandatory for school administrators under the default policy. Historical note: the previous per-school shared-PIN and licence-key model has been retired for staff; staff now use per-user accounts.

Multi-factor authentication (TOTP)

Time-based One-Time Password (TOTP, RFC 6238) MFA is available for staff and works with Google Authenticator, Microsoft Authenticator, Authy, 1Password, and any compliant app. MFA is required for school administrators and optional for teachers at the school’s discretion. Schools using Google or Microsoft SSO automatically inherit any MFA policy enforced by their identity provider. TOTP secrets are stored AES-GCM-encrypted.

Student access: no email required

Students do not need email accounts, passwords, or SSO. Three school-controlled access paths are available: Class Links (recommended: a signed, school- and class-scoped URL or QR code that is itself the credential); Student Access Code (a school-set code typed once per device, rotated by the administrator); and optional Student SSO (opt-in per school for those with Google Workspace for Education or Microsoft Entra ID). The students table holds demographic data only: no password hashes, no TOTP secrets, no auth identity. Students never see other schools’, classes’, or students’ work.

Audit logging

Every sign-in attempt (successful or failed) is logged with timestamp, source IP, user agent, and authentication method. Every administrative action (creating an account, changing a role, removing a user, committing a bulk import) is also logged. The audit log is retained for at least twelve months and can be exported to a school’s IT or compliance team on request.

Backups

Automated daily backups are retained for 30 days, and point-in-time recovery is available for the last 7 days at five-minute granularity. All backups are encrypted with AES-256 and stored in the AWS Sydney region; they are never replicated outside Australia.

Security headers

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. Session cookies are HttpOnly, Secure, SameSite=Strict, and host-scoped to app.writeiq.com.au; JWT session tokens are never written to localStorage or sessionStorage.

Marking and feedback (Amazon Bedrock, Australia)

Writeiq’s marking and feedback are produced by sending student writing to Claude models running on Amazon Bedrock inside the Australian boundary (AWS Sydney / Melbourne). Since 25 July 2026 this processing has been performed in Australia; before that date it ran on the Anthropic API in the United States. It is covered by the AWS Data Processing Addendum, which prohibits the use of customer data to train, improve, or evaluate models, and Anthropic personnel have no access to the inference infrastructure. The scores returned are always presented as a recommendation a teacher can accept, adjust, or reject; Writeiq supports but never replaces teacher professional judgement.

Submission typeWhat is sent for processingWhat is never sent
Typed submissions
(the most common case)
The writing text, the writing type (narrative, persuasive, analytical, recount, etc.), the subject context, and the marking rubric and criteria. In the secondary years the marking call is deliberately year-blind: the year level informs the downstream approved interpretation and feedback register, not the judgement itself. The piece cannot be linked back to an individual student from the API call alone. Student first or last name; student identifier (CASES21 ID, school UID); class name or code; teacher name; school name or identifier; any other student personal information.
Handwritten scans
(honest disclosure)
The scanned page image as captured for transcription. Because students conventionally write their name at the top of paper work, that handwritten name is visible to the transcription service during processing, as it would be to any relief teacher marking a paper stack. The service returns the name as text so the transcript attaches to the right student record; it does not retain the image beyond standard operational processing. For schools wanting stricter control: students can write a school-issued student UID instead of their name (no Writeiq change required), and Edsthetic is trialling automated cropping/redaction of name regions before transmission for Term 3 2026.

The AWS Data Processing Addendum governs this processing. It commits to: no use of customer content to develop or improve models (Amazon Bedrock service terms); no sale or sharing of customer personal data; no use beyond performing the service; Security Incident notification to Edsthetic without undue delay; deletion on termination; AES-256 at rest and TLS 1.2+ in transit; and SOC 2 Type II, ISO/IEC 27001 and IRAP-assessed status for the Sydney region. Prompts and completions are not stored by Bedrock and are not shared with the model provider. AWS Artifact publishes the current certifications; the AWS Trust Center is at aws.amazon.com/compliance.

Historical note. Before 25 July 2026 this processing ran on the Anthropic API in the United States under Anthropic’s commercial DPA (effective 24 February 2025), which carried equivalent no-training, no-retention, encryption, and 48-hour breach-notification terms. Work marked before that date was processed under those terms.

Bulk data operations

For schools migrating existing rosters into Writeiq, the admin panel offers two bulk-import paths: single-file CSV (separate files for classes, staff, and students) and OneRoster 1.2 ZIP bundle (the standard export format used by Compass, Edval, Sentral, Edumate, and most Australian school management systems). The architectural choices below are PIA-relevant.

Files are parsed client-side, never on Edsthetic servers

CSV and OneRoster ZIP files uploaded by school administrators are parsed entirely in the browser using established libraries (PapaParse for CSVs, JSZip for archives). The raw file is never transmitted to Edsthetic’s infrastructure; only the parsed and validated row data crosses the network to the import Postgres functions. So a file containing accidental clipboard contents, hidden columns, or formatting artefacts never reaches the server in raw form, and closing the browser tab before commit discards the entire upload.

No student authentication identities are created during bulk import

Importing student data via CSV or OneRoster populates demographic and class-assignment information only. No auth.users row is created for any imported student, no password is set, and no SSO link is established. Student access remains exclusively via Class Links, Student Access Code, or opt-in SSO.

Two-stage commit with dry-run validation

Every bulk import is a dry-run validation followed by a separate commit. The dry-run returns the full diff (insert / update / unchanged / archive / unarchive) plus per-row errors and warnings, without touching data. Commit proceeds only if there are no errors and the administrator has acknowledged any warnings; replace mode (archiving rows absent from the upload) requires a second confirmation. Every commit is written to the school’s audit log.

Third-party sub-processors

Writeiq uses eight contracted sub-processors, each bound by a written agreement with confidentiality, security, and data-handling obligations. Three (Supabase, Amazon Web Services and Microsoft) process school data directly, and all three do so in Australia; the rest provide edge, email, and operational telemetry only, with no student writing or names in their payloads. Edsthetic notifies schools at least 30 days before any change to this list (published at edsthetic.com.au/legal/sub-processors).

Sub-processorPurposeData processedLocation / certifications
Supabase, Inc. Managed PostgreSQL database, authentication, edge functions, file storage All school data: student records, writing submissions, feedback, staff accounts, configuration Sydney AU (data) · San Francisco (entity) · SOC 2 Type II, ISO 27001 via AWS · DPA with SCCs
Amazon Web Services (Amazon Bedrock) Marking and feedback generation; handwriting transcription. Claude models operated by AWS; no training on customer data. Typed: writing text, type, year level, subject, rubric: no names/IDs/school. Scanned: page image (handwritten name visible during transcription). See the Marking and feedback section above. Australia - Sydney ap-southeast-2 / Melbourne ap-southeast-4 · SOC 2 Type II, ISO/IEC 27001, IRAP · AWS DPA. Anthropic, PBC held this role until 25 July 2026 (United States).
Microsoft Azure AI Document Intelligence Handwriting layout extraction for the optional Vision feature: reads the page and returns lines, words, confidence scores and their positions, so a teacher can check a transcript against the original before anything is marked. It does not produce scores or feedback. Scanned only: the page image, which includes whatever the student wrote at the top. Not used for typed submissions. No names, class codes or school identifiers are sent as metadata. Australia - Azure australiaeast · SOC 2 Type II, ISO/IEC 27001, IRAP · Microsoft Online Services DPA. Residency is enforced in code: a configuration that does not attest Australia East disables the feature rather than sending page images elsewhere.
Cloudflare, Inc. Edge network: WAF, DDoS protection, bot management, TLS termination, rate limiting No stored school data. Inspects request metadata at the edge to filter attacks. Global edge (Sydney POP) · SOC 2 Type II, ISO/IEC 27001
Amazon Web Services (SES) Transactional email delivery (staff invitations, account notifications, report delivery) Recipient email address and message body (invitation claim links, notifications). No submission content; no student PII in message bodies. Edsthetic is the sender; SES is the carrier. AWS ap-southeast-2 (Sydney) · ISO/IEC 27001, SOC 2 Type II · 30-day bounce/complaint retention
Sentry (Functional Software, Inc.) Error monitoring with PII scrubbing Stack traces and sanitised context. Textarea contents, passwords/PINs, and URL query strings are masked or stripped before transmission. No student writing or names. US/EU · SOC 2 Type II
PostHog, Inc. Product usage analytics Event names, timestamps, and aggregated context (role, school identifier). No student writing, names, or feedback. US · SOC 2 Type II · GDPR data processing terms
Netlify, Inc. Static asset and serverless function hosting (marketing site, API edge functions) No stored school data. Static file serving and standard access logs. Global edge · SOC 2 Type II
Stripe, Inc., only when billing is active Payment processing for paid (billed) deployments No stored school, staff, or student data. Billing-contact and payment details only; not used in pilot or unbilled deployments. United States · PCI DSS Level 1, SOC 2 Type II

What we never do

Hard commitments. Not policies.

These are contractual commitments made in the Data Processing Agreement signed with each school, not terms changeable through a policy update.

We neverWhy this matters for schools
Use student data for advertisingNo student profile, behaviour, or writing data is ever used to serve, target, or optimise advertising: for any product, from any company, including Edsthetic.
Train external models on school dataStudent writing and assessment results are never used to train, improve, or evaluate any model. The AWS Bedrock service terms independently prohibit the use of customer content to develop or improve models, and Bedrock does not store prompts or completions; writing sent for analysis is processed transiently inside the Australian boundary.
Sell or share data with third partiesSchool data is not sold, licensed, or shared with any third party for commercial purposes. The eight sub-processors above operate only under binding data processing agreements.
Store credentials in plain textStaff email/password authentication is handled by Supabase Auth; Edsthetic never stores or sees a staff password. TOTP secrets are encrypted with AES-GCM at the application layer, and TOTP recovery codes are hashed with PBKDF2-SHA-256. No credential is stored, logged, or transmitted in plain text.
Store school data outside AustraliaAll stored school data (database, file storage, account records, submissions, backups) is held in AWS Sydney (ap-southeast-2) and never replicated outside Australia. Since 25 July 2026 marking, feedback and scan transcription are also processed in Australia (Amazon Bedrock, Sydney / Melbourne). Remaining offshore processing is limited to operational telemetry (error and usage monitoring), which never carries student writing or names.

Incident response & breach notification

Edsthetic maintains a documented incident response procedure covering detection, containment, investigation, notification, remediation, and post-incident review, integrated with the obligations its sub-processors hold.

Notification chain

Supabase commits to notify Edsthetic of a Security Incident within 48 hours of becoming aware, and AWS without undue delay. Edsthetic, in turn, commits to notify any affected school within 72 hours of confirmation; the 24-hour buffer allows scope to be investigated and accurate information assembled for the school’s response.

Notifiable Data Breaches

For an eligible data breach under the Privacy Act 1988 (Cth), Edsthetic complies with the Notifiable Data Breaches scheme, including notifying the Office of the Australian Information Commissioner (OAIC), and cooperates with any state Department of Education investigation.

Reporting an incident

Suspected incidents should be reported to security@edsthetic.com.au. We acknowledge security reports within four working hours during Australian business hours (next working day otherwise). Full detail is in our Incident Response Plan.

Legislative compliance

ObligationFrameworkHow Edsthetic meets it
Australian Privacy PrinciplesPrivacy Act 1988 (Cth), Schedule 1Compliant with APP 1, 3, 6, 8, 11, 12, 13. Privacy policy at /privacy. DPA available for school sign-off before any paid contract.
Victorian Information Privacy PrinciplesPrivacy and Data Protection Act 2014 (Vic)Data handling designed to satisfy both the APPs and the Victorian IPPs concurrently, meeting the higher standard of the two on every control.
Notifiable Data BreachesPart IIIC, Privacy Act 1988 (Cth)Bound under the scheme. OAIC notified as required; affected schools notified within 72 hours of confirmation.
Cross-border disclosureAPP 8Storage and model processing are both in Australia. Since 25 July 2026 marking, feedback and scan transcription run on Amazon Bedrock within the Australian boundary. Remaining cross-border disclosure is limited to operational telemetry (error and usage monitoring), which carries no student writing or names.
Access & correctionAPP 12 & 13Parents, students, and staff request access/correction through the school; the school administrator fulfils requests directly. Edsthetic assists on request at privacy@edsthetic.com.au.

Security testing & assurance roadmap

Items marked in place are operating now; dated items are scheduled on the published roadmap.

AssuranceWhat it isStatus / target
Internal continuous testingAutomated smoke tests on every deployment (4,000+ checks); pre-deploy build pipeline with secret-scan gate.In place
Real-browser regressionPlaywright-driven Chromium harness exercising real DOM events against the live build (login flow, navigation hiding, security boundary visibility).In place
OWASP ZAP passive scanOWASP ZAP passive manual exploration was completed against the live service. This was not an active penetration test. No High-risk issues were identified. SRI hardening and app-host cookie scoping were confirmed closed on the 24 May 2026 passive re-scan.Completed · school-facing summary available on request; re-run before each commercial deployment
Sub-processor complianceAll seven sub-processors hold SOC 2 Type II certification.In place
ST4S Readiness CheckSelf-assessment submission to Safer Technologies for Schools (Education Services Australia).Term 3 2026 submission
ST4S badgeFull ST4S assessment outcome and badge.Mid-2027 target
External penetration testManual third-party offensive assessment (CREST-certified or equivalent).2027
SOC 2 Type II (Edsthetic)Independent audit of Edsthetic’s own controls (in addition to sub-processor certifications).2028

PIA quick reference

The most-requested Privacy Impact Assessment fields, for fast completion. Full detail is in the Security & Privacy Overview v1.7.

Software nameWriteiq
VendorEdsthetic, ABN 70 939 441 240 (Australia: Federal & Victorian law)
Marketing URLhttps://edsthetic.com.au
Application URLhttps://app.writeiq.com.au
Hosting locationSydney, Australia (AWS ap-southeast-2) via Supabase
EncryptionAES-256 at rest (FIPS 140-2 HSM key management); TLS 1.2+ in transit
Authentication (staff)Per-user accounts. Email + password or Google/Microsoft SSO. TOTP MFA required for admins, optional for teachers.
Authentication (students)No email/password required. Class Links (recommended), Student Access Code, or opt-in Student SSO.
AuthorisationRole-based (Admin / Leader / Teacher / Student) + Row-Level Security + SECURITY DEFINER functions.
Account provisioningPer-user invitations via AWS SES (Sydney); bulk CSV + OneRoster 1.2 ZIP, parsed client-side, never sent to Edsthetic servers in raw form.
Audit loggingAll sign-ins, admin actions, and bulk-import commits. Retained at least 12 months.
Marking processingAmazon Bedrock - Australian boundary (Sydney ap-southeast-2 / Melbourne ap-southeast-4). Claude models on AWS-managed infrastructure; Anthropic personnel have no access to the inference infrastructure. No training on customer data. Typed: writing + rubric only. Scanned: image with handwritten name; UID workflow and Term 3 2026 redaction trial available. Before 25 July 2026 this ran on the Anthropic API in the United States.
Residency enforcementApplies to both model processing (Amazon Bedrock) and handwriting layout extraction (Azure Document Intelligence, pinned to Australia East). Australian processing is enforced in code and by AWS IAM policy, not by configuration alone: the permitted regions are an allow-list, a model without an Australian route is refused, and a request that cannot be served onshore fails and is retried onshore. There is no automatic fallback to an overseas region.
Sub-processorsSupabase, Amazon Web Services (storage, Bedrock model processing, SES), Microsoft (Azure AI Document Intelligence, Australia East, optional Vision feature only), Cloudflare, Sentry, PostHog, Netlify, plus Stripe only when billing is active.
Backups30 days daily backups, encrypted, in Sydney AU; 7-day point-in-time recovery.
Breach notificationAffected schools within 72 hours of confirmation; OAIC under the NDB scheme.
ST4SReadiness Check submission Term 3 2026; badge target mid-2027.
Privacy / PIA contactlegal@edsthetic.com.au
Security incident contactsecurity@edsthetic.com.au

Related documents

Security & Privacy Overview (PIA reference)

The full reference for school privacy and IT teams populating a PIA for Writeiq. Version 1.7, 26 July 2026. Download PDF →

Data deletion policy

Deletion triggers, timelines, and backup retention (30-day backup window, 7-day PITR). Aligned with APP 11.2. Read policy →

Incident response plan

How we detect, contain, and notify on incidents. 72-hour school notification; OAIC under the NDB scheme. Read plan →

Staff security training

A practical guide for administrators, teachers, and support staff. Schools should ensure staff read it before first use. Read training →

Data Processing Agreement

The formal DPA governing processing of school data, signed before any paid contract. Download PDF →

Questions about security?

PIA support, DPA requests, and data deletion: legal@edsthetic.com.au · Security incident reports: security@edsthetic.com.au

Contact privacy team →