Student Data Privacy: A Practical Guide for Teachers

Every time you photograph a student’s work and upload it somewhere, you make a decision on their behalf about where that data goes. Most of the time that decision is fine. Occasionally it is not, and the difference is usually whether anyone stopped to think about it first.

This is practical guidance, not legal advice. Rules differ by country, by state and by school district, and if you are unsure about something specific, ask whoever handles data protection at your school.

Start by collecting less

A very effective privacy measure is not collecting the data in the first place. Three questions to ask before any new tool:

Do I need this particular piece of information? A quiz score does not need a full name, a date of birth and an email address.
Does it need to leave the classroom at all? Plenty of tasks — grading, scoring, item analysis — can be done entirely locally.
If it does leave, who else sees it, and for how long?

Identifiers: use the least you can

A common unnecessary risk in this whole area is a full name on a scannable document. A sheet with a student’s name on it, uploaded to a grading service, is a named educational record sitting on someone else’s server.

Better options, in ascending order of privacy:

No identifier at all for practice, surveys and anonymous feedback. Our no-header sheets are built for this.
A desk or seat number that only your seating plan maps to a name.
A school ID number, bubbled into a grid rather than written. Machine-readable, but meaningless to anyone without your roster.
A full name only when you have a specific reason.

If you run a bubble-in ID grid, use a number that is not derivable from anything public. A student number is fine. A date of birth is not — it is a permanent identifier that never changes and cannot be reissued.

Know which of your tools are local

Tools fall into three rough buckets, and the distinction is what matters:

Local: nothing leaves your device. A PDF you print, a punched answer key overlay, a spreadsheet on your own laptop, a generator that builds files in your browser. There is no vendor, no upload, and nothing to audit. This is why the generator on this site runs entirely client-side — a sheet you are about to use for a real assessment should not pass through anyone’s server.

Local-ish: a phone app. Grading apps may process on the device, upload to a cloud account, or both. Check which, because it changes what you are responsible for.

Cloud: everything is uploaded. If you photograph student work into a website, the image goes to that company’s servers, and the terms of that relationship are set by their privacy policy and, if your school has one, a data-processing agreement.

None of these is inherently wrong. But you should be able to say which bucket each tool you use falls into.

Before you adopt a tool

A short checklist that catches most problems:

Is there a data-processing agreement, and has your school signed it? In many jurisdictions a school must have one before staff put student data into a service. If your school has not signed one, that is a question for your administrator, not something to work around.
Where are the servers, and who can access the data? “We may share aggregated data with partners” is worth reading closely: find out who the partners are.
How long is data retained, and can you delete it? A service that keeps student work indefinitely is a liability you cannot undo later.
Is it used for advertising or model training? Read the privacy policy for these words specifically. Some free tools are free because the data is the product.
What happens to the account when a student leaves? You want an answer before you need it.

Age matters

Rules tighten for younger children. In the United States, the FTC’s COPPA FAQ says the COPPA Rule covers commercial websites and online services directed to children under 13, and general-audience services that know they are collecting information from children under 13. How it applies in a school setting is a question for your school’s data lead. Similar rules exist elsewhere under different names.

A cautious default for under-13s: use local tools, avoid accounts, and put nothing identifying into anything that uploads.

Bubbling, scanning and images

Some specifics for answer sheets:

A photograph of a completed sheet is student data if the sheet carries a name or ID. Treat the photo like the sheet.
Scan locally where you can. A document scanner writing to your own laptop keeps the image on your machine.
Delete images after grading if you have no reason to keep them. A folder of 150 photographs of student work is a risk with no upside.
Do not share images of student work in group chats, teachers’ lounges or social media, even with names covered. A partially-covered name on a photograph is often readable.

Record keeping

If you keep scores, keep the minimum: identifier, assessment, score, date. Keep them where your school expects them to be kept — usually the official gradebook, not a personal spreadsheet on a personal device.

Two practical habits:

Never email a class list with scores to yourself or to a colleague on a personal account.
Do not keep assessment data past the point of usefulness. Many scores stop being useful after the semester ends; check your school’s retention rules and delete them then.

Talking to students and parents

You do not need a policy document to do the right thing, but you do need an answer ready. Parents ask three things: what did you collect, where did it go, and can you delete it. If you can answer all three in one sentence each, you are in good shape.

It is also worth telling students, in age-appropriate terms, why you use ID numbers instead of names. It is a small lesson in data minimization, and they will carry it further than the test will.

The short version

Collect the least you can, and prefer numbers to names.
Prefer tools that keep work on your own device.
Know which of your tools upload, and whether your school has an agreement in place.
Delete what you no longer need.
When in doubt, ask your school’s data lead before you adopt, not after.