Product guides
Data-retention questions for school management, ERP, and SIS
A data-retention question guide for school management software, covering purpose, records, access, archival, deletion, exports, backups, suppliers, and review.
Begin with purpose and record type
Retention should begin with why the school holds a record and what decision or obligation it supports. Do not apply one period to every value in a connected system. Student identity, applications, attendance, assessment, fees, payments, staff access, messages, documents, support tickets, exports, and backups may have different purposes and requirements.
Create a record inventory for the proposed phase. For each record, name the owner, purpose, users, source, retention trigger, access rule, archive state, deletion or return method, and review date.
Questions about lifecycle states
Ask what saved, active, submitted, approved, published, withdrawn, archived, restricted, and deleted mean. A record that is hidden from a family may still be active for the school; a record removed from a screen may remain in an export, backup, integration, or support tool.
Define the event that starts the retention period: application closure, enrollment end, academic year, employment end, payment reconciliation, contract end, or another approved trigger. Record exceptions only with an accountable reason and review date.
- What purpose justifies keeping the record?
- Who can access it in each lifecycle state?
- Which related copies or exports must be included?
- How is deletion or return evidenced?
- Who reviews the rule when law or school policy changes?
Questions about access and minimization
Ask whether the school can limit fields collected and exposed to the minimum necessary for the workflow. Test an archived student, former guardian, staff leaver, family export, and support request. The correct answer may be restricted access rather than a permanently visible record.
GOV.UK procurement guidance recommends data protection by design and default, minimum necessary data, access control, security measures, subprocessors, incident handling, and clear end-of-contract data return or deletion. These questions should appear in implementation and contract review.
Questions about suppliers and backups
Request a map of copies held by the platform, backups, integrations, payment providers, messaging tools, support systems, and subprocessors. Ask how a deletion, correction, legal hold, or contract-end return is propagated and evidenced across those copies.
Do not assume that “deleted” means irrecoverable immediately in every backup system. Ask for the actual lifecycle, operational exceptions, recovery implications, and responsibility for confirming completion.
Questions about exports and end of contract
Ask what the school can export, in what format, with which relationships, history, metadata, and audit information. Test whether an export is useful for migration or only a screen-level report. Define who requests it, who receives it, how it is protected, and when the school’s copy is deleted.
Contract-end obligations should name data return, deletion, supplier assistance, subprocessors, fees, timing, and evidence. Obtain qualified local legal and privacy advice rather than treating a generic vendor clause as a complete policy.
Review and govern the rule
The U.S. Department of Education data governance checklist connects lifecycle and disposal with quality, access, security, sharing, and monitoring. Review retention rules when the workflow, jurisdiction, vendor, data field, or school policy changes. Keep the owner and next review date visible.
A defensible retention decision is specific enough for an operator to apply, a system owner to configure, a privacy adviser to review, and the school to evidence later.
Keep a decision record for exceptions such as a legal hold, an unresolved complaint, an active safeguarding matter, a migration, or an investigation. The record should state who approved the exception, what access remains, what review date applies, and how the normal rule resumes.
Check that the rule is understandable to the staff who apply it and explainable to families or regulators when appropriate. Review a sample periodically to confirm that configuration matches policy and that an old export has not quietly become a second system.
