Trust & Security

Security is part of the product architecture.

OarClass handles information that schools depend on every day. Our security approach is built around controlled access, separation between institutions, secure development, careful handling of school data and clear processes for identifying and responding to security concerns.

01 Role-based access Access follows responsibility.
02 School and tenant boundaries Institution data remains logically separated.
03 Secure production access Administrative access is restricted.
04 Security throughout development Testing and review are part of delivery.

Security across the OarClass platform.

Security controls work together rather than relying on one feature. OarClass combines identity, permissions, institution boundaries, application controls, infrastructure safeguards and operational processes to reduce unnecessary access and protect the systems used by schools.

01

Identity and access

OarClass accounts are authenticated before access is provided. Permissions are associated with user roles so administrators, teachers, students, parents and accounts teams can work within the areas relevant to their responsibilities.

02

School and tenant isolation

OarClass is structured around institutional boundaries. Data access is designed to remain associated with the relevant school or tenant rather than being exposed as one unrestricted platform-wide dataset.

03

Permission-based workflows

Sensitive administrative, academic and financial functions are intended to be available only to users whose assigned role and permissions require them.

04

Encrypted connections

Production web traffic is served using HTTPS/TLS to protect data travelling between supported clients and OarClass services.

05

Restricted production access

Access to production infrastructure and administrative systems is restricted to authorised personnel with a legitimate operational need.

06

Operational logging

Relevant application, security and infrastructure events may be logged to support troubleshooting, investigations and the detection of unusual or unauthorised activity.

Security begins before code reaches production.

OarClass development uses automated validation and review processes designed to identify regressions, dependency risks and security issues before changes reach production.

01 Development New functionality is developed within the OarClass application architecture and existing permission model.
02 Automated testing Automated tests help identify application regressions and unexpected behaviour before release.
03 Dependency and code checks Dependency and source checks may be used to identify known vulnerabilities or unsafe changes.
04 Release validation Production changes are expected to pass the applicable delivery and validation process before deployment.
05 Ongoing improvement Security controls and technical safeguards are reviewed as the platform, infrastructure and risk profile evolve.

Protecting school information beyond login.

OarClass security also considers what happens after a user is authenticated: which information they can access, how data is processed, how systems are restored and how incidents are handled.

01

Data minimisation

OarClass aims to process the information needed to provide the selected platform functionality rather than collecting unrelated school or student information.

02

Backup and recovery

Backup and recovery processes are used where appropriate for production systems to support restoration after relevant technical failures or data-loss events.

03

Data retention and deletion

Personal information is retained according to the purposes and obligations described in our Privacy Policy, customer agreements and applicable law. Users can also follow our published data-deletion process.

04

Service providers

Providers that process customer data on behalf of OarClass are expected to operate under appropriate contractual and security obligations relevant to the services they provide.

05

Security incidents

When a confirmed security incident affects customer personal data, OarClass follows an investigation and response process and provides notifications where required by applicable law or contractual obligations.

Security also depends on how accounts are managed.

OarClass protects the platform, but schools and users also control important parts of the security model, including account access, permissions and device security.

OarClass responsibilities

01 Operate and secure the OarClass platform.
02 Maintain role and tenant access controls.
03 Restrict production and administrative access.
04 Maintain security and incident-response processes.

Customer responsibilities

01 Assign roles and permissions carefully.
02 Remove access when users are no longer authorised.
03 Protect credentials and institution-managed devices.
04 Report suspected compromise promptly.

Found a security issue? Tell us responsibly.

We welcome good-faith reports of potential vulnerabilities. Please give us enough information to reproduce and investigate the issue, and avoid actions that unnecessarily expose user or school data.

01 Do not access more data than is necessary to demonstrate the issue.
02 Do not modify, delete or damage school or user data.
03 Do not intentionally disrupt OarClass availability or other users.
04 Give OarClass reasonable time to investigate before public disclosure.

Clear about what we claim — and what we don't.

Security architecture OarClass uses role-based permissions, institution boundaries and restricted operational access as part of its security architecture.
Data processing terms Institutional processing responsibilities are described in the OarClass Data Processing Agreement.
Certifications OarClass does not currently claim SOC 2, ISO 27001 or other independent security certifications unless a certification is explicitly published by OarClass.
Future assurance As OarClass grows, additional security reviews, documentation, independent testing and formal assurance programs may be introduced.

Security is only one part of trust.

Review how OarClass handles privacy, institutional processing, acceptable use and platform availability.