Security overview

Security at OneTeam.

A plain-English summary of the technical controls protecting student data. Detailed obligations live in our Data Privacy Agreement.

Technical controls in production

Encryption in transit

TLS 1.2 or higher

Every connection between the OneTeam app, our servers, and our sub-processors uses TLS 1.2+ with modern cipher suites. HSTS is enabled on the marketing site.

Encryption at rest

AES-256, managed keys

All data stored in our Supabase Postgres database is encrypted at rest using AES-256 with keys managed by Supabase. Backups are encrypted with the same standard.

Row-Level Security

RLS on every table

Every ot_* table in our Postgres schema has RLS policies. A teacher can only read students assigned to them; an administrator can only read students in their school. Enforcement is at the database level — application bugs cannot bypass it.

Audit logging

Every change recorded

Every read, write, and delete on student records is recorded in an append-only audit log with the actor, timestamp, and action. Used for parent-rights data export, deletion verification, and incident investigation.

Authentication

Email + password, MFA gating on destructive actions

Email/password auth via Supabase Auth. TOTP multi-factor authentication is available for all staff. Server-side, destructive admin actions (account deletion, retention purge, hard delete of a student record) are gated to aal2 — i.e., the caller must have presented a second factor in their current session — regardless of whether the call comes from the iOS app, the web app, or a direct PostgREST request. MFA is not required for normal login or dashboard access; that is on the roadmap and inherited per-district from Entra ID Conditional Access when SSO is enabled. Passwords are hashed with bcrypt by Supabase Auth; OneTeam servers and personnel never see plaintext.

Authorization

Role-based access control

Users have one of: parent, teacher, administrator. Each role’s permissions are enforced both in the application and at the database level via RLS. No user can escalate their own role.

Data retention

Automatic purge after 2 years

Behavioral check-ins, tier history, and cycle evaluations are eligible for automatic deletion after 2 academic years by default. Schools may configure shorter retention. License termination triggers full deletion within 30 days.

Hard deletion

Cascade across every table

When a parent or school requests deletion of a student record, the deletion cascades through every table holding data tied to that student. A paired audit-log entry documents what was deleted, with row counts.

Hosting region

United States

Database (Supabase) and web hosting (Vercel) both run in U.S. regions. Student data does not leave the United States.

Vulnerability management

Dependency scanning + reviews

We use automated dependency scanning (npm audit, Dependabot) and manual code review on every change. Production deploys require all checks to pass.

Tier visibility

MTSS tier is admin-only

A student's MTSS tier assignment is visible only to authorized school administrators and the student's authorized parent or guardian. Tier is never displayed on classroom-teacher dashboards, on screens shared between students, or in any surface other students or their families can see. Enforced in the iOS app and by Row-Level Security on the tier-history table.

Authentication & Identity

Common district-questionnaire answers, with the current state and the roadmap stated separately so there’s no daylight between what we say and what’s shipping.

Staff (administrators, teachers, specialists)

Today: email + password, managed by Supabase Auth. Passwords are bcrypt-hashed in Supabase’s auth.users table; OneTeam servers and personnel never see plaintext. HaveIBeenPwned breach-list integration rejects compromised passwords at signup and password change.
Roadmap (per-district): Microsoft Entra ID OIDC, tenant-locked to the district’s Microsoft 365 tenant. When this is enabled for a district, OneTeam stores no passwords for that district’s staff — authentication, MFA, and session lifetime are inherited from Entra.
SAML 2.0: on the roadmap. Available on request for districts that require it; OIDC is the supported flow for v1.

Parents

Authentication: emailed sign-in link (magic link) is the default; password is optional. Parents are not in the district directory.
Authorization to a child’s record: per-student share code issued by the child’s teacher, plus admin-approved access request. Knowing the share code does not grant access on its own — a teacher must approve, and the parent must accept the consent disclosure before any data renders.

Students

Students do not sign in to OneTeam. Children under 13 do not have OneTeam accounts.

Multi-factor authentication

Today: TOTP MFA available for all staff via Supabase Auth. Destructive admin endpoints (account deletion, retention purge) are aal2-gated server-side, regardless of UI path.
With Entra: staff MFA is inherited from the district’s Conditional Access policy — OneTeam does not enroll a separate factor.
Parents: not required.

Sessions

Sessions are JWTs issued by Supabase Auth (signed with Supabase’s key, validated server-side). OneTeam does not mint its own session tokens.
Default access-token lifetime: 1 hour. Refresh tokens are rotated and server-revocable.
No session secrets are persisted client-side beyond the JWT and refresh token, which are stored in browser localStorage on web and the iOS Keychain on iOS.

Deprovisioning

Today: a school administrator disables a staff account in OneTeam directly. Active sessions are revoked on next request validation.
With Entra: when the district disables the user in Entra, the next sign-in attempt fails. Active OneTeam sessions end within the JWT TTL (default 1 hour). SCIM provisioning for immediate session revocation is on the roadmap if a district requires it.

Audit-log retention

OneTeam’s ot_audit_log is append-only and not purged automatically. Districts can request a configurable retention window (1 year minimum) on contract. Authentication events written to the audit log: account creation, email confirmation, account ban, account disable (mirrored from auth.users via a database trigger), and successful sign-in and MFA enrollment (logged client-side from the OneTeam app on every successful authentication). Events still recorded only in Supabase Auth’s internal log (auth.audit_log_entries) and exportable on request: sign-in failures, password-verification attempts, password resets, and MFA challenge attempts; mirroring those into ot_audit_log requires Supabase Auth Hooks (password-verification-attempt-hook + mfa-verification-attempt-hook) and is on the roadmap.

Sub-processors

OneTeam uses three sub-processors. Each is bound by a written agreement requiring them to handle data on our behalf subject to the same restrictions as our Privacy Policy and DPA, and contractually prohibited from using the data for any other purpose.

Sub-processor	Purpose	Region
Supabase	Postgres database, authentication, and transactional auth email (signup confirmation, password reset, login OTP — no student personal information is included in any email)	United States (us-west-2)
Vercel	Web hosting + serverless compute	United States (iad1)
Microsoft Teams	Notification webhooks (only when school configures the integration)	School’s own M365 tenant

We provide 30 days’ written notice before adding or changing any sub-processor. Schools may terminate their agreement before a new sub-processor takes effect if they object.

Incident response

If we discover or are notified of a security incident affecting student data, we:

Notify affected schools without unreasonable delay, and within 72 hours when feasible.
Provide a written incident summary including scope, root cause, remediation, and affected records once the investigation is complete.
Cooperate with the school’s breach-notification obligations under FERPA, state laws (e.g., NY Ed Law 2-d, CA SOPIPA), and the school’s own policies.

Reporting a vulnerability

If you believe you’ve found a security vulnerability in OneTeam, please email privacy@oneteam.school with subject line “Security disclosure”. Include reproduction steps and the impact you observed. We acknowledge within 1 business day, work in good faith on a fix, and credit researchers in a coordinated disclosure if you wish.

What’s on the roadmap

We are committed to continuous improvement of our security posture. Currently in development:

Independent third-party penetration test (target: 2026–27 school year).
Formal SOC 2 Type II audit (under evaluation).
Security questionnaire pre-fills (CAIQ-Lite, HECVAT) for district procurement.

Last updated May 1, 2026.