Education data protection in school software

Education data protection is the work of deciding, inside the software a school or an edtech company runs, how student information is handled. Six decisions do most of it: who can see a student’s records, what gets logged, how long data is kept, how it leaves, when a person’s access ends, and how backups and incidents are handled. In the US it usually goes by student data privacy. Laws and contracts set the obligations, and the software carries them out.

Who can see which student records?

Access in school software follows relationships as well as roles. A teacher opens the records of students in the sections they teach, a counselor the students on their caseload, a parent their own children, and a principal one school rather than the whole district. Where those relationships come from the student information system’s roster, access is only as current as the last sync. Some fields need a smaller circle than the record they sit in, such as discipline notes or special education accommodations. Reading and changing are separate permissions, so seeing grades does not mean editing them.

Every person needs a named account, a vendor’s support staff included, limited to the task in front of them. Ask whether staff and administrator accounts require multi-factor sign-in.

What should the system record?

When a principal needs to know who has been reading a student’s discipline file, the audit log should answer. A useful log records views of sensitive records, changes with the old and new values, exports, role and permission changes, and sign-ins. Entries are never edited, and the school’s staff can search them without going through the vendor. Because a log that keeps old values holds student data too, it needs its own access limits and its own line in the retention schedule.

Error reports and analytics events collect names and ID numbers unless they are designed not to. A copy of the live database used for testing makes a test server one more store of student records.

How long should student data be kept?

Each kind of record needs its own written answer, within any records schedule your state sets. A school might keep transcripts permanently, a learning platform’s activity data for the length of a course, and access logs for a fixed period. We agree that schedule with the school in scoping and build the system to apply it, so deletion does not wait for anyone to remember it. It also needs an end-of-contract line: what comes back to the school, what is deleted, and how the deletion is confirmed.

Deletion has to reach the copies. A record removed from the main database can survive in a search index, an analytics store, a cache or a saved export. Backups are not edited record by record, so restoring an older one brings back whatever was deleted after it was taken, and the restore procedure has to delete those records again.

How does student data leave the system?

Exports are the most visible way out, so decide who may run one and prefer a standing integration to a spreadsheet emailed around. On our education builds each integration is written down in scoping field by field, with the system that owns each field and the direction it flows, so that document doubles as the list of what leaves.

Tools launched from a learning platform are another route. In an LTI 1.3 launch, name and email are optional, but a tool granted the roster service can request the whole class list, with names and emails if the platform shares them. The platform’s settings for each tool decide what it learns, so check them on any platform, and design them in if you are building your own learning management system. Last, list every outside service the software calls, with the data each one receives.

When should someone’s access end?

On the day their role ends. Where staff and students sign in with Microsoft Entra ID or Google Workspace accounts, disabling an account in that directory stops the person’s next sign-in, but it may not end a session the application has already issued. Microsoft’s guidance on revoking access says Entra ID cannot revoke such a session, so the application must. Ask how long sessions last and whether the software acts on the directory’s change. We have delivered both kinds of sign-in on education builds.

Some access never went through the directory, such as a contractor’s local account or an API key. A teacher who moves schools gains new access, and the old is often left in place. For an app that works offline, decide what it stores, how long that lasts without a connection, and when signing out clears it.

Backups, restores and incidents

Backups hold student data, so they need the same access rules as the live system and a line in the retention schedule. Ask whether backups and the live database are encrypted, who holds the keys, and whether one copy sits where a compromised administrator account cannot delete or alter it. On a maintenance retainer, backups run automatically in the school’s own infrastructure, we check that each one completes, and restores are tested on a schedule.

Every system we launch has uptime and error monitoring. On a system we maintain, each incident at the retainer’s top severity level ends with a short written note to the school on the cause and the fix. A data breach also carries notice duties set by law and by contract, so write the vendor’s notice window into the agreement.

What FERPA and COPPA say about vendors

FERPA binds schools, districts and colleges funded under Department of Education programs. A vendor can act as a school official only if it does work staff would otherwise do, stays under the school’s direct control over the records, and is bound to use them only for the purpose they were shared for, passing them on without consent only where the rule allows. The school must also use reasonable methods, such as access controls, to keep officials to records they have a legitimate educational interest in (34 CFR 99.31 and 99.33).

COPPA binds a commercial online service directed to children under 13, or one with actual knowledge that it collects their personal information. It requires a written security program, a written retention policy, and deletion once the data is no longer reasonably needed (16 CFR 312.8 and 312.10). FTC staff guidance lets a school consent for parents only when the data is collected for the school’s use and benefit. State laws and any data privacy agreement you sign add more; which apply is a question for your counsel.

How we build these decisions in

When you bring us in as your education software development company, these decisions are settled in scoping, and the engineers in those meetings are the ones who build the system. Whatever your counsel says applies goes into the scoping document, and we check the design against it before build; the legal judgment stays theirs. Changes are reviewed before they ship and dependencies are scanned for known vulnerabilities. Secrets stay out of the code. Our contracts assign you the code we write and the intellectual property in it, and the infrastructure runs in your own accounts, so your IT staff can inspect the access rules and the audit log directly. The staff who will run the system are trained and get documentation for daily work.

The full service behind this post: Edtech & Education Software Development Services.