| Field | Details |
|---|---|
| Product | Edminhub |
| Document Type | Access Control Matrix |
| Version | 1.0 |
| Effective Date | 29 April 2026 |
| Contact | info@simplesoftwaredevelopment.com | www.simplesoftwaredevelopment.com |
| Address | 131 Continental Dr, Suite 305, Newark, Delaware |
1. Purpose
This Access Control Matrix explains the standard user roles and permission principles used within Edminhub. It is intended to help schools understand how access to learner, parent, teacher, academic, attendance, disciplinary, document, and administrative information should be controlled.
The matrix supports the Edminhub Security and Privacy Statement, Data Processing Agreement, Child Data Protection Statement, Data Retention Policy, Incident Response Procedure, and SaaS Subscription Agreement. It does not replace the school's own internal access governance, employment controls, safeguarding processes, or legal obligations.
2. Access Control Principles
| Principle | Meaning |
|---|---|
| Least privilege | Users should only receive the minimum access reasonably required to perform their authorised duties. |
| Role-based access | Access is assigned by role, function, and school responsibility rather than by personal preference. |
| School accountability | The school is responsible for deciding which school users should have which roles and for keeping role assignments accurate. |
| Separation of duties | Sensitive actions, such as user administration, permission changes, financial administration, discipline administration, and publishing of academic records, should be limited to authorised users. |
| Auditability | Important user actions should be logged where technically supported, especially for administrative, academic, disciplinary, and permission-related activities. |
| Timely removal | User access should be removed or changed promptly when a user leaves the school, changes role, or no longer requires access. |
| No shared accounts | Users should not share accounts, passwords, or credentials. Each person should access Edminhub using their own authorised account. |
3. Permission Legend
| Code | Permission Meaning |
|---|---|
| N | No access |
| V | View only |
| C | Create new records |
| E | Edit existing records |
| D | Delete records, where enabled and appropriate |
| A | Approve, authorise, publish, or finalise |
| M | Manage configuration, roles, settings, or administrative functions |
| S | Support access, limited to technical support, security, maintenance, or troubleshooting |
4. Standard Role Definitions
| Role | Description |
|---|---|
| Simple Software Development Platform Owner | Internal owner role used by Simple Software Development LLC for platform administration, infrastructure management, security, billing, service operation, and emergency support. This role should be tightly restricted. |
| Edminhub Support Administrator | Internal support role used for troubleshooting, customer support, limited data checks, configuration assistance, and incident support. Access should be used only where required and restricted to authorised personnel. |
| School Super Administrator | Highest school-level administrative role. Usually assigned to the principal, school owner, or delegated senior administrator. Can manage school setup, users, roles, and key records. |
| Principal / Head of School | Senior leadership role with broad visibility over academic, attendance, disciplinary, learner, teacher, and school reporting information. User management may be limited depending on school policy. |
| Deputy Principal / Senior Management | Senior operational role with broad view and limited management rights over academics, attendance, discipline, and reports. |
| Head of Department | Department or phase-level role for overseeing teachers, subjects, classes, marks, attendance trends, and academic progress within assigned areas. |
| Class Teacher / Homeroom Teacher | Teacher responsible for a class or register group, usually with access to learner information, attendance, communication, and limited discipline or academic information for assigned learners. |
| Subject Teacher | Teacher responsible for assigned subjects or classes. Access is normally limited to assigned learners, subject marks, attendance where enabled, and related communication. |
| School Administrative Staff | Office or admissions staff role for learner records, parent details, enrolment, documents, and school administration. Access to academic or disciplinary details should be limited according to school policy. |
| Finance / Billing Staff | Role for finance-related school functions if enabled. Should only access billing, account, invoice, or payment-related information and limited learner/parent data needed for those functions. |
| Parent / Guardian | External user role for viewing information relating only to their own child or children, where enabled by the school. |
| Learner | External user role for viewing the learner's own school-related information, where enabled by the school. |
| Auditor / Read-Only Reviewer | Temporary or restricted role for review, inspection, audit, or governance purposes. Access should be time-bound and view-only unless otherwise authorised. |
5. Access Control Matrix
The matrix below is the recommended standard baseline. Final configuration may vary depending on the school's selected modules, contract, implementation decisions, and legal or operational requirements. Access should always be limited to what is appropriate for each user's actual duties.
| Module / Function | Platform Owner | Support Admin | School Super Admin | Principal | Deputy / SMT | HOD | Class Teacher | Subject Teacher | Admin Staff | Finance | Parent | Learner | Auditor |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| School profile and configuration | M | S | M | V/E | V/E | V | N | N | V/E | V | N | N | V |
| User accounts and role assignment | M | S | M | V | N | N | N | N | N | N | N | N | V |
| Learner core records | S | S | C/E/D | V/E | V/E | V | V/E | V | C/E | V | V limited | V own | V |
| Parent / guardian records | S | S | C/E/D | V/E | V/E | V | V/E | V | C/E | V | V own | N | V |
| Teacher and staff records | S | S | C/E/D | V/E | V/E | V | N | N | C/E | N | N | N | V |
| Grade, class, and subject setup | S | S | M | V/E | V/E | V/E | V | V | V/E | N | N | N | V |
| Class allocation | S | S | M | V/E | V/E | V/E | V/E | V | C/E | N | N | V own | V |
| Subject allocation | S | S | M | V/E | V/E | V/E | V | V/E | C/E | N | N | V own | V |
| Attendance capture | S | S | M | V/E | V/E | V/E | C/E | C/E | C/E | N | V own | V own | V |
| Attendance reporting | S | S | M | V | V | V | V | V assigned | V | N | V own | V own | V |
| Academic marks and assessments | S | S | M | V/A | V/A | V/A | V assigned | C/E assigned | N | N | V own child | V own | V |
| Report comments and publishing | S | S | M | A | A | A | C/E assigned | C/E assigned | N | N | V published | V published | V |
| Discipline incident capture | S | S | M | V/A | V/A | V/A | C/E assigned | C/E assigned | C/E | N | V limited if enabled | V limited if enabled | V |
| Discipline outcomes and sanctions | S | S | M | A | A | A | V/E limited | V limited | V/E limited | N | V limited if enabled | V limited if enabled | V |
| Documents and attachments | S | S | M | V/E | V/E | V/E | C/E assigned | C/E assigned | C/E | V limited | V own child | V own | V |
| School notices and communication | S | S | M | C/E/A | C/E/A | C/E | C/E assigned | C/E assigned | C/E | N | V/receive | V/receive | V |
| Parent portal functions | S | S | M | V | V | N | V assigned | V assigned | V limited | V limited | V own | N | V |
| Learner portal functions | S | S | M | V | V | N | V assigned | V assigned | V limited | N | N | V own | V |
| Finance / billing if enabled | S | S | M | V | V | N | N | N | V limited | C/E/M | V own | N | V |
| Audit logs and activity history | M | S | V/M | V | V | V limited | N | N | N | N | N | N | V |
| Security settings | M | S | M | V | N | N | N | N | N | N | N | N | V |
| Data export | S | S | M | A | A limited | N | N | N | A limited | A limited | N | N | V limited |
| Data deletion / archival | S | S | A/M | A | A limited | N | N | N | A limited | N | N | N | V |
| Support requests | M | S | C/E | C/E | C/E | C/E | C/E | C/E | C/E | C/E | C | C | V |
| System administration and infrastructure | M | S | N | N | N | N | N | N | N | N | N | N | N |
6. Recommended Approval Rules
| Access Request | Recommended Approval Requirement |
|---|---|
| New school user account | School Super Administrator or Principal approval. |
| Principal or Super Administrator access | Written approval by school owner, governing body representative, or authorised executive contact. |
| Finance role access | Written approval by the school's authorised finance or administrative contact. |
| Parent or guardian access | School must verify the parent or guardian relationship before granting access. |
| Learner access | School must decide whether learner portal access is appropriate for the learner's age, grade, and internal policies. |
| Auditor or reviewer access | Must be time-bound, view-only where possible, and approved by the school. |
| Simple Software Development support access | Should be limited to troubleshooting, security, maintenance, incident response, or agreed support activities. |
| Emergency access | May be used only where reasonably required to protect service availability, security, data integrity, or customer support. Emergency actions should be reviewed afterwards where practical. |
7. Provisioning, Review, and Removal Process
User provisioning
The school should only request or create access for users who require Edminhub for legitimate school administration, academic, communication, or support purposes. Role assignments should be based on the user's actual duties.
Access review
The school should periodically review users, roles, and permissions. A practical minimum is once per school term, after major staffing changes, and before the start of each academic year.
Access removal
The school should remove or amend access promptly when a staff member, contractor, learner, parent, guardian, or other user leaves, changes role, or no longer requires access.
Privileged access
Privileged access should be restricted to a small number of authorised users. Privileged users should use strong passwords and, where available, multi-factor authentication.
Support access
Simple Software Development LLC may access configuration, logs, metadata, or Customer Data where reasonably necessary to provide support, maintain the service, investigate incidents, protect the platform, or comply with legal obligations. Such access should be limited to authorised personnel and appropriate purposes.
8. Customer Responsibilities
- Approve, assign, review, and remove school user access appropriately.
- Ensure users only receive access required for their authorised school duties.
- Verify parent, guardian, learner, staff, contractor, or auditor identity before granting access.
- Ensure parent or guardian access is granted only to persons lawfully entitled to view learner information.
- Prevent shared accounts, weak passwords, unmanaged devices, and unauthorised internal access.
- Notify Simple Software Development LLC promptly if unauthorised access, credential compromise, misuse, or incorrect role assignment is suspected.
- Maintain internal policies governing learner confidentiality, discipline records, academic records, and parent communication.
- Ensure that all personal information entered into Edminhub has been collected and processed lawfully.
9. Important Limitations
- This Access Control Matrix is a standard baseline and may not reflect every configuration, feature, module, or customisation available in Edminhub.
- Simple Software Development LLC does not decide which school employees, parents, guardians, learners, contractors, or reviewers should receive school-level access unless separately agreed in writing.
- Simple Software Development LLC is not responsible for unauthorised access caused by shared credentials, incorrect school role assignment, failure to remove users, insecure school devices, compromised email accounts, or school-level misuse of the platform.
- No access control system can guarantee complete prevention of all unauthorised access, misuse, cyber incidents, human error, or insider risk.
- Nothing in this document expands Simple Software Development LLC's liability beyond the limits agreed in the applicable SaaS Subscription Agreement, Data Processing Agreement, or other written agreement with the school.
10. Compliance Position
Edminhub is designed to support responsible school administration and privacy-aware access control. Simple Software Development LLC aims to align Edminhub with recognised good practices in information security, privacy, and secure application administration.
Unless specifically stated in writing, Edminhub should not be interpreted as certified under ISO/IEC 27001, ISO 9001, SOC 2, Cyber Essentials, GDPR, POPIA, COPPA, or any other formal certification or regulatory approval scheme.
11. Review and Updates
Simple Software Development LLC may update this Access Control Matrix from time to time to reflect platform changes, new modules, security improvements, implementation experience, or legal and operational requirements.
12. Contact
Questions about Edminhub access control, security, privacy, or user permissions may be directed to:
Simple Software Development LLC
Product: Edminhub
Email: info@simplesoftwaredevelopment.com
Website: www.simplesoftwaredevelopment.com
Address: 131 Continental Dr, Suite 305, Newark, Delaware