Security, Privacy and Data Handling

Mark My Words Australia Pty Ltd · ABN 93 662 681 450
Service: app.markmywords.au

This document describes how Mark My Words stores, protects and handles school and student data. It is written for school leaders, business managers and IT staff, and answers the questions schools most often ask before onboarding. It is drawn from our Safer Technologies for Schools (ST4S) assessment responses and supporting control documentation.

1. At a glance

The short answers to the questions schools ask most.

2. What information we collect

We collect the minimum needed to attribute a piece of writing to a student and return feedback to the right teacher.

Required

• Teacher name and email address
• School name
• Student name or pseudonym, class, and year level
• The student writing sample itself (typed, pasted, or uploaded as a photo or scan)

Optional

• Student email address: only required if the student signs in to the platform directly, and only where the school chooses to provide it

Not collected

We do not collect dates of birth, home addresses, demographic information, Aboriginal and Torres Strait Islander status, religion, language background, gender, health or behavioural data, parent or guardian identifiers, or financial information.

Pseudonymity. Schools that prefer not to place real student names on the platform can use pseudonyms. The platform functions normally with pseudonymous student records.

Who holds the information. Student personal information originates with the school, and the school determines the purposes for which it is used on the platform. Mark My Words handles that information to deliver the service to the school and, where the school permits it, for the model improvement described in section 8. We are happy to formalise this allocation of responsibilities in a Data Processing Agreement. Obtaining any consent required from students or families remains the school’s responsibility, and we will provide whatever information you need to support that.

3. Where your data is stored

All Mark My Words school and student data is hosted in the Microsoft Azure Australia East region (Sydney, New South Wales). This covers live application data, databases, uploaded files and backups. Student work, assessment data and school records are not stored or processed outside Australia, and we have no plans to change this.

Two operational tools support product quality and reliability: usage analytics and application error monitoring. These process limited technical and usage data outside Australia. They are listed in section 10, with what each can and cannot see.

Mark My Words operates a cloud-native architecture built entirely on Microsoft Azure platform services. We do not own, operate or maintain physical servers, data centres or on-premise infrastructure. All data stores sit behind private network endpoints with public internet access disabled, so they cannot be reached from the internet even with valid credentials.

Access to production systems. All school and student data is stored and processed in Australia at all times, and is never copied or transferred out of the Australia East region. Access to production systems by Mark My Words personnel is subject to VPN, multi-factor authentication and conditional access, is granted through identity-managed security groups rather than to individuals, and is reviewed monthly and whenever personnel change. Further detail is in section 5.

How the service is delivered

Mark My Words is delivered as a browser-based web application at app.markmywords.au. There is no native mobile application, and no browser extension is required. The full platform runs in the browser with nothing installed on school devices.

4. How student work flows through our AI

Our models are our own, and they run in Australia

Mark My Words runs three AI models, all self-hosted on our own Azure infrastructure in Australia East:

• An assessment evaluator, which produces marking and feedback
• A document parser, which performs handwriting recognition and matches the student name on a submitted document to class records
• An embedding model, used for vector search within the platform

These are open-weight models. The weights are published artefacts that we download once and run entirely on our own infrastructure. We hold no API relationship with any model publisher, there is no network path between our platform and any of them, and no student data is transmitted to any of them at any point.

Student writing is never sent to OpenAI, Google, Anthropic or any other external AI service.

The specific models and versions in use are set out in our technical annex, which is available to IT and procurement teams on request and is included in our Safer Technologies for Schools assessment responses.

Three separated layers

The platform is deliberately structured so that the language model itself never touches the database or a real student name:

• Application server. Handles authentication, role-based access control and the API gateway. This is the only component with database access.
• ML server. Orchestrates processing and performs all anonymisation and data minimisation before anything is passed to the model.
• Language model. Receives only anonymised, minimal data. It has no database connectivity and no access to raw personal information.

End users have no direct access to the ML server or the language model. Before a submission is passed to the assessment and feedback model, the ML server substitutes student names with generic tokens such as [STUDENT_NAME], so that model does not receive a real student name. Personal information linked to the account, such as a student email address, is removed before the document is sent for processing. The model receives the work sample only. The one exception is the document parser, which reads the name written on a submitted page for the sole purpose of matching it to the class list.

What the AI does, and does not, do

The platform exposes four AI functions: annotations, marking, reasoning and feedback. Of these, only feedback generates free-form text; the others classify or structure content that has already been extracted from the submission.

The AI does not:

• Offer chat or any back-and-forth conversation with students
• Remember individual users between sessions
• Browse or search the internet
• Write essays or generate work on a student’s behalf
• Generate images
• Make automated decisions with legal or similarly significant effects without human review

Where the platform uses retrieval to give the model context, it retrieves curriculum standards, learning progressions and rubrics only. No school or student data is included in that retrieval layer.

5. Security of the platform

Encryption and network security

• Encryption in transit and at rest is enforced by default across all services.
• HTTPS with TLS is enforced for all inbound web traffic and all authentication flows. Inbound internet traffic is restricted to HTTPS only.
• TLS is used for internal service-to-service communication as well as external traffic.
• Application secrets and cryptographic keys are held in a dedicated managed key vault inside a private network.
• Databases, file storage and internal messaging are reachable only over private network endpoints. Public network access to these services is disabled.
• A web application firewall enforcing the OWASP Core Rule Set protects the application against injection, cross-site scripting, remote code execution and protocol violation attacks.
• Management ports are not exposed publicly.
• Continuous security posture assessment, threat detection and malware scanning run across the whole environment.

Separation of live and test environments

Production and development run in completely separate networks, with no routing, peering or data transfer between them. Production data is never replicated, restored or copied into development or testing environments. Non-production environments use synthetic, pseudonymised or non-identifiable placeholder data only. Secrets, configuration, logging and audit retention are environment-specific and independent, and changes are validated in non-production before promotion to production.

Access to infrastructure by our staff

• Administrative access to infrastructure is available only over a VPN with multi-factor authentication and conditional access.
• Access is granted through identity-managed security groups, never by direct assignment to individual users.
• Development personnel do not have default administrative access to production systems.
• Access assignments are reviewed monthly and whenever personnel change, supported by an automated report of all role assignments, group memberships and source-control access.

Testing and secure development

• Independent penetration testing, most recently in April 2026. Evidence available on request.
• Automated code, dependency, secret and container scanning runs continuously and on every proposed change.
• Security testing is aligned to the OWASP Testing Guide v4.2.
• Production branches are protected: direct commits are disabled, peer code review is mandatory before merge, and automated test failures block release.
• Releases require user acceptance testing signed off by a nominated stakeholder.
• Role permissions are applied server-side rather than in the browser, and are tested as part of our annual penetration test.

Backups and service continuity

• Databases are backed up automatically with point-in-time restore available.
• Backups remain within Australia.
• Our infrastructure is defined as code. In the event of a major incident or regional outage, the environment can be redeployed clean within one business day, subject to cloud provider availability.
• Restoration is tested annually, covering database point-in-time restoration, infrastructure redeployment from code, and verification that the application works correctly afterwards.

6. Who can access data

How users sign in

Mark My Words is passwordless. We do not store, process or manage user passwords anywhere in the application.

• Single sign-on with Google or Microsoft (OpenID Connect). Password policy, multi-factor authentication and account lockout for these users are enforced by your own identity provider, not by us.
• Or a one-time email link: cryptographically secure, time-limited, delivered to a verified address, validated server-side, and unusable once consumed or expired.
• Students can also submit work by scanning a class QR code without holding an account, where a teacher chooses to run a session that way. The student selects their name from the class list to attribute the submission.

Roles inside the platform

Partner access, where a school has one, is scoped to the specific partner area.

7. AI safety controls

Content is screened before it reaches the AI

All submission text is evaluated by a content safety classifier before any AI function is invoked. This applies whether text was typed, pasted, or extracted from an uploaded document. Anything flagged is blocked from further processing.

Free-form feedback is also checked after generation and before it is returned, for harmful content, inappropriate language, bias and misleading information.

Categories screened include illegal content, child sexual abuse material, image-based abuse, harmful digital communications, inappropriate or offensive content, bias, privacy and personal information, prompt injection, and other objectionable or unlawful material.

What happens when something is detected

• The submission is not passed to the AI, or the output is suppressed and never displayed, stored in a user-accessible location, or transmitted.
• The user sees a clear message that the content could not be processed, with guidance to contact support if they believe it is a mistake.
• The event is logged with a submission identifier, timestamp, safety category and the model version in use. Flagged content is held in a secured log accessible only to a small number of named, authorised Mark My Words staff, and is reviewed solely for investigation and safeguarding purposes.
• Where investigation reveals a genuine welfare concern, for example a submission indicating self-harm or abuse, the school administrator is notified through the appropriate escalation pathway, consistent with child safeguarding obligations.
• Patterns of confirmed detections from a particular user, school or submission type are escalated to the school administrator, giving schools visibility and oversight.

Prompt injection

Prompt injection is the risk that a student embeds instructions in their submission to manipulate the marking (for example, text telling the AI to ignore the rubric and award full marks). We screen for it at the input stage, across rubrics, pasted text and the body of a submission.

The attack surface is deliberately narrow. Users cannot edit the underlying prompt or converse with the model. The only inputs are the work sample, rubric and skill selections. Uploaded files are scanned for malware, and archive files cannot be uploaded.

As a marking result is not released to a student until a teacher has reviewed it, teacher review remains the backstop against a manipulated result reaching a student.

Teachers stay in control

• AI marking must be reviewed by the teacher before it reaches students. This is enforced in the workflow.
• AI-generated feedback is fully editable. Teachers retain authorship of what is communicated to students.
• Annotations are non-binding and can be modified or discarded.
• Teachers can see the exact transcription of handwritten work, and the assessment criteria and rubrics used.
• Every AI feature carries an in-product notice that output may contain errors, bias or inaccuracies.
• No AI output is treated as a final decision, and users are never compelled to accept one.

8. Use of data to improve our models, and how to opt out

No account or profile data is used for training. Where submission data is used to improve our models, it is the student work sample only. Account information, profile data, login history, preferences and usage behaviour are never used as training input.

Before any submission enters the training pipeline, personally identifying information is detected and stripped, then replaced with synthetic equivalents. We recognise that a piece of student writing can itself contain personal detail, so this step operates on the content of the work as well as on the record around it.

The default, and how to change it

Participation is on unless it is switched off. We can disable it for your organisation at provisioning, before any of your data is processed, and we will do that on request as part of onboarding.

• A school or organisation administrator can switch off “use submission data for AI training” in administrative settings at any time. All submissions from that organisation are then excluded from the pipeline.
• Individual users can also opt out in their own account settings.
• An organisation-level opt-out applies to everyone in the school and cannot be overridden by an individual setting. Where both an organisation and an individual have opted out, both are honoured.
• Both settings are reversible, and take effect immediately for future processing. The pipeline checks the opt-out register before processing any submission.
• Where a school system disables this at system level, we apply it across every school in that system at the system administrator’s request.

9. Retention, deletion, export and ownership

How long we keep data

• Data is retained for the duration of the school’s active subscription, plus 12 months. This matches the retention periods set out in our Privacy Policy.
• A school can request earlier deletion at any time, either of specific user, class or organisation records during the agreement, or of all its data once the subscription ends. We act on that request rather than waiting out the retention period.
• Deleting a submission removes the uploaded file from cloud storage and the associated vectors from the ML database.
• Residual copies held in backups expire under our standard backup retention cycle and are never restored to live systems. Written confirmation of deletion is provided on request.
• We do not retain student data for longer than is necessary for the purposes described in this document and our Privacy Policy, or than is required by law.

Getting your data out

• All student work, assessment data and reports can be exported from the platform at no cost, at any time during the agreement.
• Export remains available for 30 days after an agreement ends, so a school is never cut off from its own records at the point of departure.

Who owns what

• Students own their writing. Mark My Words claims no ownership of student writing samples, and does not sell or license them to anyone.
• AI-generated output (marking, feedback and annotations) is owned by Mark My Words under our End User Licence Agreement.

10. Third parties we rely on

The following providers support the service. School and student content is held only by Microsoft Azure, in Australia.

Overseas processing. Microsoft Clarity and Sentry are operational tools that help us keep the platform working properly, and both process data outside Australia. The data they handle is limited to technical and usage telemetry. Student work, assessment data and school records remain in Australia and are not sent to either tool.

11. Incident and breach response

Security incidents are triaged on a severity scale from P0 (critical: actively exploited, or risk of physical harm) through to P3. P0 incidents trigger immediate notification to engineering and IT management, and root cause analysis. The incident response plan is reviewed and formally tested at least annually.

Where a breach affects a school’s data, we will notify that school within 72 hours of becoming aware of it, by email and by telephone, with full details of what happened and what information was affected.

Breach determinations are made by the Chief Executive Officer in coordination with legal counsel, and all external notifications are approved by legal counsel before issue. Notification to affected individuals and to the Office of the Australian Information Commissioner is made in accordance with the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth), our contractual commitments, and any equivalent obligation in another jurisdiction where it applies.

AI-specific incidents

AI incidents are handled under a dedicated process covering bias, harmful content, erroneous output, prompt injection, exposure of personal information, inappropriate content and model misuse. Detection is both automated, through the content classification described in section 7, and user-driven, through in-product reporting adjacent to AI output. Reports can be submitted without identifying the specific submission content, protecting student privacy.

Harmful content, prompt injection, exposure of personal information in output, and model misuse are all treated as critical by default and require immediate action. Containment options include suppressing the output, quarantining the submission, temporarily suspending the affected AI feature, and notifying and correcting for any user who received the content.

12. Compliance and governance

• Privacy Act 1988 (Cth) and the Australian Privacy Principles.
• New Zealand Privacy Act 2020.
• Our practices are also informed by GDPR principles.
• Our infrastructure provider, Microsoft Azure, holds ISO 27001 and SOC 2 certification.
• Safer Technologies for Schools (ST4S): we completed the ST4S Full Assessment in March 2026. The assessment is currently in progress with Education Services Australia, and we will share the outcome with schools when it is published.
• Accessibility: the platform is designed to meet WCAG 2.1 Level AA.
• We hold cyber liability and professional indemnity insurance. Certificates of currency are available on request.

Our staff complete privacy and data protection training within 30 days of commencement and annually thereafter, covering the Privacy Act 1988 and the Australian Privacy Principles as they apply to student data, the Online Safety Act 2021, state education department data and privacy policies, and mandatory data breach notification obligations.

13. Working with your procurement process

We are happy to sign Data Processing Agreements and to complete any security or privacy documentation required by a school, diocese, district or government procurement process.

Where your IT team needs more depth than this document provides, a technical annex covering platform services, network architecture, secure development practices and testing detail is available on request, along with our penetration test attestation and ST4S assessment responses.

14. Our other policies and agreements

This document should be read alongside the following, each of which is published in full on our website.

• Privacy Policy

  How Mark My Words collects, uses, stores and protects personal information for schools, teachers and students.

• Privacy Collection Notice

  How Mark My Words collects and handles your personal information when you sign up for the platform.

• Terms and Conditions

  The terms and conditions governing use of the Mark My Words writing assessment platform and website.

• End User Licence Agreement

  The licence terms for using the platform, including ownership of AI-generated marking, feedback and annotations.

• Acceptable Use Policy

  How the platform may and may not be used by schools, staff and students, including prohibited use, AI feedback responsibilities and how to report misuse.

• Sub-Processor Register

  The third parties Mark My Words engages to process personal information, the data they receive, and where that data is processed.

• AI Model Register

  The AI models used to assess student writing, their versions, what data they receive, where they run, and how we notify schools when a model changes.