glossaryPage.heroH1

An SIS is one of the source systems that produces school data — usually the system of record for student demographics, enrollment, and grades. School data management is the broader practice of how every system's data (SIS, LMS, finance, attendance, transport, library, HR) is captured, governed, integrated, and used. You need an SIS to do school data management well, but an SIS alone is not data management; if grades sit in the SIS, fees in QuickBooks, and attendance in a spreadsheet, you have an SIS but no data management.

In the United States, FERPA (Family Educational Rights and Privacy Act) and COPPA (Children's Online Privacy Protection Act) regulate access, parental consent, and disclosure. In the European Union, GDPR sets the legal basis for processing, data minimization, and the rights to access and erasure; many member states layer additional rules for children. In India, the DPDPA 2023 introduces consent and breach-notification duties for student data. In South Africa, POPIA, and in Brazil, LGPD, follow GDPR-style principles. A school operating in any of these jurisdictions must map each data field to its lawful basis and retention rule.

Retention rules vary by jurisdiction and data class. In US K-12, AASA and most state archivists recommend permanent retention of transcripts and graduation records, 5 years for attendance and discipline, and shorter windows for routine correspondence; FERPA requires that an institution destroy education records when a parent or eligible student requests destruction unless they are otherwise required to be kept. UK ICO retention schedules for schools, and EU member-state schedules under GDPR, set similar tiered windows. A school data-management plan should publish a retention schedule by data class and enforce it through the SIS so records are not kept indefinitely by accident.

Under FERPA in the US, the school is the custodian and the parent (or eligible student) has the right to inspect, request amendment, and consent to disclosure. Under GDPR, the school is typically the data controller and any vendor that processes data on its behalf is a data processor bound by a written DPA; the data subject (student or parent) retains rights of access, rectification, and erasure. SaaS vendors do not own school data — any defensible contract includes an explicit clause stating the school retains ownership and the vendor only processes data on the school's instructions. Always verify this clause before signing.

A practical setup needs four roles, which in small schools may all sit with the same person. (1) A data steward or registrar owns data definitions and quality. (2) The IT administrator runs the systems, backups, and access. (3) A data protection officer or privacy lead handles FERPA / GDPR / DPDPA requests and breach response. (4) Functional owners — academic head, finance head, principal — sign off on what data their teams produce and consume. EDUCAUSE and ISTE both publish role-definition templates that schools can adapt; OpenEduCat's role-based access control maps cleanly onto these four roles out of the box.