Ask where school data can travel.
Map each category of sensitive information—student, guardian, staff, fee, attendance, health and support data—to the people, systems and exports that may use it. Confirm how the product separates institutes across screens, software connections (APIs), files, reports and automatic background tasks. Displaying an institution’s name on a screen does not prove that its data is kept separate.
Scope
Which institute, campus, programme and academic period does each action apply to?
Storage
Where are records, files, backups and generated exports held, and for how long?
Movement
Which integrations, support processes or downloads can move data outside its normal boundary?
Deletion
How long are records kept, when must they be preserved for legal reasons, how are they archived and how is deletion verified?
Test duties, not just role names.
Role-based access control (RBAC) determines what each staff role may view, create, change, approve, export and administer. Review representative duties for teachers, admissions staff, finance staff, institute administrators and platform operators. Check that the system’s permission checks still work when someone bypasses the normal screens.
Swipe for more columns →
| Control | Evidence to request | Warning sign |
|---|---|---|
| Least privilege | A list of what each role may do, with a test showing a refused action | Broad access granted because it is easier to configure |
| Institute scope | Tests of permitted and refused actions across two fictional institutions | The system relies only on an institution identifier that the requester can change |
| High-risk access | Named owner, reason, expiry and review evidence | Permanent super-admin access without review |
| Staff joining, changing jobs or leaving | When access was granted, changed and removed | Departed users remain active or shared accounts are used |
| Exports | Permission, purpose, expiry and download evidence | Exports bypass the controls applied to the screen |
Separate authority from convenience.
High-impact actions should identify who requested the change, who may approve it and what happens when policy requires different people to request and approve the action. Review fee reversals, admissions rollback, identity correction, permission elevation, bulk export and institute lifecycle changes. The system handling the action must check approval; a button or written procedure alone is not enough.
- Define which actions require one approver, two-person control or additional evidence.
- Prevent requesters from approving their own restricted action.
- Retain rejection, expiry, cancellation and resubmission history.
- Show the user when an approval request was created instead of implying that live data changed.
- Test that direct software requests and expired or no-longer-valid approvals are refused.
Make important events explainable.
Useful audit records show who acted, which institution and record were involved, what happened, when and the result. A reference number connects related events. Sensitive before-and-after values should be protected rather than copied indiscriminately. Ask how authorized reviewers search, export and verify evidence, and how the system prevents silent changes to retained history.
- Choose one high-impact workflow and trace it from request to final outcome.
- Verify denied and failed attempts appear where policy requires them.
- Confirm timestamps, actor identity and institute context remain consistent.
- Export a privacy-safe evidence pack and verify its expiry and download controls.
- Ask how the supplier demonstrates, in the system you will use, that records are kept for the agreed period and changes to audit history can be detected.
Connect controls to an owned response.
Preventive controls do not replace operational readiness. Identify who receives alerts, who can contain access, how a school is informed, how backups are protected and when restore exercises last passed. Ask for proof of where alerts are sent, how long records are kept and how providers are configured. A future plan is not a safeguard operating today.
- Critical security and isolation alerts have an accountable owner and response target.
- Passwords, access keys and extra permissions have procedures for replacement and removal.
- Backup access, retention and restore ownership are documented.
- Incident records link related events without exposing another institution’s unrelated data.
- A recent rehearsal demonstrates containment, recovery and follow-up actions.
Record evidence, gaps and owners.
Swipe for more columns →
| Evaluation area | Decision question | Record before approval |
|---|---|---|
| Data boundary | Can separation between institutions be shown across screens, software connections, files, downloads and automatic tasks? | Test reference, environment and unresolved gaps |
| RBAC | Do tests confirm what each role is allowed to do and what it must be refused? | Role matrix, exceptions and review owner |
| Approvals | Does the system enforce approval for high-impact changes? | Policy, separate requester and approver where required, and proof of refused actions |
| Audit | Can an authorized reviewer reconstruct an important action? | Retention, export, integrity and access evidence |
| Operations | Are monitoring, incident and restore responsibilities rehearsed? | Responsible person, last practice exercise, next review and remaining risk |
Classify every answer as demonstrated, documented, planned or not available. Agree who owns each gap and when it affects pilot or production readiness. This keeps a procurement checklist from becoming an unsupported security promise.