Last updated: July 13, 2026
Model B's security practices are informed by the NIST Cybersecurity Framework (CSF) 2.0, a framework maintained by the National Institute of Standards and Technology and recognized among the cybersecurity frameworks referenced by the Student Data Privacy Consortium (via the Education Security and Privacy Exchange, Edspex). NIST CSF 2.0 is designed to be usable by organizations of any size and maturity, which is the right fit for Model B today: an early-stage company, still building toward formal third-party certification, that takes the security of school data seriously from day one rather than treating it as something to backfill later.
This document is organized around the CSF's six core functions: Govern, Identify, Protect, Detect, Respond, and Recover.
Model B is a single-founder company at this stage. Security-relevant responsibilities — access provisioning, vendor selection, incident response — are centralized with the founder rather than distributed across a team. We view this as something to be transparent about, not obscure: a small team means every access decision has a clear, accountable owner.
Vendor (subprocessor) selection follows a deliberate standard: a service is only added to Model B's infrastructure if it's necessary to operate the platform, and it's added with the minimum access required for its function. See the Subprocessors section below for the current list.
Model B maintains an internal, continuously updated inventory of what data the platform collects, where it's stored, who can access it, and how long it's retained — covering every module currently in production. This inventory is not published in full (it includes system-level detail not relevant to an external audience) but underlies both this document and our Privacy Policy, and is available for review as part of a district's due diligence process on request.
Data is organized into a small number of categories: account/authentication information, student directory-type information, operational records generated through normal platform use, free-text or uploaded content entered by school staff, and — in the Requests & Assist module — structured incident records that may include student associations (for example, an urgent Admin Assist request may identify specific students in connection with a reported incident type such as a behavioral escalation). Each category has a defined access scope — see Protect, below.
Authentication. School staff sign in via Google OAuth, Microsoft OAuth, or email and password. Passwords are never stored in plaintext or viewable by anyone, including Model B — only a securely hashed form is retained. At sign-up and password reset, submitted passwords are checked against a breach database using a privacy-preserving method (k-anonymity) that never transmits the actual password; only a small, non-reversible fragment is ever sent.
Access control. Access is enforced at the database layer using PostgreSQL Row Level Security (RLS) — not application logic alone. This means data scoping (a school only ever seeing its own data, a district-level role only seeing schools within its district) is enforced by the database itself, not something that can be bypassed by an application-layer bug.
Role-based, least-privilege access. Every role in the platform — teacher, staff, school admin, district-level roles — has an explicitly scoped set of permissions matched to what that role needs to do. No role has broader access than its function requires.
Substitute/guest access. Substitute teachers never receive a standing account. Access is a time-boxed, individually revocable session, scoped only to the specific classroom(s) they're covering, with instant revocation checked on every request rather than relying solely on session expiry. Every action taken during a substitute session is individually logged.
Vendor (Model B staff) access. Model B personnel can, when necessary for support or platform operation, access a school's account using the same role-based view that account's own users would see — never more. This access is logged: who accessed which account, when, and for how long.
Encryption. Data is encrypted in transit (HTTPS/TLS) between users and Model B's infrastructure, and at rest, consistent with the platform-level security defaults of our infrastructure providers (Supabase, Vercel).
Sensitive-content guidance. School staff are instructed not to enter health information, disciplinary records, custody or legal restrictions, or other sensitive personal information into free-text or document-upload fields. Model B does not review or process the content of these fields; responsibility for what's entered rests with the school and its staff.
Model B maintains audit logging for the platform's most sensitive access patterns:
As an early-stage company, Model B does not yet operate a dedicated security information and event management (SIEM) system or formal intrusion detection program beyond what our infrastructure providers (Vercel, Supabase) provide at the platform level. This is an area we expect to invest in as the company and customer base grow.
In the event of a security incident affecting customer data, Model B will notify affected schools without unreasonable delay after confirming the incident, and will cooperate with a school's own incident response and notification obligations under FERPA, applicable state law, and any agreement in place between Model B and the school. Specific notification timelines are governed by applicable law and by the terms of the agreement with each district, rather than a single fixed number stated here.
Model B operates automated nightly backups of all production data — both database records and uploaded files — to a geographically separate storage provider (Cloudflare R2), retained on a rolling 30-day basis. Backup access uses separate, restricted credentials from the application itself.
Model B uses the following service providers, each with access limited to what's necessary for their specific function:
| Service Provider | Purpose |
|---|---|
| Vercel | Application hosting |
| Supabase | Database, authentication, and file storage |
| Sign-in (if a user chooses to sign in with Google) | |
| Microsoft | Sign-in (if a user chooses to sign in with Microsoft) |
| Resend | Transactional email |
| Have I Been Pwned | Password breach checking, using a method that never transmits the actual password |
| Cloudflare | Automated, encrypted backup storage |
| Better Stack (Betteruptime) | Uptime monitoring and public status page |
This list is kept current and matches the list published in our Privacy Policy.
If you believe you've discovered a security vulnerability or issue affecting Model B, please contact hello@modelb.app. We take all reports seriously and will respond promptly.