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 →