Security & incident response
How Bright Path protects the records you enter, what happens to them over time, and what we commit to if something goes wrong.
Access control
Every route in the application requires sign-in. There is no anonymous read or write path to student records.
Records are scoped to a caseload at the database layer with row-level security, so a request can only return rows belonging to a caseload the signed-in user is a member of. Caseload owners control membership and can revoke a member at any time.
Passwords are handled by the managed authentication service; Bright Path does not store or see them. Data is transmitted over HTTPS.
Deletion and restore events are written to a caseload activity log.
Data residency
Application data is held by the managed cloud database described on the subprocessors page. The specific region is fixed per project rather than chosen per customer.
To confirm before publishing
- Exact hosting region(s) for the database, file storage and application runtime.
- Whether any subprocessor processes data outside that region, and on what transfer basis.
Retention
Deleted students and records move to Trash first so an accidental deletion can be reversed. Trash entries are kept for 30 days and are purged automatically the next time the caseload is opened after that window; a user can also purge an item, or empty Trash, immediately.
Purging is not a local-only action: the caseload's records are replaced in the cloud database on the same sync, so a purged record is removed from the live database and not just from the device. Settings → Caseload data controls includes a "Verify cloud copy" check that reads the live row counts back from the database so an administrator can confirm the purge took effect, and an "Erase records" action that deletes every record, Trash entry and activity-log entry for a caseload server-side and reports the post-purge counts.
Deleting a caseload or an account removes the associated students, goals, session data, services, attendance, meetings, communications and Trash from the live database. Account deletion is self-service in Settings and also removes the sign-in credential and profile.
Institutions should export their records before closing an account; Settings provides per-caseload JSON export, full JSON backup, and CSV export at any time.
To confirm before publishing
- Retention period for account and billing records after an account is closed (billing records are held by the payment processor named on the subprocessors page).
- Log retention period at the hosting and database layer.
Backups and restoration
Two layers exist. Customer-controlled backups are the exports produced from Settings; platform backups are automated snapshots taken by the managed database platform to recover the service after a failure. Platform backups are not a customer-accessible archive and cannot be restored for a single caseload on request.
Customer restoration procedure: (1) download a full backup (JSON) from Settings → Export your data, or a per-caseload export from Caseload data controls; (2) sign in and select the caseload the data should land in; (3) open Import and load the backup file; (4) choose merge to add to what is there or replace to overwrite the caseload; (5) spot-check a student's goals and recent sessions, then run "Verify cloud copy" in Settings to confirm the restored records are in the database.
Recommended practice for institutions: export a full JSON backup at the end of each reporting period and before any account or caseload deletion, and store it in the district's own records system. Because deletion is immediate and irreversible in the live database, an export taken beforehand is the only supported way to recover deleted records.
Platform-level restoration is initiated by the Bright Path operator with the hosting provider and applies to the whole project, not to an individual caseload.
To confirm before publishing
- Backup frequency and retention period offered by the hosting provider on the current plan.
- Restore objectives (RPO/RTO) the operator commits to.
- How long deleted data may persist in platform backups before it ages out.
AI provider data use
AI features are optional and only run when a user asks for a draft — a goal draft, a PLAAFP draft, a progress narrative, or a note summary.
When that happens, the text supplied for that specific draft is sent to the AI gateway described on the subprocessors page, and the generated text is returned to the user to review and edit. Nothing is published or sent to a family automatically.
Bright Path does not use customer content to train models and does not permit its AI provider to do so for training.
Users are the author of record for any AI-assisted text and are expected to review it before it is used in an IEP, a report, or family communication.
To confirm before publishing
- The AI provider's written retention period for prompt and completion data, and its zero-retention or no-training terms, quoted from the current contract.
Breach notification
If Bright Path confirms a security incident that has compromised customer records, it will notify affected account owners at their account email address without undue delay.
The notice will describe, to the extent known: what happened and when, the categories of records involved, what has been done to contain it, what the Institution should do, and a contact point for follow-up questions. Updates follow as the investigation progresses.
Bright Path will cooperate with the Institution so the Institution can meet its own notification duties to parents, eligible students, and regulators, since those duties sit with the Institution as the owner of the education records.
To confirm before publishing
- The committed maximum notification window (for example, within 72 hours of confirming an incident) — publish only a window the operator can actually meet.
- The named contact and escalation path for incident communications.
Reporting a vulnerability
If you believe you have found a security issue in Bright Path, report it privately using the contact address published for Bright Path rather than disclosing it publicly, and include enough detail to reproduce it. Please do not access, modify, or exfiltrate other users' records while testing.