Trust Center
What's in place.
And what isn't yet.
Districts screen vendors on privacy paperwork before they ever look at the product. This page is the summary your CTO, counsel and purchasing office need — written to be checked, not admired.
What is CCMRI's legal basis for handling student data?
CCMRI operates as a school official with a legitimate educational interest under the FERPA school-official exception (34 CFR §99.31(a)(1)), codified in the Data Processing Agreement. Data is processed only under district direction; the district retains control throughout.
| Area | Posture | Status |
|---|---|---|
| FERPA | School-official exception; data used only for the school-authorised educational purpose; no redisclosure; district retains control. | In place |
| COPPA (under 13) | School-consent exception. K-8 students never receive direct email — a hard-coded grade gate permits direct student email only at grade 9 and above; younger students are reached through parent-directed communication. | In place |
| Texas student privacy TEC §32.151 / §32.157 |
No sale of student data, no targeted advertising, no behavioural profiling, deletion on request. | In place |
| Standard DPA | We have signed the SDPC National Data Privacy Agreement with the Texas exhibit (TX-NDPA) unmodified — no red-lines, so districts execute the instrument they already know. | In place |
| Data we do not collect | No Social Security numbers, no medical or health records beyond the special-education indicator, no biometrics, no photographs, no disciplinary records, no psychological records. | In place |
| Retired credentials | We do not display the Student Privacy Pledge, which the Future of Privacy Forum retired in April 2025. A site still showing it is showing you a dead badge. | N/A |
For Texas districts specifically
TX-NDPA, signed unmodified.
The Texas Student Privacy Alliance — the Texas chapter of the Student Data Privacy Consortium — maintains a common agreement its member districts use for any online application. We adopt it as-is rather than red-lining it, because a modified DPA is what turns a two-week review into a two-month one.
Member districts can leverage another member's executed agreement through the SDPC Resource Registry. If your district is in the Alliance, ask us for our registry status before you start a fresh review.
How is the platform secured?
The control that matters most in multi-tenant K-12 software is tenant isolation — and ours is enforced at the database rules layer, not in application code, so an application bug cannot leak one district's records to another.
Isolation & access
Role-based access across six tiers, enforced in database security rules and verified by an automated test suite that runs on every build. Every query is scoped to the caller's district. A teacher session loads their campus, not the district — which is faster, cheaper, and better data minimisation under FERPA.
Encryption
AES-256 at rest, TLS 1.3 in transit. Hosted on Google Cloud Platform in a United States region.
Audit trail
Every export and every mass view of student data is written to a tamper-resistant audit trail that district administrators can read directly. The record is written server-side, so it cannot be suppressed by a modified client.
Application hardening
Device attestation on all callable endpoints, CORS origin allow-list, timing-safe HMAC-verified webhooks, single-use privileged links, and outbound request validation that pins the resolved IP to prevent server-side request forgery.
Backup & recovery
Managed point-in-time recovery with a 7-day window, plus managed daily backups retained for 30 days. Delete-protection is enabled on the production database, and a restore has been tested and recorded.
Supply chain & scanning
Static analysis blocking on every pull request, dependency and code scanning, secret scanning in CI, and pinned build actions. Findings are triaged weekly.
How does CCMRI use AI, and what does it do with student data?
Texas has not issued state K-12 AI guidance, so we publish our own posture rather than wait to be asked. Cybersecurity, data privacy and generative AI are the top three district technology concerns — this is the section your CTO will read first.
Enterprise inference only
Google Vertex AI on enterprise Google Cloud. No consumer AI tools, no third-party model APIs. Zero data retention is configured on the Vertex project.
No training on student data
Student data is never used to train or fine-tune any model — ours or anyone else's.
De-identified before inference
A deterministic interceptor strips direct identifiers before any payload leaves the trusted environment. Where a per-student plan is generated, the student is represented by a cryptographic hash, not a name or ID. The interceptor fails closed — the request aborts rather than sending raw data.
Human in the loop
No autonomous external sending. Outbound communication is drafted and routed through a human approval gate.
Kill switch & quotas
Per-user AI quotas and an administrative kill switch that disables every AI endpoint at once.
Age-gated assistants
The parent-facing assistant refuses to converse with a self-identified under-13 user, in English and Spanish, and never discusses an individual student's records.
Accessibility
VPAT published, open items included.
The Department of Justice Title II rule makes WCAG 2.1 Level AA the standard for public entities, phasing in from April 2026. We publish a VPAT 2.5 Accessibility Conformance Report against WCAG 2.1 AA and Section 508.
It states "partially supports" where that's the truth, and lists remediation still open. A VPAT that claims blanket conformance is a VPAT nobody checked.
Who are the subprocessors?
The full list, with purposes. Districts are notified before a new subprocessor handling student data is added.
| Subprocessor | Purpose | Student data? |
|---|---|---|
| Google Cloud Platform | Hosting, database, authentication, file storage and Vertex AI inference. United States region. | Yes |
| Resend (on Amazon SES) | Transactional email delivery. | Limited — recipient address and message content only |
| Twilio | SMS delivery, only where a district enables it. | Limited — recipient number and message content only |
| Stripe | Payment processing for district invoicing. | No |
Data sovereignty option: under the Bring-Your-Own-Database deployment, student PII stays on district infrastructure and only pseudonymised metrics reach the cloud.
Security & privacy questions
Is CCMRI SOC 2 certified?
No. CCMRI is control-mapped and audit-ready against SOC 2 Trust Services Criteria but has not completed a Type II audit, and we don't display a badge we haven't earned. If your policy requires a completed Type II report today, treat that as an open item. The control mapping, with evidence for each control, is available for your review — and note that SOC 2 proves security posture, it does not validate FERPA or COPPA.
How does CCMRI comply with FERPA?
FERPA binds districts rather than vendors, so the accurate statement is that CCMRI operates as a school official with a legitimate educational interest under the FERPA school-official exception (34 CFR §99.31(a)(1)). That designation is codified in our Data Processing Agreement. Student data is processed only under district direction and control, is never sold, never used for advertising, and never redisclosed.
Do you use student data to train AI models?
No — never, for any model. We use Google Vertex AI on enterprise Google Cloud rather than consumer AI tools or third-party model APIs, and zero data retention is configured on the Vertex project. A deterministic interceptor removes direct identifiers before any payload leaves the trusted environment, and it fails closed: if scrubbing can't be completed, the request aborts rather than sending raw data.
Where is our data stored, and who else touches it?
Student data is stored on Google Cloud Platform in a United States region. Current subprocessors are Google Cloud Platform for hosting, database, authentication and AI inference; Resend, running on Amazon SES, for transactional email; Twilio for SMS where a district enables it; and Stripe for payment processing, which never receives student data. The full list with purposes is in the vendor security packet.
Can we keep student data on our own infrastructure?
Yes. The Bring-Your-Own-Database deployment has the district run the data gateway on its own infrastructure, so all student personally identifiable information stays there and only pseudonymised metrics reach the cloud for computation. This suits districts whose policy prohibits sending student records to a vendor cloud at all.
Is CCMRI accessible under WCAG and Section 508?
We publish a VPAT 2.5 Accessibility Conformance Report against WCAG 2.1 Level AA and Section 508. It states conformance honestly, including "partially supports" items and open remediation work, rather than claiming blanket conformance. Districts subject to the DOJ Title II rule should review it directly; we refresh it as remediation lands.
What happens to our data if we stop using CCMRI?
On termination your data is deleted on request. The platform includes an automated purge that removes every district-scoped collection containing personally identifiable information, including nested records and stored files, driven from a single canonical list so nothing is missed. Retention schedules run automatically, and records that serve as statutory audit evidence are held to their required retention floor rather than deleted early.
How do we report a security issue?
Email security@txccmri.com. We accept good-faith vulnerability reports and will acknowledge receipt. Please include enough detail to reproduce the issue, and don't access, modify or exfiltrate any student data while testing — report it and we'll verify it ourselves.
Send this to your CTO before we ever meet.
We'd rather your security review start early and find our open items than have it stall a decision later. Ask for the full packet — you don't need to be a prospect to get it.