FlashEDU Subprocessor and Security Overview
Every third party that processes Student Data on FlashMath's behalf, and the security practices applied to that data. Incorporated by reference into the DPA (Article II.5).
Version 1.3 · Effective 2026-10-19 · Questions: education@flashmath.io
1. Purpose
This overview identifies every third party that processes Student Data, as the FlashEDU Student Data Privacy Agreement defines it, on behalf of FlashMath LLC ("Company"), and describes the security practices Company applies to that data. It is incorporated by reference into that agreement (Article II.5). It does not cover vendors that never receive or process Student Data, such as general business tools with no access to the production environment. Company updates this overview whenever a subprocessor is added, removed or changed, and gives notice as Section 6 describes.
2. Subprocessors
| Subprocessor | Role | Student Data accessed | Data location |
|---|---|---|---|
| LanIT IT Services | Hosting on dedicated, single-tenant infrastructure: the application, PostgreSQL and Redis servers that hold each district's data, and the hosts for edu.flashmath.io and the FlashEDU Console. LanIT also runs the mail relay, the host that receives server logs, the support tracker that receives staff support requests, and the object storage that holds the encrypted off-site copies of each district's database-log archives. | All Student Data at rest and in transit through the Services, including students' problem reports, which stay on the district's own servers for the teacher or district administrators. The support tracker receives only staff requests: the staff member's own name, email address and text, and anonymous student account identifiers, never a student's name; the deletion of a district's data deletes every ticket its staff filed, and does not run while the tracker cannot be reached. Emails carry student information only when an educator requests a classroom digest (student names and accuracy) or a parent summary is sent. Server logs carry account identifiers and IP addresses, with email addresses and secrets removed before they are sent. The off-site storage receives the database-log archives already encrypted, and the key that decrypts them is not kept on the district's servers. | United States (dedicated, self-managed infrastructure) |
| Anthropic | AI model provider for the educator-facing tools (data questions, district and board report narratives, classroom digests, attention explanations, parent summaries), the default provider for roster mapping, an alternate Coach Flash provider, and the model provider for the staff help assistant | For the educator-facing tools, only while the LEA's educator AI setting is on: student names or usernames, school, classroom and teacher names, and performance summaries. For roster mapping, the column headings of the uploaded file and a small sample of its values, with sensitive fields removed. For the staff help assistant, the staff member's question, role, the page they asked from and the LEA's feature settings, with words matching a student name on the staff member's class rosters or in the LEA's roster, username-shaped words, numbers of five or more digits and contact details removed first, and no Student Data records; if a roster cannot be checked, the question is not sent, and Company stores neither the question nor the answer. The help assistant has its own LEA setting, enabled by default and separate from the educator AI setting. | United States (per Anthropic's API data-handling terms) |
| OpenAI | AI model provider for the staff voice assistant (audio streamed directly from the browser), practice-problem generation, and the default Coach Flash provider | Staff voice audio, and the results the voice assistant reads back, which can include student names and results. Practice questions and answers for coaching, only while Coach Flash is enabled. Practice-problem generation sends no Student Data. | United States (per OpenAI's API data-handling terms) |
| (a) Alternate AI provider for practice-content tools and roster mapping, where configured. (b) Google Classroom roster import through the district's own authorization (read-only access to rosters, courses and profile email addresses), where a school connects it. | (a) As for Anthropic, for the same features. (b) Course names, and student given name, family name and email address. The access tokens are stored encrypted. | United States (per Google's terms) | |
| OpenRouter | AI model-routing service, used only where configured as the active AI path; it forwards a request to a downstream model provider | The same data as the request it routes | Determined by the downstream provider (see the note below) |
| Clever | Roster sync and single sign-on, where a district connects it | Student and staff first and last names, grade, school, classes and Clever identifiers, as the district shares them through Clever. A student email address supplied by Clever is used only to match accounts and is kept only in one-way hashed form. | Per Clever's terms and the LEA's own agreement with Clever |
| District identity providers (OpenID Connect or SAML 2.0) | Single sign-on through the district's own identity provider, where the district configures it | The subject identifier, name, email, grade, school and group information the provider sends. Students' names and grades are stored in the district's own database schema, and each student is given a generated sign-in address. | Per the LEA's own identity provider |
| Stripe | Card payments for FlashClass Pro teacher subscriptions and for districts that pay by card | None: billing contacts and payment details only. Stripe never gives Company full card numbers. | United States |
Resend is not a subprocessor. The Services' email code can use Resend, but no environment uses it: all mail goes through the LanIT mail relay above. If Company ever uses it, it will be added here with the notice Section 6 describes.
OpenRouter. OpenRouter can route a request to any of several downstream model providers. The current list of downstream providers is available from education@flashmath.io.
Data residency. Student Data is stored and processed within the United States. It does not leave the United States except, transiently, where an AI subprocessor above processes an enabled feature's request under its US data-handling terms.
3. What Company does not do
- Company does not sell Student Data to any third party.
- Company does not permit any subprocessor to use Student Data for that subprocessor's own advertising.
- Company does not permit AI subprocessors to use Student Data to train or improve their general-purpose models (see the Student Data Privacy Agreement, Article IV.7).
- Company does not embed third-party advertising, analytics, crash-reporting or behavioral-tracking technologies in the Services.
4. Security practices
Company's security program is aligned to the CIS Controls v8 framework. The controls below describe the system as it runs today.
Encryption
- In transit: TLS 1.2 or higher between users' browsers and the Services, including real-time connections, and between the application servers and their PostgreSQL servers. Other traffic between the Services' own servers stays on their private network.
- At rest, storage: each district's PostgreSQL and Redis data are kept on encrypted storage volumes, and a data store is not started on unencrypted storage.
- At rest, fields: sign-in verification secrets, stored student passwords, single sign-on and identity-provider secrets, and staff view PINs are each encrypted individually, in addition to the storage encryption.
- Backups: nightly database dumps, Redis snapshots and local database-log archives are written only to the encrypted data volume. Every production deployment sends copies of its database-log archives off-site, encrypted before they leave the servers.
Access control and authentication
- Role-based access to Student Data: a teacher sees their own classrooms; a school administrator sees their own schools, including only those schools' roster imports, stored student credentials and audit events, without IP addresses; a district administrator sees the district. Classroom and roster data is also protected by database-enforced row-level security, and a deployment is refused unless its application connects as the database role that row-level security binds.
- Least-privilege internal access: Company personnel access to Student Data is limited by role to those with a legitimate operational need. The FlashEDU Console reaches the control plane only through its API and cannot query student records.
- Multi-factor authentication is required for the FlashEDU Console, for the administration surfaces on the district servers (a step-up verification), and for Company personnel's access to infrastructure: SSH access to servers, direct database access, and the secrets manager. A district may require two-step verification for its own staff.
- District sign-in: built today are Clever (roster sync and sign-in), Google Classroom roster import, and per-district single sign-on with OpenID Connect and SAML 2.0. ClassLink and OneRoster are not offered.
Monitoring, audit and response
- Tamper-evident, append-only audit trail of sign-ins and administrative actions affecting Student Data, hash-chained in the database and exportable by the LEA. Its contents and retention are stated in Article VI.C.3(a) of the Student Data Privacy Agreement: it keeps account identifiers, IP addresses and the text of administrative actions, which may include names, and it has no scheduled deletion date.
- Security and access logging: server logs are sent to the log host LanIT IT Services runs, with email addresses and secrets removed first. They are kept for 90 days, encrypted at rest, to support incident investigation.
- Breach notification to the LEA without unreasonable delay, as Article VI.B of the Student Data Privacy Agreement provides (and the New York Education Law § 2-d rider where it applies).
Development and data architecture
- Vulnerability management: static application security testing and mandatory code review gate every release; dependency and container-image scanning are being added to the release pipeline.
- Tenant and data segregation: game data and application data are held in separate database systems, and each district's most sensitive data (student legal names, IEP/504 accommodation flags, the district's copy of the audit trail) lives in its own per-district database schema, a stronger boundary than row-level filtering alone. The flags themselves stay there; when the untimed or extended-time flag applies to a practice round, the shared practice record keeps only that round's settings (its length, or its number of questions), which can show that a time accommodation applied. A request whose district cannot be resolved is refused rather than served from a shared schema.
5. Data deletion and retention
As Article VI.C and Exhibit C of the Student Data Privacy Agreement provide, Student Data is deleted or de-identified within 90 days of the termination of the Service Agreement, or of the LEA's request (for individual students or the whole LEA), whichever is earlier. A Service Agreement that expires without being renewed, including a pilot that ends without a paid agreement, or whose paid service lapses, is terminated 30 days later unless it has been renewed by then. For a request a district administrator makes in the Services, the 90 days run from when it is made; for a written request sent to Company, they run from Company's confirmation of that request. Confirming a written request to delete the whole LEA ends the Services, including data export, at that moment.
A termination starts an automated deletion clock. Unless the LEA instructs a hold, the deletion then runs on its own across the district's own schema, its application database, its game database and its Redis data. It is fully audited, completes within the 90 days, and produces a deletion certificate for the LEA.
The exceptions are data Company is legally required to retain, the audit trail (Section 4), and backups. Backup copies are encrypted and are not altered when Student Data is deleted; they expire on their own schedule. Nightly backups kept on the servers that host the LEA's data are deleted within 16 days, database-log archives there are deleted 14 days after they are copied off-site, and the encrypted off-site copies are deleted once they are more than 90 days old — so every backup copy made before a deletion is gone within 91 days of it. The deletion certificate Company issues when the LEA's Student Data is deleted states the dates.
6. Notification of subprocessor changes
Company will give LEAs with an active FlashEDU Service Agreement notice at least 30 days before adding a new subprocessor with access to Student Data, by updating this overview and by direct notice to the LEA's designated administrator, and will offer the LEA an opportunity to object on reasonable data-protection grounds, consistent with the Student Data Privacy Agreement.
7. Compliance posture
- Regulatory: the Services are operated consistent with FERPA and COPPA, and the Student Data Privacy Agreement carries the state-specific terms the contracting LEA's home state requires (for example, New York Education Law § 2-d and Part 121).
- Framework: the security program is aligned to CIS Controls v8.
- Independent attestations: none is available today. A third-party penetration test and a SOC 2 examination are planned; their timing follows district requirements.
8. Requesting more security information
A district that needs a more detailed review — a security questionnaire such as HECVAT or SIG, architecture and data-flow diagrams, or the current OpenRouter downstream-provider list — can write to education@flashmath.io. Some of these require a signed non-disclosure agreement before Company shares architectural detail beyond this overview.
Change Log
Version 1.3 is the first version published in this library; earlier versions were sent on request. It adds that LanIT IT Services runs the host that receives server logs, and that those logs are kept for 90 days, encrypted at rest; that multi-factor authentication is required for Company personnel's access to servers, databases and the secrets manager; and that every production deployment sends its encrypted database-log backups off-site. It removes Google Fonts, which the Services no longer use: the typefaces in the student locker and shop are served from FlashEDU's own servers. It also describes deletion after an agreement ends as version 1.5 of the Student Data Privacy Agreement does.