Guide / Role access

How to evaluate teacher, student, parent and administrator access

Evaluate role access with a matrix the school writes itself. For teachers, students, parents or guardians and administrators, list what each must view, create, correct, approve, export and share, and what each must be refused. Then test it in the exact configuration offered: one permitted and one denied action for every risky cell, plus account creation, role changes, recovery and closure, keeping evidence of each result.

Published 14 September 2026 · Reviewed 18 September 2026 · EASY EDU SDN BHD

On this page10 sections

What are the key points of this guide?

Key takeaways

Define roles from the school's own responsibilities; treat a vendor's role names as inputs, not answers.
Test refusals as carefully as permissions. A correctly denied action is evidence too.
Give account creation, transfer, temporary access, recovery and closure their own test cases.
Map administrator powers separately, because one administrator can change many users at once.
Use Malaysian personal-data material as context, and take advice on the actual arrangement.

Who publishes this, and its scope

EASY EDU SDN BHD, part of ES PRODUCATION GROUPS BERHAD, publishes this vendor-neutral guide. Its timetable screens are illustrative and its modules are not yet confirmed, so put these questions to Easy Edu as to any vendor.

This guide covers the access matrix, account lifecycle and administrator powers. To map records and notifications first, use the school role map: who sees, changes and approves each record.

Vendor-neutral guide

Download the role-access worksheet Ask Easy Edu for its role model

What does role-based access mean in an evaluation?

Role-based access means permissions are attached to a role, such as teacher or guardian, rather than granted person by person. The NIST Computer Security Resource Center glossary defines role-based access control in the same terms: permitted actions are identified with roles, not individual identities. The idea is useful; it proves nothing about whether a product's roles are complete or fit the school. Ask how each permission is actually granted:

Fixed role: Which permissions come with it by default, and can the school narrow them?
Custom role: Who can create one, and is every change to it recorded?
Group: Does joining a class or department add permissions automatically?
Individual exception: Who approves it, when does it expire, and where is it listed for review?

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

Write the matrix from real tasks, then ask the vendor to demonstrate every cell in the configuration you would buy. Add a purpose and an owner to each permission. A teacher may correct a record they created without seeing unrelated classes; a guardian may see selected information about a linked child without seeing staff notes.

Role-access matrix: a starting point to replace with school policy
Role	View	Create	Correct	Approve	Export	Share
Teacher	Own classes' timetable, attendance, work and marks	Attendance, tasks and marks for own classes	Own entries, original kept in history	Only if the school delegates it	Own class lists; ask about bulk export	Messages to own classes and guardians
Student	Own timetable, work and released results	Submissions to own tasks	Own submission before the deadline	None	Own work, if allowed	Within own class spaces only
Parent or guardian	Linked child's attendance, released results, notices	Replies or absence notes, if enabled	Request correction of own details	Consent requests sent to them	Only as school policy allows; test the refusal	None
Administrator	School-wide, within the scope policy sets	Accounts, classes, timetable	Closed records, with a stated reason	Result release and role grants	Bulk data, with named approval	School-wide notices

How should the school test least-privilege access?

For every high-risk cell, test one action the role should perform and one it should be refused, such as opening another class, searching across year groups, bulk-downloading contact details or opening a message addressed to someone else. NIST SP 800-53 offers a neutral vocabulary for this (account management, access enforcement, least privilege); do not assume a product aligns with it unless the vendor documents which controls apply and to what scope.

01Sign in with a test account holding only the role under test.
02Perform the permitted action and note what the screen shows.
03Attempt the refused action and capture the refusal.
04Note the role, product version and settings that produced both results.

One permitted-versus-refused test, run for each high-risk cell of the role matrix.

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

Write the lifecycle cases before a pilot. For each one, name who requests the change, who approves it, how fast it should take effect and what history must stay available for legitimate school purposes. Test account recovery separately: a working password reset does not show that the right person regained access or that old sessions ended.

New starter: Who requests the account, who approves the role, and on which date access begins.
Department change: Old class access ends when the new role begins, not weeks later.
Temporary staff: Access carries an end date and closes on it without a manual step.
Guardian change: Who confirms a new or removed guardian link before any information is shown.
Account recovery: What identity check runs, who may reset a privileged account, and what record remains.

Which administrator powers need special evidence?

Some actions affect many users or records at once. For each, ask whether it can be split between people, time-limited and reviewed, and list any vendor support action a school administrator cannot perform directly. Google for Education's privacy and security centre shows one provider describing central administration and data-access controls for its own products; use it to see which categories are reasonable to ask about, not as proof that another platform has them.

Creating another administrator, or changing a role's permissions
Importing or bulk-exporting school records
Changing retention or deletion settings
Reading activity logs, and deciding who else may read them
Connecting another application to school data
Any action vendor support staff take on the school's behalf, and how the school is told

How should Malaysian personal-data context shape the questions?

Malaysia's Personal Data Protection Department sets out seven personal-data-protection principles under section 5(1) of Act 709, and its public FAQ lists six data-subject rights. Use that context to ask what personal data each role reaches, for what purpose, who receives it, how accuracy and security are handled, how long it is kept and how a request from a family is answered.

The legal roles themselves depend on the school, the vendor, the contract and the real data flow. Ask the vendor to state its position in writing and take appropriate advice on the arrangement. This guide does not assign Easy Edu, a school or any provider a controller or processor role.

Sources: the department's principles page and its public FAQ. Both are general Malaysian context, not a finding about any platform.

What belongs in the role-access sign-off?

A sign-off turns the tests into a decision someone owns. A failed refusal test is a blocker until it is fixed or the school knowingly accepts the risk through its own process. Record these fields for every role:

Role and matrix version: The role name and the dated version of the matrix it was tested against.
Actions tested: Permitted and refused actions, each with its observed result.
Exceptions: Each accepted exception and the person who owns it.
Tester and account: Who ran the test, with which test account, on which date and product version.
Evidence link: Where the screenshots or exported results are kept.
Re-review trigger: A major configuration change, a new integration, a new data category or a change in school responsibilities.

Quick answers

What do schools ask about evaluating role access?

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 give the same label different permissions, and a school may need a narrower or delegated role that no default label expresses.

What is the most important negative access test?

Check that each role is refused 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 own matrix rather than a generic list.

How often should role access be reviewed?

Set a routine review that suits the school's calendar, and add a review after any major change to roles, product, integrations or data. Each review compares actual accounts and exceptions with the approved matrix.

External context

Which outside sources does this guide cite?

Method and scope. A vendor-neutral checklist built from the public sources listed above. It does not describe Easy Edu features, and the sources do not describe or endorse Easy Edu.

On this page

10 sections

Email Easy Edu

Next move

Where should the completed matrix go next?

Take the tested matrix into the role map guide to check records and notifications together, then ask each vendor, Easy Edu included, for written evidence against it.

Build the full school role map Send Easy Edu an evidence request

EVERYTHING ON THIS SITE