SuitonX Security
Institutional systems need institutional controls.
SuitonX is designed around controlled access to institutional workflows and information, based on each person's responsibility in the organisation.
01
Institution
Every user belongs to an institution. Requests are checked against it.
02
Role
Faculty, HOD, principal, accountant, warden, student, parent and more.
03
Permissions
What that role may view or change, checked on the server.
04
Authorized workflows
Only the screens and actions the role is responsible for.
Data protection principle
Institutional information should be available to the people who need it, and controlled for those who do not.
Role-based access
Access follows responsibility.
Access to SuitonX workflows is controlled according to authenticated users, their roles and their permissions. The server checks permission on each request. Hiding a menu item is never the control.
Students and administration
Students work in the student workspace. Staff and administrative interfaces refuse student sessions.
Faculty and HOD
Faculty work in their own courses and with their own mentees. An HOD also sees their department's faculty, leave and continuity.
Parent and student
A parent has a separate account. Access exists only through a verified parent–student link, re-checked on every request. Knowing a student's ID is not enough.
Management and principal
Both see institution-wide views. The principal acts on routed approvals. For management, acting is an explicit grant. Individual salary detail stays restricted.
Operational offices
The exam office owns exam operations and the accountant owns finance transactions. Leadership reads and reports. It does not stand in as a fallback operator.
Platform administration
Institution roles, including college administrators, cannot reach platform governance and cannot raise their own role.
We do not publish our internal permission matrix. During implementation, roles are mapped to your institution's structure with your IT and administrative leads.
Institution boundaries
Institution-scoped by design.
SuitonX is designed around institution-scoped data and authorization boundaries. Records belong to an institution, and requests are checked against the signed-in user's institution.
Tested, not certified
Cross-institution access checks are part of the product's automated test suite. That is an engineering practice, not a third-party certification, and we describe it that way.
Suspension without deletion
Suspending an institution stops its members signing in without deleting its records.
Authentication
Every session starts with a known user.
- Separate sign-in for staff, students, parents, alumni and applicants
- Passwords stored as salted hashes, with a minimum strength policy
- Sign-in attempts rate-limited
- Time-limited signed sessions
- Accounts can be deactivated, and members of a suspended institution cannot sign in
Auditability
A record of who acted, and what changed.
Workflows where accountability matters write activity records. Platform administrators can review an audit trail of privileged platform actions.
- Examinations, marks and results
- Attendance corrections
- Finance
- HR
- Admissions
- Hostel, transport and library
- Outcome-based education records
- Platform administration
Conceptual architecture
Controls sit between every user and every record.
A request passes authentication and a permission check before it reaches institutional information or any connected service.
01Users
Staff, students, parents, alumni and applicants, each with their own entry point.
02Authentication
Signed, time-limited sessions after sign-in. Unauthenticated requests are refused.
03Role and permission controls
Each request is checked against the user's role and permissions on the server.
04SuitonX application
Academic, examination, finance, people and campus workflows.
05Institution-scoped information
Records belong to an institution and are read within that boundary.
06Controlled services and integrations
Configured by platform administrators, with credentials masked and changes audited.
Conceptual only. Hosting, network and infrastructure details are discussed with your IT team, not published.
Data protection
Protection starts with who can see what.
Access boundaries
Role, department and institution scope decide what a person can see, before any screen loads data.
Need-to-know views
Individual salary detail is restricted from leadership views. Anonymous surveys hide respondent identity in results and exports. Grievance cases carry confidentiality levels.
Controlled administration
Platform governance is separate from institution roles. The last platform administrator cannot be removed or demoted, and integration credentials are never displayed.
Deployment, transport security and recovery
These depend on how and where your SuitonX environment is deployed. We work through them with your IT team during planning rather than publishing generic figures here.
Precision
What we claim, and what we do not.
Enterprise trust comes from precise statements. If your procurement process needs a security questionnaire answered, we answer it specifically.
We state
- Role-based access to workflows
- Permission checks on the server for each request
- Institution-scoped data and authorization boundaries by design
- Authenticated, time-limited sessions
- Activity records in the workflows listed above
- Masked integration credentials
We do not claim
- ISO 27001, SOC 2 or any other certification
- GDPR or HIPAA certification
- Certified or guaranteed tenant isolation
- Uptime percentages or service-level guarantees
- Backup frequencies or recovery-time figures
- Immutable or complete audit coverage
Want to discuss your institution's IT and security requirements?
Bring your IT team and your questions. We will walk through roles, institution boundaries and deployment, and answer what we can about your campus.