Security pages often read like a wall of reassuring adjectives. This one lists specific controls that exist in the product, then lists gaps. If you work in school IT, the second half is probably the part you want.
What exists today
Connections and storage
- All traffic uses HTTPS, and plain HTTP requests are redirected to HTTPS.
- Data is stored in a United States region. The providers involved are listed on the data practices page.
- Passwords are stored as bcrypt hashes, not as readable text.
- The database is snapshotted daily and each snapshot is kept for five days. Deleted data can therefore linger in a snapshot until it ages out.
Accounts and sessions
- Sessions use signed tokens. The production server refuses to start if it is still using a default signing secret.
- There are three roles: teacher, student and admin. A request from someone not signed in is rejected, and a request from someone signed in with the wrong role is rejected separately.
Who can see what
| Role | Can see |
|---|---|
| Student | Only their own work, mastery and settings. |
| Parent | Only the child they linked to with a teacher-issued invite code. |
| Teacher | Their own classes and course materials. Asking for another teacher's class returns "not found" rather than confirming it exists. |
Monitoring and your control over data
- Error monitoring is configured not to send personal information by default.
- Signed-in users can export their records as JSON and delete their account. Student records are removed and the account is anonymized. Teachers can delete courses and materials at any time.
- A review of the code in July 2026 found no student names or emails in the prompts sent to the AI service. The one disclosed exception is the nickname moderation step, which sends only the nickname text.
What we do not have
- No third-party security certification and no published audit or penetration test report. We are not going to imply otherwise.
- Two-factor sign-in and single sign-on are not documented as available. Do not build a district requirement on them.
- Encryption of stored data is not something we have documented, and we do not claim it here. Ask your reviewer to request it in writing if it matters to your policy.
- We have not published a separate written security program document or an insurance statement.
- Breach notice is an email to affected account holders without undue delay after confirmation. There is no committed number of days.
What you control
Most real classroom risk is not a hacked server. It is a class code posted on a slide, a shared password, or a spreadsheet of student names uploaded as course material. Keep codes private, have students sign out on shared devices, and upload lessons and readings rather than rosters or graded work. The AI-related reasons for that are on student data and AI.
Reporting a problem
If you think you have found a vulnerability or a data exposure, write to the contact address on the data practices page with what you saw and what you did. Do not test against other people's accounts. For the legal side of what a vendor owes a school, see FERPA and ClassSense and data processing agreements.
Plain-language summary, not legal advice. Last reviewed October 2026. Laws and regulations change, so have your district's counsel confirm anything you rely on.
Common questions
Is ClassSense independently audited or certified?
No. We have no third-party security certification and no published audit or penetration test report.
Are student passwords stored safely?
Passwords are stored as bcrypt hashes rather than readable text. Students normally join with a teacher-issued class code.
Can one teacher see another teacher's students?
No. Teachers see their own classes. A request for another teacher's class returns not found, so it does not even confirm the class exists.
Is stored data encrypted?
Connections are encrypted with HTTPS. We have not documented encryption of stored data, so we do not claim it. Ask us in writing if your policy requires it.