Security & Privacy

DistrictBinder stores no student records by design. There is no student information schema, no student information system (SIS) integration, and no collection of grades, health, or special-education data as structured records.

• Staff and board accounts: name, email, and district role. Accounts are provisioned by district administrators — there is no open self-signup.
• Governance records:policies, agendas, minutes, and named vote records — your district's public record, held on its behalf.
• Public participation: speaker sign-ups and public comments (name, contact information, topic), moderated by district staff before public display.
• Uploaded documents: a built-in scanner checks uploads for student identifiers, Social Security numbers, and personal names, and offers redaction before a document is ingested.

Closed-session protection: executive-session items are structurally excluded from the public portal. Titles appear in the public record where required by open-meetings law, but motions, votes, and materials from closed sessions never do. Where judgment calls exist, the platform is deliberately biased toward under-disclosure.

• Hosting: the application runs on Vercel and data is stored in Supabase managed PostgreSQL, on U.S.-hosted cloud infrastructure.
• Tenant isolation: every record is scoped to a district identifier, and every API operation resolves and enforces district context. Database row-level security provides a second layer of protection on core record tables.
• Role-based access: eight defined roles — from superintendent to staff — with a documented capability matrix, enforced at the network edge, in every API route, and in database policy.
• Sessions: HTTP-only secure cookies; passwords are hashed and managed by Supabase Auth.
• File access: documents are served only through short-lived signed URLs (one-hour expiry) after ownership and tenant checks.

• In transit: TLS on all connections, with HTTP Strict Transport Security enforced and automatic upgrade of insecure requests.
• At rest: database and file storage are encrypted at rest by our managed infrastructure providers.
• Content safety: a full security-header suite (Content Security Policy, frame denial, MIME sniffing protection) and allowlist-based HTML sanitization on all rendered rich text.
• Abuse protection: rate limiting on public submission and AI-powered endpoints.

• An append-only audit log, enforced at the database level, captures the actor, operation, and full before-and-after snapshots for changes to policies, votes, meetings, and role assignments. The database itself rejects edits or deletions of audit entries.
• Votes are never deleted. Corrections are recorded as voids with the actor and reason preserved alongside the original record.
• Meetings are never hard-deleted, supporting minutes-retention obligations, and agendas are versioned on every published change.
• Open-meetings compliance: state-specific notice requirements are encoded in the platform, with warnings for late postings.

Your community portal is your public face, and it must work for every resident. The DistrictBinder public portal is audited against WCAG 2.1 AA: our most recent accessibility audit (July 2026) found zero automated accessibility violations across all public page types in production. Color-contrast minimums are enforced server-side, so district branding choices can never break accessibility for your community.

We use a small set of service providers to operate the platform:

AI features process district policy and document text through Google and Anthropic APIs under commercial terms; district data is not used to train their models. AI processing is a per-feature choice, not a requirement of core governance workflows.

This list is reviewed whenever our infrastructure changes. Last reviewed: August 2026.

• Your data is yours. Districts own their data. Document and record exports are built in, and we return or delete district data on termination.
• Incident response: we notify affected districts within 72 hours of a confirmed security incident involving their data.
• Data privacy agreements:we are prepared to execute your district's standard data privacy agreement or the Student Data Privacy Consortium's National Data Privacy Agreement (NDPA).
• Roadmap: single sign-on (Google Workspace / Microsoft Entra ID), multi-factor authentication, and SOC 2 Type II certification as the platform moves from pilot to general availability.

Questions, security reports, or vendor questionnaires: admin@districtbinder.com. We respond to security reports as a priority.