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's AI requirements changed in 2026. We publish the provider, model-data inventory, district controls, decision boundaries, retention caveats and open contract items so a district can complete its review without reverse-engineering the product.
Enterprise inference only
Google Cloud Vertex AI; no consumer model key in the browser. In-memory caching is disabled in production and staging. Full zero data retention is not claimed while Google's separate abuse-monitoring exception remains unverified.
No training on student data
CCMRI has not authorized training on district data. Google's terms prohibit model training or fine-tuning on Customer Data without the customer's permission or instruction.
Minimized and pseudonymized
Direct structured student references are pseudonymized and supported SSN, email, phone and student-ID patterns are scrubbed on audited model paths. Academic evidence can remain linkable inside CCMRI; this is pseudonymization, not anonymity.
Human in the loop
No autonomous external sending. Outbound communication is drafted and routed through a human approval gate.
Kill switch & quotas
A global emergency stop, a district master stop and five independent feature controls are enforced on audited district-scoped model endpoints. CCMRI cache retention is district-selected from 30 to 3,650 days (90 days by default), with a daily tenant-scoped purge and district legal-hold control.
Age-gated assistants
The parent guide blocks self-identified users under 13 and never queries student records. Student and public-parent AI default off and fail closed until an authorized district administrator records that district's provider/counsel approval reference; CCMRI does not claim a blanket education exception.
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: the implementation-led hybrid Bring-Your-Own-Database pilot can keep the reviewed roster/evidence collection set in district-managed PostgreSQL. Identity, configuration, audit, engagement, governed workflows, and explicitly enabled server processing remain in CCMRI's U.S. cloud environment.
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?
CCMRI does not authorize training on district data. Google's terms state that Google will not use Customer Data to train or fine-tune models without permission or instruction. We use Vertex AI, minimize feature context, pseudonymize direct structured student references and scrub supported identifier patterns. In-memory caching is disabled in production and staging, but we do not claim full zero data retention while the separate abuse-monitoring exception remains unverified. Current generation uses a supported Gemini successor in Vertex AI's U.S. multi-region; hosted data and the existing embedding index remain in us-central1. CCMRI's own cache defaults to a 90-day district retention period, supports a 30–3,650 day selection, and pauses scheduled deletion when the district records a legal hold.
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?
CCMRI offers an implementation-led hybrid Bring-Your-Own-Database pilot. The reviewed roster/evidence collection set can remain in district-managed PostgreSQL, while Firebase Auth and CCMRI identity, configuration, audit, engagement and governed workflow records remain in CCMRI's U.S. cloud environment. Explicitly enabled server jobs may transiently process gateway rows; this is not represented as a zero-cloud deployment.
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, district-scoped product records are returned or deleted under the executed Data Processing Agreement. The platform includes an automated purge driven from the canonical district-data inventory. The current append-only audit trail has separate retention and may contain limited tenant, actor, IP, or resource identifiers, so its post-termination deletion or de-identification must be expressly defined in the executed agreement.
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.