How your data is protected

A plain-language summary of what IncidentDesk stores, where it lives, and who can reach it.

What we store, and what we deliberately do not

Stored
  • Student first name, last name, grade
  • Incident date, location, type, description
  • Action taken; whether a parent was contacted
  • Which staff member filed the record
Not stored
  • Student ID numbers
  • Dates of birth, addresses, contact details
  • Disability status, IEP/504 details, diagnoses
  • Audio recordings (discarded after transcription)

A student may optionally be flagged so staff are prompted to check that student's plan before acting. The flag records only that a plan exists, never its contents, its type, or any diagnosis.

Where the data lives

  • Hosting: a managed database in the United States.
  • Encryption at rest: AES-256, applied to the database and all backups.
  • Encryption in transit: TLS on every connection.
  • Separation: every record is scoped to one school. No school can access another's data. This is enforced at the database level and checked by automated tests.

Who can see what

  • Teacher: sees the incidents they filed. An administrator may grant wider visibility.
  • Administrator (dean): sees all incidents for their school; manages the roster and staff.
  • Platform administrator: can access schools for support. Every such access is recorded in an audit log.

Passwords are hashed and are not readable by anyone. Accounts are created only by administrators or by emailed invitation.

How the voice logging works

When you speak an incident, the audio is transcribed and structured using the Google Gemini API on a paid tier. Under Google's paid terms, what is sent is not used to improve Google's models. The audio itself is not kept once it has been transcribed. Sent for a given incident: the spoken words and the school's roster of names and grades, so a spoken name can be matched to a student.

Keeping and removing records

  • Records are not deleted by everyday use. Incidents are archived, staying recoverable and auditable.
  • Every creation and edit is logged with the user and time, so a record's history can be reconstructed.
  • Continuous point-in-time recovery covers recent changes; encrypted exports can be produced on request.
  • On request, a school's data can be exported in full or permanently deleted.

Stated plainly: current limits

  • No single sign-on yet. Accounts use email and password.
  • No two-factor authentication yet.
  • No formal third-party security audit has been conducted to date.
  • This page is a summary, not a legal agreement. A district can sign a data privacy agreement on its own terms.

Questions? support@incidentdesk.org