FIELD GUIDE / EVIDENCE FIRST

How to Evaluate Teacher, Student, Parent and Administrator Access

Evaluate role access with a school-owned matrix. For each teacher, student, parent or guardian and administrator role, define what the person needs to view, create, change, approve, export and share; then test account creation, role changes, exceptions, recovery and closure in the exact proposed configuration.

Reviewed draft · 14 September 2026

KEY TAKEAWAYS

What should the reader carry into the decision?

  1. The school should define roles from real responsibilities instead of accepting vendor labels without examination.
  2. Test denied actions as well as permitted actions; both results belong in the evidence record.
  3. Account creation, transfer, temporary access, recovery and closure need their own test cases.
  4. Administrative power should be mapped, approved and reviewed like any other access.
  5. Legal and privacy questions depend on the real arrangement and need appropriate advice.

Method and scope. Prepared from the cited public sources and the verified client facts available for this article.

Download the reusable worksheet →Send a prepared evidence request →
Decision exhibit for How to Evaluate Teacher, Student, Parent and Administrator Access
A structured evidence map for the decision described on this page.
01

What does role-based access mean in an evaluation?

NIST defines role-based access control as “a model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities.” For a school, that is a useful starting concept: access should follow a person's responsibility. It is not proof that a platform's roles are complete, correctly configured or appropriate for the school's policies.

Ask the vendor to explain how roles are created, combined and limited in the exact offer. Record whether permissions come from a fixed role, a custom role, a group, an individual exception or another mechanism. The school should be able to trace a visible action back to an agreed permission and a named approval owner.

02

What should each school role be able to see and do?

Build a matrix from real tasks. Rows might include attendance, timetable changes, assessment records, messages, contact details, reports and account settings. Columns should cover view, create, correct, approve, download and share. Complete the matrix for administrators, teachers, students and parents or guardians only where those roles are relevant to the school's proposed use.

Add a purpose and owner to every permission. A teacher may need to correct a record they created without gaining access to unrelated classes; a parent or guardian may need selected information about a linked learner without seeing internal staff notes. These are test scenarios, not statements about how any particular product works.

03

How should the school test minimum necessary access?

Test one permitted and one prohibited action for every high-risk matrix row. Sign in as the role, attempt the action, record the result and capture the configuration that produced it. Include bulk download, search across classes, attachment access, message recipients and shared-device behaviour. A correct screen is useful evidence only when the school knows which account, role and configuration produced it.

NIST SP 800-53 uses concepts such as account management, access enforcement and least privilege as a control vocabulary. A school can use those labels to organise questions, but should not claim NIST alignment unless the vendor supplies valid evidence for a defined scope. The evaluation record should describe what was actually tested.

04

What happens when a person's role or relationship changes?

Create lifecycle cases before a pilot: a teacher changes department, a temporary staff member's access expires, a learner changes class, a parent or guardian relationship changes, and a staff member leaves. For each case, define who requests the change, who approves it, how quickly it should take effect and what information must remain available for legitimate school purposes.

Test account recovery separately. Ask what identity checks occur, whether recovery changes other sessions, who can reset a privileged account and what record remains. A working password reset does not by itself show that the recovery process protects the right user or that old access has ended.

05

Which administrator powers need special evidence?

List actions that can affect many users or records: creating administrators, changing permissions, importing or exporting data, changing retention settings, viewing logs and connecting another application. Ask whether these powers can be separated between people, time-limited or reviewed. Record all dependencies, including vendor support actions that a school administrator cannot perform directly.

Google for Education's official privacy and security material is one example of a provider describing central controls, data access and administrative settings. Use it as evidence that these are reasonable categories to ask about, not as a benchmark that proves another platform has equivalent functions. Require product-specific documentation and a demonstration for the proposed configuration.

06

How should Malaysian personal-data context shape the questions?

Malaysia's Personal Data Protection Department sets out seven principles and lists six data-subject rights in its public FAQ. Use this general context to ask what personal data is used, for what purpose, who receives it, how accuracy and security are addressed, how long it is kept and how a request is handled. Do not use the checklist as a legal conclusion.

The actual legal roles and obligations depend on the school, vendor, contract, processing purpose and data flow. Ask the vendor to state its position and evidence in writing, then obtain appropriate advice for the arrangement. This article does not assign Easy Edu, a school or another provider a controller or processor role.

07

What belongs in the role-access sign-off?

For every role, record the approved matrix version, configuration evidence, test account, passed and failed cases, known exceptions, exception owner and decision date. A failed prohibited-action test is a blocker until it is resolved or the school knowingly accepts and documents the risk through its own process.

Set a re-review trigger as well as a date. Review access after major configuration changes, new integrations, new data categories or changes to school responsibilities. A matrix that was accurate at pilot start can become unreliable when the system or organisation changes.

QUICK ANSWERS

Frequently asked questions

Should schools copy a vendor's default role names?

Use vendor roles as inputs, then map them to the school's actual responsibilities. Two products may use the same label for different permissions, and one school may need a narrower or delegated role that the default label does not express.

What is the most important negative access test?

Test whether each role is blocked from a high-risk action it should not perform, such as viewing another class, bulk-exporting records or changing permissions. Choose the action from the school's data and responsibility matrix rather than using a generic test.

How often should role access be reviewed?

Set a routine review suited to the school's process and trigger an additional review after major role, product, integration or data changes. The review should compare actual accounts and exceptions with the approved matrix.

EXTERNAL CONTEXT

External sources explain category or evaluation context. They do not endorse Easy Edu or prove its product capabilities.

NEXT MOVE

Choose the next check

Use the related guide and verify the exact facts that apply.

Send Easy Edu a written evidence request