Built for the trust K–12 buyers actually need.
Schools handle student-adjacent data and operate under procurement processes that don't accept hand-waving. This page is the short version of what we do and where we are on the standards every district asks about.
Hosting & infrastructure
synthEd runs on Fly.io, with managed Postgres for application data and Tigris (S3-compatible) for file attachments. Production traffic is served over HTTPS only. Fly.io enforces an edge-level redirect to TLS and negotiates TLS 1.3 where supported, TLS 1.2 otherwise, with AEAD cipher suites (AES-256-GCM, ChaCha20-Poly1305). HSTS is sent with max-age=31536000; includeSubDomains. Data is encrypted at rest at the storage layer.
Authentication
We support multiple sign-in methods so districts can match their policy: username/password (bcrypt-hashed), WebAuthn passkeys (FIDO2), TOTP-based two-factor authentication, and OAuth via GitHub. Google Workspace, Microsoft Entra, and generic SAML SSO are on our roadmap and can be discussed as part of a District engagement today.
Authorization & data scoping
Every query in the application is scoped to a school (and to a district for multi-school customers). Role-based access (SUPER_ADMIN / ADMIN / SPECTATOR) layers on top of granular permissions like create:task:any. Staff at one school cannot read another school's data, and the test suite enforces this at the data-access layer. Sensitive actions — role changes, impersonation, mass deletes — write to an immutable AuditLog used for incident review.
FERPA
synthEd is designed to be used in a FERPA-compliant manner. School Planner is built around operational data — events, tasks, assignments to staff — and is not a system of record for student information. Schools that choose to add student-identifying information to notes or attachments remain the data controllers under FERPA; our Data Processing Addendum (available on request) formalizes that relationship.
COPPA
School Planner accounts are for school staff, not students. We do not knowingly collect personal information from children under 13. If a district configures the product in a way that exposes student PII to our service, our DPA again establishes the school as the COPPA-relevant party.
SOC 2 & audit reports
We are early-stage and do not yet hold a SOC 2 attestation. Formal certification is on our roadmap. Districts that need a control-by-control review today can request our security questionnaire (CAIQ-Lite plus custom K–12 items), which covers the same control families a SOC 2 auditor would walk.
Data export & deletion
Customers can export their account data — school details, departments, events, tasks, subtasks, and attachment metadata — at any time as JSON or CSV from the in-app /resources/export-data endpoint. On termination, customer data is deleted from production within 30 days. Database backups follow our managed-Postgres provider's retention window and are then purged.
Sub-processors
Our current sub-processors — Fly.io (hosting + Postgres), Tigris (file storage), Resend (transactional email), Sentry (error monitoring), PostHog (product analytics), and GitHub (optional OAuth) — and the data each receives are listed at /sub-processors. We give thirty days' notice before adding a sub-processor that materially changes the categories of data processed.
Incident response
We maintain an incident-response runbook covering detection, triage, containment, notification, and postmortem. Confirmed security incidents involving customer data are disclosed to affected schools within 72 hours of confirmation, in line with our Terms of Service. Where state law (NY 2-d, Illinois SOPPA, etc.) imposes a shorter timeline, we meet that timeline.
Reporting a vulnerability
Security researchers and customers can report suspected vulnerabilities to security@synthed.co. Please give us a reasonable window to triage before public disclosure; we'll acknowledge within one business day.