SCHOOL OPERATIONS · ACCESS GOVERNANCE
School ERP Access Review Checklist: Who Can See, Change, Print and Export What?
A practical review of active users, current responsibilities, record access, exports, sensitive data and stale permissions.
Conceptual product view · no customer records or performance figures
THE SHORT ANSWER
Review access by active user and real responsibility, not simply by inherited job title. Check viewing, creation, editing, deletion, approvals, printing and export as separate permissions; pay special attention to student, fee and staff information. Remove stale access after role changes, use audit history as supporting evidence and document exceptions with an approver and review date.
01 / ACTIVE USERS
Start with the people who can sign in today.
Export or otherwise review the current user list through the school’s approved process. Compare it with active staff, temporary coverage and authorised external roles, if any. Look for duplicate identities, accounts that are no longer needed and users whose responsibilities have changed since access was first granted.
Do not assume that an account is safe because no one remembers using it. Confirm its owner and business purpose. If identity or current employment is uncertain, route it to the designated approver rather than leaving a broad account active indefinitely.
02 / RESPONSIBILITY MAP
Connect every permission to work the person actually performs.
Ask each manager to confirm the tasks their staff carry out and which records those tasks require. Map permissions to functions rather than job-title shorthand. A person who changes departments may retain an old permission even though the original need has ended.
Record exceptions, such as temporary cover or a specialised review role, with an approver and an end date where practical. Avoid granting broad administrator rights to solve a short-term access problem. Confirm the product supports the necessary boundary before treating a role name as evidence.
03 / ACTION-LEVEL REVIEW
Inspect viewing, changes, approvals and exports separately.
Review view access independently from creating, updating or deleting records. Approval rights may need another control, and printing/exporting can move information beyond the system. Identify who can perform each action on sensitive student, fee and employee information.
Test a small set of representative tasks with appropriate accounts. Confirm that staff can do the work they need and that unrelated data is not exposed. Where the permission model lacks a distinction the school wants, record the gap and agree an interim procedure rather than assuming the control exists.
04 / SENSITIVE AREAS
Give student, finance and staff records a more deliberate review.
Student and family details, financial records and employee compensation may require narrower access than routine administrative information. Identify the roles that need each category and review exports, print access and shared workstations as well as on-screen views.
Consider the full journey of information after it is downloaded. Specify where an export may be stored, who can share it and how it is disposed of. Software permission cannot control a file copied into an unapproved location, so institutional handling procedures matter too.
05 / CHANGES & HISTORY
Remove stale grants and use history to support—not replace—the review.
When staff transfer, take leave, cover a role or exit the institution, trigger an access check. Revoke or revise permissions through a controlled process and confirm which individual is responsible for completion. Shared accounts make it harder to establish ownership and should not be used as a substitute for an account lifecycle.
Where the product retains user activity history, confirm which actions it records, how reviewers can access it and the relevant retention. History can help investigate a specific question, but it is not a substitute for approved access policy or a complete audit conclusion.
06 / REVIEW RECORD
Finish with decisions, exceptions and the next review date.
Record who performed and approved the review, what was examined, which permissions changed and what remains unresolved. If an exception remains temporarily, name its owner and revisit date. This creates continuity when the next review begins and helps explain why a permission was retained.
A checklist is useful only when acted upon. Share the outcome with the relevant managers without exposing more personal information than necessary. Update the process when the school changes staffing, policies or product configuration.
A FIELD GUIDE FOR YOUR TEAM
A periodic school access review
Use these checks after staffing changes and on a regular schedule. The reviewer should be able to explain both why access remains and what changed.
| Lens | Question to ask | What to record |
|---|---|---|
| ACTIVE USERS | Start with the people who can sign in today. | A reconciled list of named accounts and current owners. |
| RESPONSIBILITY MAP | Connect every permission to work the person actually performs. | A role-to-task mapping with every exception approved and bounded. |
| ACTION-LEVEL REVIEW | Inspect viewing, changes, approvals and exports separately. | A verified permission test for each high-impact action. |
| SENSITIVE AREAS | Give student, finance and staff records a more deliberate review. | A sensitivity-based access and export decision for each record group. |
| CHANGES & HISTORY | Remove stale grants and use history to support—not replace—the review. | A tracked access change and confirmed user-history scope. |
| REVIEW RECORD | Finish with decisions, exceptions and the next review date. | A dated sign-off with completed changes, exceptions and next review. |
CODEPEX IN CONTEXT
Useful guidance begins with clear scope.
School ERP declares roles and permissions, access controls and user activity history. Exact permission granularity and audit detail should be demonstrated and confirmed. Do not infer a specific quarterly review feature or automated offboarding behavior; the school owns the review process.
Product-specific statements are based on the current owner-controlled capability declaration. Ask CodePex to confirm any institution-specific configuration or unlisted requirement.