Security at Classroom Insight

Last updated: July 13, 2026

Classroom Insight exists to hold some of the most sensitive information a school manages: how students are doing, what happened, and what the adults around them are doing about it. This page explains, specifically, how we protect it. If your district's vetting process needs something you don't see here, email [email protected] — you'll reach the team directly.

1. What data Classroom Insight stores

Schools and their authorized staff decide what to enter. Depending on use, this includes student roster information (name, ID, grade level, class enrollment), daily behavior check-ins, incident reports and their resolution history, student case files and support plans, draft behavior goals, and logs of family contact. Optional student metadata — such as IEP/504 status or English-learner status — can be recorded to give educators context.

We store only what schools provide. Students do not have accounts, and we never collect information directly from students.

2. How student data is protected

Every school's data is isolated at the data layer — not just the interface. Each record is tagged to its school and district, and our application enforces that scope on every database query and write automatically: a request scoped to one school cannot read another school's records, and any attempt to write data outside the user's authorized scope is rejected by the data layer itself. This isolation is covered by automated regression tests that run with every change, proving cross-tenant queries return nothing.

Role-based access controls. Each staff member sees only what their role allows: teachers see their own classes, school administrators see their school, district administrators see their district. Access is checked on every request against the user's assigned roles and schools.

Encryption. All traffic is encrypted in transit with TLS, enforced by HTTP Strict Transport Security (two-year policy, preload). Data is encrypted at rest by Google Cloud SQL using AES-256.

Account security. Passwords are stored only as salted, industry-standard one-way hashes — we cannot see them. Users can authenticate with a password or optional Google Sign-In. Sign-in requires a verified email address, and login, registration, and password-reset endpoints are rate-limited to block brute-force attempts. Sessions use secure, HTTP-only cookies, have an absolute eight-hour lifetime (including "remember me"), and are revoked when a password, email, role, or access assignment changes or an account is deactivated.

Application hardening. The application ships with defense-in-depth protections: CSRF protection on all forms, a Content Security Policy, clickjacking denial (X-Frame-Options), MIME-sniffing protection, restrictive referrer and permissions policies, and per-endpoint rate limits on sensitive operations. The application runs as a non-root user in its container.

3. Where data lives

Classroom Insight runs on Google Cloud (Cloud Run and Cloud SQL PostgreSQL) in the United States. Student data is stored and processed only in the United States. Automated daily database backups are retained on a rolling 7-day cycle.

4. AI features and student data

Classroom Insight's AI features help educators draft summaries, support ideas, family messages, and behavior goals. Because this is the section district reviewers read first, here is exactly how it works:

• Provider. AI features are powered by Google's Gemini models, running on the same Google Cloud infrastructure that hosts the rest of the application.
• What is sent. When an educator uses an AI feature, the request includes the relevant behavior notes, the student's name, and instructional context the school has recorded — grade level, English-learner status, IEP/504 status, and disability category — so the draft is genuinely usable. Race, ethnicity, and gender are excluded from AI processing by design, and custom student fields are excluded unless a school explicitly marks them as AI-shareable.
• No training on student data. Student data is not used to train AI models — ours or Google's.
• Retention. Data sent for AI processing is used to generate the requested output and retained by Google only for 55 days for the purposes of detecting and preventing abuse. We do not store separate copies of prompts outside your school's records.
• Drafts, not decisions. Every AI output is a draft. Nothing is sent to a family, entered into a student's record, or acted on automatically — an educator reviews, edits, and approves first. We do not use AI to make decisions about students.

5. FERPA: our role

Where student data includes education records protected by FERPA, Classroom Insight operates as a "school official" with a legitimate educational interest under 34 C.F.R. § 99.31(a)(1): we perform a service the school would otherwise perform with its own staff, we remain under the school's direct control with respect to the use and maintenance of education records, we use records only to provide the service, and we do not re-disclose them except as the school directs or the law permits. Education records remain the property of, and under the control of, the school at all times. Parents and eligible students exercise their FERPA rights through their school, and we help schools respond — see Section 7.

6. Data ownership, export, and deletion

Your district owns its data.

• Export. Schools can export a complete, FERPA-oriented record set for any student at any time — a structured archive of CSV files covering roster details, behavior entries, incidents and their history, support plans, and family-contact records. Full-school exports are available on request at any time, including at the end of a pilot.
• Deletion. Authorized staff can permanently delete a student and all associated records directly in the product. When a school or district leaves Classroom Insight — including at the end of a free pilot — the school has 30 days to request an export, after which we delete the school's Student Data from our systems within 60 days and confirm deletion in writing on request. Backups containing deleted data age out on our rolling backup cycle.

7. Accountability

• Audit records. Authentication events, password and email changes, administrative mutations, FERPA exports, student-record access, permanent student deletions, and AI invocations are written to append-only security records. Records contain user, student, school, and source-IP identifiers where applicable, but never student names, notes, prompts, generated content, passwords, or tokens. Security events are retained for at least one year.
• Offboarding. When a staff member leaves, a single offboarding action removes their memberships and class assignments, cancels pending invitations, and captures the sequence in the audit log.
• Testing. The codebase ships with an automated test suite — including dedicated regression tests proving cross-school and cross-district data isolation — plus dependency, secret, and container vulnerability scans. These checks must pass before the deployment stage runs.

8. Subprocessors

Each subprocessor is bound by terms restricting use of data to providing services to us. We'll update this table if it changes and, for districts with a signed DPA, give notice as the DPA requires.

9. Data privacy agreements

We're glad to sign your district's data privacy agreement, and we're familiar with the Student Data Privacy Consortium's National Data Privacy Agreement (NDPA). California districts: we will work through your Ed. Code § 49073.1 requirements as part of the DPA process.

10. Reporting a security concern

If you believe you've found a vulnerability, email [email protected]. You'll reach the team directly, we'll acknowledge within 2 business days, and we won't pursue action against good-faith research conducted without harming student data.

Questions your team needs answered that aren't here? Email [email protected] and we'll add them to this page.