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's application servers run on Fly.io; application data lives in a managed Postgres database at Neon; file attachments are stored in Tigris (S3-compatible); and nightly database backups are encrypted on our infrastructure before being archived to Cloudflare R2, which only ever holds ciphertext. 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: single sign-on with Google Workspace and Microsoft 365 (Entra ID), username/password (bcrypt-hashed), WebAuthn passkeys (FIDO2), and TOTP-based two-factor authentication. Generic SAML SSO can be discussed as part of a District engagement.
Single sign-on is bound to your directory tenant, not to email addresses. We hold an explicit allowlist of the Entra tenant ids and Google Workspace domains permitted to sign in and which district each represents; a sign-in from any other tenant creates no account and grants no access, whatever address it presents. This is what closes the "nOAuth" class of attack, in which someone with their own directory sets a mutable mail attribute to one of your staff addresses. Two-factor challenges and session lifetimes apply to SSO sign-ins exactly as they do to passwords.
Email security & link scanning (for IT departments)
Our sign-in and invitation emails are designed to coexist with K–12 email security, including Microsoft Defender Safe Links, Proofpoint, Mimecast, Barracuda, and remote browser isolation:
- Links contain no secrets. Verification links only navigate; the one-time code is in the email body and must be typed by a person. A scanner that fetches a link, or even renders and clicks it, cannot consume or invalidate anything, so no Safe Links exemption is required.
- Codes survive sandboxed browsers. A code is not used up until account setup actually completes. If a link opens in an isolated or short-lived container, the user can re-open it in their normal browser and the same code still works.
- Quarantine-tolerant validity. Verification codes are valid for 30 minutes (7 days for staff invitations), so a delivery delay from mail filtering does not strand users.
- Allowlisting. All transactional mail is sent from
@synthed.covia Resend. Allowlisting that sender domain is the only step we ask of district mail administrators, and only if delivery problems appear.
Districts that prefer to avoid email entirely can use Google or Microsoft SSO, so staff never receive a verification email at all.
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.
Activity log
Sign-ins, password and two-factor changes, role and permission changes, staff added or removed, data exports, calendar connections, impersonation by our staff, and every deletion write to an append-only AuditLog. Your admins can read your school's own history at any time under Settings → Activity Log, filtered to security events if that is what you came for. Security-relevant entries are kept for two years; routine day-to-day edits are kept for six months. An entry records who acted, what they acted on and when. It never records the contents of a message, file or debrief, and never an IP address.
FERPA
synthEd is designed to be used in a FERPA-compliant manner. School Planner is built around operational data such as events, tasks and 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, including school details, departments, events, tasks, subtasks, and attachment metadata, at any time as JSON or CSV from Settings → Export data. Exports keep working even for a suspended or lapsed account. On termination, customer data is deleted from production within 30 days; database backups are encrypted and expire on the fixed schedule published at /sub-processors, with deletion-on-request from long-term archives as described in our Terms of Service §15.
Sub-processors
The full list of sub-processors, covering hosting, database, file storage, backups, email, error monitoring, analytics, payments, and AI, and the data each one receives is maintained 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.