Security, Privacy and Data Handling

Mark My Words Australia Pty Ltd · ABN 93 662 681 450, contracting directly with US schools and districts
US service: app.us.markmywords.ai

This document describes how Mark My Words stores, protects and handles school and student data for schools in the United States. It is written for district administrators, principals, technology directors and privacy officers, and answers the questions districts most often ask before onboarding. It is drawn from our security control documentation and the responses we provide to district data privacy reviews.

1. At a glance

The short answers to the questions districts 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 or district name
• Student name or pseudonym, class, and grade 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, Social Security numbers, student ID numbers beyond what a school chooses to use as a pseudonym, race or ethnicity, free or reduced-price lunch status, IEP or 504 status, English learner status, immigration status, religion, gender, health or behavioral data, disciplinary records, 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. Education records remain the property of the school or district at all times. Mark My Words handles that information to deliver the service to the school and, where the district permits it, for the model improvement described in section 8, acting as a school official with a legitimate educational interest under the Family Educational Rights and Privacy Act (FERPA), under the direct control of the school with respect to the use and maintenance of education records. We are happy to formalize this allocation of responsibilities in a Data Privacy 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.

Students under 13. Where a school uses the platform with students under 13, we rely on the school’s authority to provide consent on behalf of parents under the Children’s Online Privacy Protection Act (COPPA) for use of the service in the educational context. We collect no more information from students than is reasonably necessary to provide the service, do not use it for any commercial purpose unrelated to the school’s educational purpose, and will provide schools with a description of what is collected so they can share it with parents.

3. Where your data is stored

All Mark My Words school and student data for US customers is hosted in the Microsoft Azure West US region (California). This covers live application data, databases, uploaded files and backups. Student work, assessment data and school records are not stored or processed outside the United States, and we have no plans to change this.

Our US platform runs on dedicated infrastructure that is separate from the infrastructure serving our customers in other countries. Databases are not shared or synchronized across regions, so US student data never travels to Australia or any other region.

Two operational tools support product quality and reliability: usage analytics and application error monitoring. These process limited technical and usage data. 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 centers 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 US school and student data is stored and processed in the United States at all times, and is never copied or transferred out of the West US 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.us.markmywords.ai. 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 the United States

Mark My Words runs three AI models, all self-hosted on our own Azure infrastructure in the West US region:

• An assessment evaluator, which produces grading 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 artifacts 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 technology and procurement teams on request.

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 anonymization and data minimization before anything is passed to the model.
• Language model. Receives only anonymized, 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, grading, 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 state 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, pseudonymized 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 the United States.
• 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, authorized Mark My Words staff, and is reviewed solely for investigation and student safety 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, so the school can act under its own student safety and mandated reporting 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 grading (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 grading 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 grading 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 de-identified student work sample only. Account information, profile data, login history, preferences and usage behavior 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 recognize 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. Training data from US schools remains in the United States. This use of de-identified data to improve an educational product is consistent with state student privacy laws such as California’s SOPIPA and with the SDPC National Data Privacy Agreement, and we disable it wherever a district’s Data Privacy Agreement requires.

The default, and how to change it

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

• A school or district administrator can switch off “use submission data for AI training” in administrative settings at any time. All submissions from that organization are then excluded from the pipeline.
• Individual users can also opt out in their own account settings.
• An organization-level opt-out applies to everyone in the school or district and cannot be overridden by an individual setting. Where both an organization and an individual have opted out, both are honored.
• Both settings are reversible, and take effect immediately for future processing. The pipeline checks the opt-out register before processing any submission.
• Where a district disables this at district level, we apply it across every school in that district at the district 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, unless your Data Privacy Agreement specifies a shorter period.
• A school or district can request earlier deletion at any time, either of specific user, class or organization 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 certification 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.
• Parents and eligible students can exercise their FERPA rights to inspect, review and request correction of education records through their school. We support schools in responding to those requests.

Who owns what

• Students and schools own student writing and education records. Mark My Words claims no ownership of student writing samples, and never sells, rents or licenses them to anyone, or uses them for targeted advertising.
• AI-generated output (grading, feedback and annotations) is owned by Mark My Words under our license agreement, and schools have full rights to use it for their educational purposes.

10. Third parties we rely on

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

Operational telemetry. Microsoft Clarity and Sentry are operational tools that help us keep the platform working properly. The data they handle is limited to technical and usage telemetry. Student work, assessment data and school records remain in Azure West US and are not sent to either tool. A full list of sub-processors, what each receives and where it processes data, is available on request.

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, so the school can meet its own notification obligations to parents, students and state authorities.

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 regulators is made in accordance with applicable state data breach notification laws, FERPA, our contractual commitments including any Data Privacy Agreement signed with your district, 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

• FERPA. We operate as a school official with a legitimate educational interest, under the direct control of the school, and use education records only for the purposes the school authorizes.
• COPPA. For students under 13 we rely on school consent for use in the educational context, collect only what is necessary to provide the service, and never use student information for commercial purposes unrelated to the school.
• PPRA (Protection of Pupil Rights Amendment). The platform collects no survey, attitudinal or protected-category information from students.
• State student privacy laws, including California SOPIPA and AB 1584, New York Education Law §2-d, and equivalent laws in other states. We do not sell student data, use it for targeted advertising, or build profiles of students for any purpose other than the school’s educational purpose.
• Data Privacy Agreements. We sign the Student Data Privacy Consortium (SDPC) National Data Privacy Agreement (NDPA) and state-specific alliance versions, as well as district-authored agreements.
• Our practices are also informed by GDPR principles.
• Our infrastructure provider, Microsoft Azure, holds ISO 27001 and SOC 2 certification.
• Accessibility: the platform is designed to meet WCAG 2.1 Level AA, consistent with ADA and Section 508 expectations. A VPAT is available on request.
• We hold cyber liability and professional indemnity insurance. Certificates of insurance are available on request.

Our staff complete privacy and data protection training within 30 days of commencement and annually thereafter, covering FERPA, COPPA and state student privacy law as they apply to student data, child safety obligations, and data breach notification requirements.

13. Working with your procurement process

We are happy to sign Data Privacy Agreements and to complete any security or privacy documentation required by a school, district, charter network or state procurement process, including vendor security questionnaires such as HECVAT.

Where your technology 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.