Security & privacy for threat assessment records: Built for the most sensitive records a school keeps.
Threat assessment files contain interviews, family circumstances, and a team's judgments about a child. VeriThreat is designed around least privilege, data minimization, and a complete record of who accessed what.
Least privilege
Everyone sees exactly what their role requires.
Access is enforced on the server for every page, action, and file download. Hiding a button is never the security boundary.
| Role | Can access | Cannot access |
|---|---|---|
| Staff & teachers | Submit reports; see status of their own reports | Cases, notes, other reports, other schools' students |
| BTAM member | Reports, cases, notes, assessments for their school(s) | Finalizing assessments; closing cases |
| BTAM lead | Everything a member can, plus finalize, close, reopen | Schools outside their scope |
| District admin | Users, schools, roster sync, audit log | Any student, report, or case record |
| VeriThreat staff | Account setup and support; usage counts (schools, users, reports) | Any student, report, case, note, or attachment |
Every district is its own separate account. Within it, team members can be scoped to a single school or work district-wide.
Isolation & hosting
Your district's records stay yours.
Threat assessment data shouldn't be one misconfiguration away from another district, or from your vendor. VeriThreat is built so that it isn't.
Walled off from every other district
Each district is a separate account. Every query for students, reports, and cases is limited to the signed-in user's district, and enforced on the server, not in the browser.
Even our staff can't look
VeriThreat's own team manages accounts and sees usage counts only: how many schools, users, and reports. We can't open a student, report, case, or note.
Tested before every release
Automated tests run on every change before it reaches production, including tests that try to reach one district's data from another and confirm they're refused.
Hosted in the United States
Data is stored on Google Cloud in the US (Iowa) and encrypted in transit and at rest. When AI is turned on, requests go to Anthropic with students pseudonymized first.
Backups and recovery
Automatic daily backups kept for 14 days, point-in-time recovery, and deletion protection on the database.
Access ends when someone leaves
When a staff member leaves, your district admin deactivates their account and every session they have ends immediately. Role changes take effect the same way.
Safeguards
Protection at every layer.
Tamper-evident audit log of every access
Views of students, reports, cases, assessments, and attachments are recorded with the user, time, and IP address, along with logins and every change. Each entry is chained to the one before it, and a daily fingerprint is kept in write-once storage, so the log can't be quietly altered. Administrators can search it by action or record.
Minimal student data
Roster sync uses read-only credentials and reads only names, IDs, and grades. Districts may import IEP, 504, and English learner status, and optional gender and race/ethnicity for an aggregate equity check that is never shown on a student or case and never sent to AI. We don't collect religion or income.
Pseudonymized AI requests
When AI is used, students are replaced with labels, known names are removed from free text, and identifiers are left out. AI can be disabled entirely.
Hardened authentication
Passwords hashed with bcrypt, repeated failed sign-ins slowed and then blocked, and two-step sign-in with an authenticator app that districts can require for leads and administrators or for everyone. Session tokens are stored only as hashes in HTTP-only cookies and expire after a school day; deactivating a user ends their sessions immediately.
Protected evidence files
Uploads are checked against their actual contents and size, stored under random names in a private, encrypted storage bucket, served only to authorized users, and never cached.
No caching of sensitive pages
Every page is rendered fresh on the server for the signed-in user, with no-store headers, a strict content security policy that blocks injected scripts, frame protection, and strict content-type handling.
Separation of duties
District administrators manage accounts and rosters but can't open student or case records. Only BTAM leads can finalize assessments or close cases.
Immutable decisions
Finalized assessments are locked. Reopening one requires a lead and is written to the audit log.
Alerts that carry no student details
Email, Microsoft Teams, Google Chat, and Slack alerts include only a report number, school, and link. Chat alerts go only to those providers' own webhook addresses, stored encrypted.
Compliance
Designed to support your obligations.
Student privacy law varies by state, and threat assessment records raise specific questions about access, retention, and sharing. We work with your counsel and privacy officer instead of handing you a checkbox.
Built in
- Record-of-access logging to support FERPA requirements
- Role-based access to education records by legitimate educational interest
- Data minimization for both storage and AI processing
Decided with your district
- Data processing agreements, including for AI processing
- Record retention and parent-access procedures
- Information sharing with school resource officers and law enforcement
- Account provisioning and sign-on requirements
Security documentation and deployment details are available on request.
Reviewing VeriThreat for your district?
Everything privacy officers, IT directors, and counsel usually ask for, including our data inventory, subprocessors, retention and deletion, and accessibility.
Every attacker in the Secret Service's study showed concerning behavior first.
Make sure the people who notice it have somewhere to go, and your team has what it needs to act.