School software can hold student identity, guardian contacts, attendance, assessment, fee, staff, visitor, and transport information. A security review should therefore be part of vendor selection and renewal—not a final question after the commercial decision is made.
No checklist guarantees security or compliance. It helps leaders ask consistent questions, collect evidence, and identify risks that need professional review.
Review security in layers
Look beyond a single certification or encryption statement. Identity, access, data handling, recoverability, monitoring, and response need to work together.
Identity and authentication
Ask how administrators, staff, students, and guardians sign in; how accounts are created and recovered; and what stronger authentication is available for privileged roles. Review session controls, failed-login handling, and the process for compromised accounts.
Account recovery should verify the person appropriately without exposing data or depending on an informal message to a developer.
Access control
The system should support roles aligned with real responsibilities and allow the institution to remove access promptly. Ask whether permissions can be scoped by campus, class, department, or child relationship where needed.
Request a demonstration of common changes: a teacher moves department, an accountant covers another campus, a guardian relationship changes, or an employee leaves. Review how privileged actions are logged.
Data lifecycle
Document what information the vendor collects, where it is processed and stored, which subprocessors are involved, and how data moves between systems. Ask about encryption in transit and at rest, secure exports, deletion, retention, and tenant separation.
Collecting less is also a security control. Confirm whether optional fields can be disabled and who can download large data sets.
Backups and recovery
“We take backups” is not enough. Ask what is backed up, how often, how copies are protected, how restoration is tested, and what recovery objectives the vendor commits to. Understand whether customer configuration, uploaded files, and audit history are covered as well as database rows.
Request evidence suitable for the decision’s risk level without expecting disclosure of details that would weaken security.
Monitoring and audit
Ask what security and operational events are monitored, how suspicious activity is investigated, and what audit history administrators can access. Important events may include privileged changes, bulk exports, authentication changes, and permission updates.
Logs must themselves have access and retention controls. More logging is not automatically better if nobody reviews meaningful signals.
Incident response
Review how the vendor identifies, contains, investigates, and communicates an incident. Contracts should define relevant notification routes, responsibilities, and escalation contacts. Ask when the process was last exercised and how customers receive updates.
The school also needs its own response plan. Identify who can disable accounts, contact the vendor, preserve evidence, communicate internally, and obtain legal or specialist advice.
Product and engineering practices
Ask how changes are reviewed and tested, vulnerabilities are handled, secrets are managed, dependencies are updated, and production access is controlled. Independent testing or certifications can support the review, but check their scope and date.
Compare statements with the vendor’s published security information and contractual commitments.
Availability and portability
Security includes reliable access and recoverability. Ask about service monitoring, maintenance communication, resilience, support during critical school periods, and data export if the institution changes provider.
Test whether exported records are usable, not merely available in an undocumented format.
Contract and governance
Clarify data roles, confidentiality, subprocessors, retention, deletion after termination, breach responsibilities, audit evidence, and change notification. Requirements vary by jurisdiction and institution, so obtain qualified legal, privacy, and security advice where appropriate.
Vendor checklist
- Authentication and recovery fit every user type.
- Privileged roles support stronger controls.
- Access can be scoped and removed promptly.
- Data locations, subprocessors, exports, retention, and deletion are understood.
- Encryption and tenant separation are explained.
- Backups are protected and restoration is tested.
- Meaningful events are monitored and auditable.
- Incident roles and communication are contractual and exercised.
- Engineering and vulnerability practices have current evidence.
- Availability, support, and data portability meet operational needs.
A good vendor welcomes precise questions and distinguishes current controls from future plans. Use this checklist alongside your institution’s risk assessment and professional advice. To review Scholva’s controls and responsibilities, visit Scholva Security or contact the team.
Related reading: Role-based access protects school data and School ERP migration checklist.