SECURITY & TRUST
Security is our foundation, not a feature.
Every architectural decision was made before we wrote a single line of product code. Here’s exactly how we protect your students’ data, and how we go beyond what a standard data privacy agreement asks for.
SECTION 01 / COMPLIANCE
Compliance is our architecture, not a checkbox.
Built from day one to meet the highest standards in K-12 student data protection.
FERPA compliant
We operate as a "School Official" under the district’s direct control. Your data is never used for any purpose beyond providing this service.
● SHIPPED
COPPA compliant
Aligned with the updated COPPA rules effective April 2026. Student data is never used to train AI models, a structural guarantee, not just a policy.
● SHIPPED
IDEA compliant
IEP/504 records receive our highest protection tier: dedicated encryption, restricted role access, and a separate audit trail.
● SHIPPED
State data privacy laws
All data stored and processed within the United States. We meet state-level frameworks including Illinois SOPPA/NDPA, the Massachusetts Student Data Privacy Act, and equivalents nationwide.
● SHIPPED
Student Privacy Pledge
Committed to responsible student data stewardship. Signing via the SDPC NDPA before our first production district.
◌ COMMITTED
SOC 2
Type I targeted Q3 2026; Type II observation period running through Q1 2027. Independent third-party validation of our controls.
◌ COMMITTED · Q3 2026
CIS Controls v8 (IG1)
Our baseline cybersecurity framework, recognized for SOC 2 readiness and accepted under state NDPA frameworks.
● SHIPPED
SECTION 02 / DATA CLASSIFICATION
Four tiers. Every piece of data classified.
Protection scales with sensitivity, from aggregates to protected health records. There is no "public / unencrypted" tier. Everything is encrypted.
| Tier | Sensitivity | Examples | Protection |
|---|---|---|---|
Tier 1 HIGHEST |
Protected health / disability | IEP/504 documents, disability status, health records, behavioral data | Per-district encryption keys + application-level encryption, dedicated IDEA audit trail, restricted role access |
Tier 2 PII |
Direct identifiers | Names, SSNs, state student IDs, addresses, contact info, birthdates | Application-level AES-256 encryption, blind indexes for search |
Tier 3 EDUCATIONAL |
Records | Grades, attendance, discipline, assessment scores | AES-256 at rest, role-filtered by database policy |
Tier 4 AGGREGATE |
De-identified | School averages, trend data, course catalogs | AES-256 at rest, no individual PII; groups under 5 students suppressed |
SECTION 03 / DEFENSE IN DEPTH
Every layer hardened.
Multi-layer infrastructure security on enterprise-grade cloud.
AWS
AWS cloud infrastructure
Hosted on AWS (SOC 2, FedRAMP, FERPA-aligned). US-only regions; student data never leaves the country.
ENV
Fully separated environments
Production, pre-production, and security monitoring run in isolated AWS accounts. A compromise in one cannot reach another.
NET
Three-tier network
Public tier holds only the load balancer; the application tier has no public internet access; the data tier has no route to the internet at all, even outbound.
AES
Encrypted at rest
AES-256 everywhere, the standard used by banks and the U.S. government.
TLS
Encrypted in transit
TLS 1.3 for all data movement. No unencrypted connections, anywhere.
KMS
Per-district encryption keys
Each district gets its own key via AWS KMS. On offboarding, we destroy the key, rendering that district’s data permanently unreadable, including in backups.
VPC
AI processing over a private network
All AI traffic flows through AWS PrivateLink. Student data never traverses the public internet.
WAF
Web Application Firewall
Blocks SQL injection, XSS, and automated attacks. US-only traffic permitted.
IaC
Keyless CI/CD & IaC
Infrastructure-as-code (Pulumi), keyless CI/CD (GitHub Actions via OIDC), and no static cloud credentials anywhere.
SECTION 04 / ACCESS & ROLES
Access & Roles, enforced at the database, not the UI.
Roll Upstart out to your whole district with confidence. A principal sees only their school. A teacher sees only their roster. A superintendent sees only aggregates. The boundary is enforced by the database, not the screen, and cannot be slipped past with a clever question.
| Role | What they see |
|---|---|
|
Technology / SIS Director
|
District-wide, all data and fields, audit logs, the generated SQL. |
|
Curriculum Director
|
District-wide academic data, no discipline, IEP, contact info, SSN, or FRL detail. |
|
Principal
|
Their assigned school(s), full roster, attendance, assessment, grades, discipline, full IEP/504. |
|
Assistant Principal
|
Same as Principal, but accommodation summaries only (no full IEP documents). |
|
Teacher
|
Their rostered students only, accommodation summaries, not full IEP documents. |
|
Superintendent
|
District-wide, aggregate and de-identified only, never individual records. |
Custom roles, custom permissions.
The six standard K-12 roles cover most districts. When your structure doesn’t fit, define custom roles with custom permission sets, granular by data category, scope, and action, and assign them to individual staff.
Roles are a starting point. Scope (which buildings, which classes) is configured per person.
SECTION 05 / FIVE-LAYER AI DEFENSE
The AI is treated as untrusted. Five layers verify its output.
No layer trusts any other. Even if the AI generated a malicious query, layers 2–5 catch it.
1
Schema filtering
The AI only sees the tables and columns the user’s role is authorized to query. A teacher’s AI sees a different schema than an administrator’s.
→
2
Query validation
Generated SQL is parsed and validated. No writes, no cross-tenant access, no system tables can pass.
→
3
Access-filter injection
Role and scope filters (district, building, roster) are appended after AI generation. The AI cannot bypass what it doesn’t control.
→
4
Database enforcement
Postgres Row-Level Security as a final fail-safe, independent of application logic. Even if layers 1–3 had bugs, the database refuses unauthorized data.
→
5
Result post-processing
Every query is audited, and groups of fewer than 5 students are suppressed to prevent re-identification.
“No layer trusts any other layer.”
SECTION 06 / ZERO AI TRAINING
Zero AI training on student data. Period.
A structural guarantee enforced by our architecture, not merely a policy.
WHAT BEDROCK RECEIVES, AND WHAT HAPPENS TO IT
› Schema + your question (text-to-SQL step)
sent
› Query results (to write the plain-English summary)
sent
Retained after the response
never
Used to train or fine-tune a model
never
Seen by Anthropic, the model maker
never
- All AI processing runs through AWS Bedrock, Amazon’s enterprise AI service.
- AWS Bedrock has zero data retention. Every prompt, completion, and intermediate result is discarded the moment the response is generated. We have also explicitly opted out of Bedrock’s default 30-day abuse-monitoring logging.
- Anthropic, the model maker, never receives or sees the data. Bedrock’s Model Deployment Account architecture makes this structural, not contractual.
- Student data is never used to train, fine-tune, or improve any AI model, structural via AWS Bedrock, not just policy.
- Only two subprocessors handle student data: AWS (hosting + AI) and Ednition (SIS data pipeline). No OpenAI, no Google AI, no third-party analytics.
SECTION 07 / BEYOND THE DPA
We go beyond the standard DPA.
Most districts sign the SDPC NDPA, a solid 2020 baseline. Here’s where our architecture exceeds it.
| The standard DPA says… | What Upstart actually does |
|---|---|
| Encrypt data at rest | Per-district KMS keys; on offboarding the key is destroyed, cryptographically shredding the data, including every backup copy. |
| Limit access to authorized employees | Postgres Row-Level Security forced at the database layer, an application bug cannot leak cross-tenant data, and even a table owner can’t bypass it. |
| Mostly silent on AI training | Student data is never used to train, fine-tune, or improve any AI model, a structural guarantee via AWS Bedrock’s zero-retention architecture, not just a contractual promise. |
| Doesn’t address AI-provider isolation | Bedrock’s account topology makes Anthropic structurally unable to reach prompts, completions, or accounts. |
| Enter written agreements with subprocessors (no cap) | A hard architectural cap of two subprocessors, with 5-business-day advance notice for any change. |
| Maintain logs | Append-only audit enforced three ways (DB triggers + role revokes + S3 Object Lock WORM, 7 years); fail-closed, if the access can’t be logged, the data isn’t returned. |
| Dispose of data within 60 days | 60-day deletion plus key destruction that makes the data mathematically unrecoverable, no need to scrub individual backup snapshots. |
SECTION 08 / LOGGING & AUDIT
Every access logged. Every log immutable.
Complete transparency and accountability for all data access.
- Complete query loggingWho asked, what was asked, what data was returned, and when.
- Immutable audit trailWrite-once storage that cannot be altered or deleted, even by our own engineering team.
- Dedicated IEP/504 trailSpecial-education access is logged in a separate, IDEA-compliant audit trail.
- Verifiable deletionData deleted within 60 days of contract termination, with cryptographic verification that it’s permanently unrecoverable.
SECTION 09 / ADDITIONAL COMMITMENTS
More of what we do, every day.
Daily backups with ransomware protection (WORM storage; even a compromised root account can’t delete a backup early).
4-hour recovery-time target.
Annual penetration testing by independent researchers (first test pre-launch).
Continuous compliance monitoring with real-time alerts.
Minimal subprocessor chain with 5-day advance notice before any change.
Cyber liability insurance for K-12 EdTech data incidents (procured pre-launch).
Annual data review with each district.
72-hour breach notification commitment with a defined incident response plan.
SECURITY @ UPSTART
Questions about our security practices?
We’re happy to walk through our architecture in detail, line by line if you want.
Contact our team →