Keep student names, identifiers, grades, contact details, free text messages, and every credential or token out of logs and error reports. Log opaque internal IDs and event types instead. Libraries record whatever your code gives them, so the safe default is to scrub before logging, not after.
Why logs are a quiet risk
Logs are written by many hands, kept for a long time, copied to other tools, and read by people who may not be cleared to see student records. A crash reporting library can attach request bodies, headers, and local variables to each error. Those details are useful for debugging and equally useful to anyone who gets into the tracker.
The FTC's COPPA guidance says operators must keep children's information confidential, secure, and intact, and keep it only as long as needed for the purpose collected. Logs that quietly copy student data work against both points.
What to keep out
| Category | Examples | Safer alternative |
|---|---|---|
| Direct identifiers | Names, emails, phone numbers, addresses | Internal user ID |
| Education record content | Grades, attendance, disciplinary notes, special program status | Event name only |
| Free text | Messages, essays, support chat | Length or hash, never the text |
| Credentials | Passwords, session cookies, API keys, reset tokens | Nothing, ever |
| Full request bodies | Form submissions, uploads | Selected fields on an allow list |
How to build it in
- Use an allow list. Define the few fields that may be logged for each event. Everything else is dropped. A deny list always misses something.
- Wrap your logger. One shared function that applies redaction means developers cannot forget.
- Configure third party reporters. Look in the settings of crash and performance tools for options that control request data, user data, and breadcrumbs, and turn off what you do not need.
- Scrub URLs. Query strings often carry IDs or tokens.
- Test it. Add a unit test that logs a fake student record and fails if the output contains it.
- Shorten retention. Keep logs only as long as your debugging and audit needs require, and set the limit explicitly.
- Restrict access. Fewer people should be able to read logs than can read the codebase.
Dependencies are part of this
Your logging stack is code you did not write. Check its release notes when you update: a new default that captures more context can undo your configuration. Keep the version list for logging and error tracking packages in your inventory, and treat changes to them as review-worthy.
Also check libraries that write their own debug output. Some HTTP clients and ORMs can print full queries or request bodies when a debug flag is on. Make sure that flag is off in production and cannot be switched on without review.
Plan for the day it goes wrong
Decide now how you would purge a tracker if student data landed in it: who can delete, how you confirm it, how you tell the school. Practice it once.
Quick check
Is hashing a student ID enough to log it?
Not always. If the input space is small, a hash can be reversed by trying candidates. Prefer a random internal ID that has no meaning outside your system.
Can we log student data in a private log system?
You can, but it increases the people and tools that touch records. Log less if you can, and restrict access either way.
Safeguard's dependency scanning and policies can help you spot version changes in logging and reporting libraries as they happen, and the free scan is a quick place to start.
Sources
Last reviewed: 19 October 2026.
