Security without unsupported badges
Know what protects school data and what still requires review.
This page describes implemented safeguards, data handling, retention controls, incident responsibilities, and the evidence a school should request. It does not turn privacy laws or security frameworks into marketing certifications.
Implemented controls
Security boundaries a school can test.
ControlCurrent implementationHow to validate
Role and tenant authorizationRoutes check the signed-in role, school, district, assigned class, and enrolled student before returning protected records or accepting an action.Use separate test roles and intentionally request records outside each scope.
Plan authorizationEntitlements are checked by the service as well as reflected in the interface.Call an excluded feature endpoint and confirm an explicit denial.
Password storagePasswords are stored as salted scrypt-derived hashes, not reversible plaintext.Review current configuration and credential-reset procedures under agreement.
Secret comparisonCredential hashes and signed values use timing-safe comparison where applicable.Include authentication and token tests in the technical review.
Stored integration and deployment tokensSensitive stored service tokens use authenticated AES-256-GCM encryption.Review key management and rotation details during security review.
Browser sessionsSigned sessions expire and use HTTP-only, SameSite cookies; secure cookies are used on the public HTTPS service.Inspect cookie attributes, expiration, logout, and invalidation behavior.
Response hardeningResponses disable content-type sniffing, deny framing, restrict browser permissions, and use a strict-origin referrer policy.Inspect public and authenticated response headers.
Screen authorizationA class-scoped active-view lease controls capture targeting. Teacher access is checked before screen records are returned.Test start, renew, expiry, cross-class denial, and inactive-view behavior.
AuditabilitySafety actions, category approvals, command acknowledgements, billing changes, and selected administrative changes retain attributable records.Perform controlled changes and reconcile the resulting histories.
Service monitoringComponent checks, response measurements, incidents, and public updates are exposed through the status service.Compare the public status record with pilot observations.
Data lifecycle and retention
Capture, access, retention, and deletion are different decisions.
Retention values below describe current application controls. A signed agreement and school configuration may impose additional requirements.
Only for enabled school features and managed activity.
Limit records and actions by role, school, district, class, and plan.
Apply policy, show classroom context, produce reports, or support human review.
Apply automatic cleanup, school action, and contractual requirements.
DataCurrent behaviorSchool control
Live screen framesIntended to be ephemeral during active authorized viewing and not recovered as a recording.Stop viewing or let the active-view lease expire.
Explicit screen recordingsDefault application retention is 30 days; configurable from 1 to 90 days, followed by scheduled deletion.School retention setting and explicit recording enablement.
Raw activityDefault application retention is 90 days; configurable from 1 to 365 days for the school.School retention setting and signed requirements.
Unflagged Google Docs notice capturesScheduled cleanup removes unflagged captures after three days.The school can disable the underlying feature and request applicable deletion.
Temporary access recordsExpired or revoked credentials and grants are cleaned after the school's raw-activity retention window.Staff can revoke active credentials or grants immediately.
School records, reports, and review historyRetained for service, security, contractual, dispute, and legal needs; deletion is coordinated with the school.Request export or deletion subject to backups, security, contract, and law.
FERPA, COPPA, and school obligations
Compliance is a shared operating model, not a logo.
Classroom Guardian does not publish a blanket legal certification. The school should review the product, privacy policy, configuration, and signed data terms against its own obligations.
School-controlled education records
The service is designed for school-authorized educational use with role-scoped access, school and district boundaries, access and export workflows, and school-directed deletion review.
- Confirm the school's legal basis and school-official criteria
- Define legitimate educational interest and authorized roles
- Review the signed data agreement, retention, redisclosure, and record-request process
Notice, consent, and limited use
The public privacy policy states that student information is not used for targeted advertising and is not sold for advertising or data-broker purposes. Schools control participating accounts and features.
- Determine whether school authorization or parent consent applies
- Provide required notices and limit collection to approved educational purposes
- Review access, deletion, operator contact, and feature configuration
Filtering supports a school program
Managed Chrome and Edge filtering, Safe YouTube, categories, custom policy, activity evidence, and human review can support a school's internet-safety program.
- The school remains responsible for its policy and required measures
- Test both overblocking and missed content
- Do not treat software purchase as automatic compliance
Procurement note: Ask for the current data agreement, subprocessor information, security answers, breach-notification terms, deletion obligations, and any required state-specific student-privacy terms before production use.
Incident response
A visible process from detection to follow-up.
- 1Detect and triage
Use service monitoring, errors, school reports, request identifiers, audit records, and component health to identify scope and severity.
- 2Contain
Pause affected rollout paths, revoke or rotate credentials, restrict access, or isolate a failing component while preserving evidence.
- 3Recover
Restore healthy service, verify policy, command, event, and screen behavior, and monitor for recurrence.
- 4Communicate
Publish service incidents where appropriate and follow applicable law and signed notification commitments for verified data incidents.
- 5Review
Document cause, impact, corrective actions, evidence preservation, and follow-up ownership.
Assurance limits
Evidence still required before production.
No SOC 2 or equivalent certification is currently claimed on the public site.
No current independent penetration-test report is published for unrestricted public download.
No general public uptime or response-time guarantee should be assumed.
No independently validated large-district deployment or concurrency benchmark is publicly claimed.
Last reviewed July 30, 2026. Public documentation supports an initial review but does not replace a signed agreement, school legal review, or technical pilot.