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, APIs, files, reports and background jobs. A tenant label in the interface is not evidence of isolation.
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
What retention, legal-hold, archive and verified deletion rules apply?
Test duties, not just role names.
Role-based access control should answer what a person may view, create, change, approve, export and administer. Review representative duties for teachers, admissions staff, finance staff, institute administrators and platform operators. Check that server-side authorization remains effective even when a user bypasses the visible interface.
| Control | Evidence to request | Warning sign |
|---|---|---|
| Least privilege | Role-to-permission matrix and a denied-action test | Broad access granted because it is easier to configure |
| Institute scope | Positive and negative tests across two synthetic institutes | Tenant context accepted only from a changeable request value |
| High-risk access | Named owner, reason, expiry and review evidence | Permanent super-admin access without review |
| Joiner/mover/leaver | Provision, role-change and revocation timestamps | 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 separation of duties. Review fee reversals, admissions rollback, identity correction, permission elevation, bulk export and institute lifecycle changes. Approval must be enforced by the service handling the action, not only by a button or written procedure.
- 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 direct API attempts and stale approvals as negative cases.
Make important events explainable.
Useful audit evidence connects the actor, institute, action, target, time, outcome and correlation reference. 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 retention and tamper-evidence claims are tested in the target environment.
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. Treat monitoring destinations, long-term retention and provider configuration as evidence-dependent; do not accept a roadmap statement as a live control.
- Critical security and isolation alerts have an accountable owner and response target.
- Credentials and elevated access have rotation and revocation procedures.
- Backup access, retention and restore ownership are documented.
- Incident evidence preserves correlation without exposing unrelated institute data.
- A recent rehearsal demonstrates containment, recovery and follow-up actions.
Record evidence, gaps and owners.
| Evaluation area | Decision question | Record before approval |
|---|---|---|
| Data boundary | Can institute isolation be shown across UI, API, files, exports and jobs? | Test reference, environment and unresolved gaps |
| RBAC | Do representative roles pass allowed and denied scenarios? | Role matrix, exceptions and review owner |
| Approvals | Are high-impact changes governed server-side? | Policy, approver separation and negative evidence |
| Audit | Can an authorized reviewer reconstruct an important action? | Retention, export, integrity and access evidence |
| Operations | Are monitoring, incident and restore responsibilities rehearsed? | Owner, last exercise, next review and residual 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.