Security & privacy
Built for K-12 procurement.
School IT teams have seen enough vendor security pages to know when one is hand-waving. This isn’t one of those. Below is what’s in place today and a direct line to a human who can answer your district’s specific question.
- FERPA-aligned data handlingLive now
- Per-school RLS (database-enforced)Live now
- TLS 1.2+ · AES-256 · encrypted backupsLive now
- DPA published for reviewLive now
Every claim on this page has a section below. Skim, then email support@bellplan.app when you hit a question.
Four pillars your IT team will check first.
Every district procurement form asks the same four questions. Here are the answers, by name, with the architecture detail.
ARCHITECTURE
Per-school data isolation
Every row carries a school identifier and is gated behind row-level security. The database itself rejects any query that tries to read another school's data — not the application code, the database. That boundary holds even if our app code has a bug.
RLS is database-enforced. App bugs can't leak across schools.
POLICY
FERPA-aligned by design
BellPlan stores school operational data — events, tasks, role assignments, internal notes — not student records. The data model has no place for student PII, and the DPA obligates each school to keep it out of free-text fields. Operational data stays inside the school's tenant boundary, is never used to train models, and is never sold.
Tenant boundary is the architecture, not a policy promise.
ENCRYPTION
Encryption everywhere
TLS 1.2+ in transit. AES-256 at rest. Database backups are encrypted at rest by our infrastructure provider (Supabase). Internal access to production systems is least-privilege, and administrative actions inside the product are recorded in a per-school audit log.
Modern defaults. No bring-your-own-key required.
PAPERWORK
Data Processing Addendum
A Data Processing Addendum covers every school from day one, and the full text is published for review — legal and IT can read every clause before a single row of data lands in BellPlan. Districts that need a countersigned, school-specific copy can request one by email.
Full DPA public at /legal/dpa. Countersigned copies on request.
Reading the diagram: every query the app sends carries a school identifier. Postgres lets matching rows through and returns zero rows for everything else. The check runs at the database, not the app.
Operational data only. Not student records.
A surprising number of IT reviews ask the same thing first: do you store any student PII? The answer is no. BellPlan stores the work it takes to run a school year — not the kids.
- Student PII (names, demographics, attendance)
- Gradebook records
- SIS / student information system data
- Parent contact data
- Anything that belongs in a permanent record
- Events on the school-year calendar
- Tasks and subtasks for those events
- Role assignments (not name assignments)
- Internal notes from the staff running the work
- Staff contacts the district provided you
BellPlan security one-pager.
Everything every district IT review form asks — architecture, encryption, sub-processors, incident response, deletion — in one document. Pre-screen BellPlan before involving the team.
The things district IT actually asks.
Have a specific question?
District IT, procurement, or a parent with a sharp question — email a human and you'll get a real answer within one school day.
support@bellplan.app · one school-day reply