Measuring MasteryMeasuring Mastery

Trust & Compliance Documentation

How Measuring Mastery protects student education records

A plain description of the technical and administrative safeguards built into the platform, organized around FERPA's core protections — for the districts, principals, and teachers who ask us how their students' data is handled.

FERPA Compliance Statement

FERPA obligations belong to the school or district as the legal custodian of education records. Measuring Mastery operates as a school official with a legitimate educational interest under your written agreement with us — meaning we are held to the same restrictions on using and re-disclosing student data as the school itself. We do not sell, rent, or use student data for advertising, under any circumstance.

This page describes safeguards we have built and verified in our own systems. It is not a substitute for your district's own FERPA policy, and it is not a legal certification — there is no official "FERPA-certified" seal; compliance is a shared responsibility. We're glad to support your counsel's review with a signed data processing agreement and security questionnaire — see Requesting documentation.

Information Security Policy

Sections 01–04 below make up our Information Security Policy: access control, database-layer isolation, encryption, and audit logging.

01

Access control & least privilege

Every account only ever sees the data its role requires — enforced on the server for every request, not just hidden in the interface.

Five separate, role-scoped portals

Teacher, admin, case manager, student, and district-operator experiences are fully separate applications under the hood, each gated by server-verified role checks — not client-side flags a browser could spoof.

Implemented

Sessions re-verified on every request

API routes call Supabase Auth's live session check on each request rather than trusting a cookie's contents, so a tampered or expired session is rejected server-side.

Implemented

Platform-operator access is walled off from academic records

Our own internal administrative accounts are technically restricted from ever viewing assessment results, grades, mastery data, behavior records, or accommodations — access is limited to account and roster administration.

Implemented

Workspace and school-level isolation

A teacher's classes, and a school's students, are scoped by workspace ownership checks re-verified on every read and write — a district's data cannot be queried from outside its own workspace.

Implemented

Multi-factor authentication for staff

TOTP-based MFA (authenticator app) is built on Supabase Auth's native two-factor system for teacher, admin, and district-operator accounts.

Available — district-configurable
02

Data isolation, database layer

Access control isn't only enforced in application code — the database itself refuses to hand back rows the requester isn't entitled to.

Row-level security on every table

100% of database tables have row-level security enabled — independently confirmed via an automated database security scan, with zero exceptions found.

Implemented

No direct path to sensitive records

Tables holding academic and behavioral records (student_standard_mastery, accommodations, behavior_incidents, and similar) have no policy granting a browser session direct access — they are reachable only through authenticated server routes that apply their own authorization logic.

Implemented

Ownership-scoped policies where direct access exists

Where students, teachers, or parents do read data directly (their own attempts, enrollments, or profile), policies check identity ownership on every row, e.g. a student only ever sees rows tied to their own account.

Implemented
03

Encryption

Standard, verified transport and storage encryption across the platform.

Encrypted in transit

All traffic is served over HTTPS with HTTP Strict Transport Security enforced (2-year max-age), confirmed against the live production response headers.

Implemented

Encrypted at rest

The production database and file storage are encrypted at rest (AES-256) by our infrastructure providers as a default, non-optional setting.

Implemented
04

Audit logging

Sensitive actions are recorded with who, what, and when — separately from the records they touch, so they can't be quietly edited away.

Dedicated audit trails across sensitive workflows

Separate, append-only logs track MFA changes, single sign-on activity, behavior incident edits, parent-communication messages, class archival, billing changes, and integration syncs.

Implemented

Continuously reviewed

As part of this review, one audit-logging gap was found (a class-management action whose log table had not been provisioned) and was corrected the same day.

Implemented
05

AI Data Usage Policy

Generative AI features (the student study assistant, parent-message drafting, standards alignment) are the highest-scrutiny area of any modern ed-tech platform. Here is exactly what leaves our servers, and where it goes.

Business API, not the consumer chatbot

AI features call OpenAI's developer API under its API business terms, which by default do not use submitted data to train models — a materially different posture than the consumer ChatGPT product.

Implemented

Minimized student identity in prompts

Where a student's own name is needed for a parent-facing message, only the specific fields required for that message are included; the student-facing assistant is given a first name only.

Implemented

No use of student data to train models

Neither Measuring Mastery nor its AI vendor use student prompts, responses, or academic records to train or fine-tune AI models.

Implemented

Billing is fully separated from academic data

Our payment processor receives a staff member's billing contact information only — never a student's name, records, or identifiers, verified by inspecting every field sent to it.

Implemented

Signed data processing agreements with AI and email vendors

Formal written agreements governing data use, retention, and confidentiality with our AI and messaging vendors are maintained outside this codebase — confirm current status with your account team.

Confirm on request
06

Data Retention & Deletion Policy

What happens to a student's data when an account is no longer active, and how to request deletion.

Official education records are never deleted, only archived

Once a student has assessment or mastery history, their records are archived rather than destroyed — preserving the integrity of official education records in line with standard school record-retention practice.

Implemented

Clean removal for accounts with no academic history

An account with no linked assessments, grades, or class history can be fully and permanently deleted on request.

Implemented

Reversible class and roster archival

Teachers can archive a class or roster without erasing any historical results underneath it.

Implemented

District-directed deletion at contract end

When a district's agreement with Measuring Mastery ends, a district administrator may request export and/or deletion of that district's student records; the specific timeline is set in the district's signed agreement.

Set by district agreement
07

Subprocessor List

Every third-party service that stores or processes education-record data on our behalf. We do not sell or share this data with anyone outside this list, and never for advertising.

Supabase (database & core infrastructure) — AWS us-west-2, Oregon, USA

System of record for all student, teacher, and district data — accounts, enrollments, assessments, mastery records, accommodations, and goals.

Core infrastructure

OpenAI (AI-assisted features)

Processes student-authored text (e.g. a short answer, a chat message) only when an AI feature is actively used — question generation/rewriting, standards matching, reteach suggestions, the student study assistant, and AI-assisted parent messaging.

AI processing

Stripe (payment processing)

Handles teacher and school billing only. Never receives student names, records, or identifiers.

Billing only

Resend (transactional email)

Delivers account, password-reset, and parent-communication emails, which may include a student's first name and class context.

Email delivery

Google APIs (optional integrations)

Google Classroom roster sync and Google single sign-on, active only for schools and teachers who choose to connect them; also used for optional lesson-plan export to Google Slides.

Opt-in only

Vercel (application hosting)

Runs and serves the Measuring Mastery application itself.

App hosting
08

Incident Response Plan

A high-level summary of how we respond to a suspected security incident. This is a public summary, not our full internal runbook — specific notification timelines are set in each district's signed Data Processing Agreement, not asserted here.

Detection & internal escalation

Audit logging (see Information Security Policy, section 04) and infrastructure-provider alerting are used to detect anomalous access. A suspected incident is escalated internally immediately upon detection.

Program in place

Containment & investigation

Access is restricted or revoked as needed to contain a suspected incident, followed by an investigation to determine scope and whether education records were affected.

Program in place

District notification

Affected districts are notified after a confirmed incident involving their education records, with the notification timeline and required content governed by that district's signed Data Processing Agreement.

Timeline set by district agreement

Post-incident review

Confirmed incidents are followed by a review to identify and close the underlying gap.

Program in place
09

Parent & eligible-student access rights

FERPA gives parents (and students who have turned 18) the right to inspect their own education records. That's a built-in feature, not a manual request process.

Self-service parent portal

Parents can review their own child's mastery growth, attendance, and awards directly, without needing to email the school for a report.

Implemented

Verified guardian relationships, checked per request

Every parent-portal request is checked against confirmed guardian-student links at the server — not just hidden by the interface — so a parent can never view a student they aren't linked to.

Implemented

Direct channel to request a correction

Parents can message a teacher or case manager directly to ask questions about or dispute a record; a dedicated, separately logged amendment-request workflow is planned.

Available via messaging

Privacy Policy

Our full Privacy Policy — covering what personal information we collect across the site, how it's used, and your rights — is a separate document. Read the Privacy Policy.

Requesting documentation

  • Ask your Measuring Mastery account contact for our current security questionnaire and a signed Data Processing Agreement.
  • District counsel is welcome to request a walkthrough of any safeguard on this page before signing.
  • This page reflects a technical review completed July 31, 2026, and is updated as the platform changes.
Measuring Mastery — Student Data Privacy Practicesv1.1 · August 3, 2026