Schools trust SKOOLES with information about children. This page sets out, concretely, how we protect it. If you are evaluating SKOOLES and need more detail for a procurement review, email [email protected].
Tenant isolation
SKOOLES is multi-tenant. Every institution is a fully isolated tenant, enforced in the data layer of the application framework rather than by application code alone. A user authenticated to one institution cannot query, sync or address data belonging to another. Mobile synchronisation is scoped the same way: the token issued to a device carries the tenant and the application identity, and the sync service serves only the data streams that token authorises.
Identity and access
- Authentication uses OAuth 2.0 and OpenID Connect, with the authorisation code flow and PKCE on mobile clients. Credentials are never handled by the app itself.
- Access tokens are JSON Web Tokens signed with an industry-standard asymmetric algorithm. Signing keys are held in certificates, not in source code or configuration files.
- Authorisation is role and permission based, evaluated per request. Permissions are granular, so a teacher, a parent and an administrator see genuinely different data.
- Sessions can be revoked centrally. Because the apps are offline-first, a device that is offline applies the revocation the next time it connects, and until then it can still open data already synchronised to it. A device that must be cut off immediately should be handled through the institution’s own device management.
Encryption
- All traffic is encrypted in transit with TLS.
- Sensitive data is encrypted at rest with AES-256.
- On-device databases used for offline access are encrypted and cleared on sign-out.
- SkooNet supports end-to-end encrypted rooms, where message content is not readable by the server or by us.
Auditing and monitoring
Data operations are written to an audit log that records who changed what and when. Logs are retained for up to 12 months and are used to investigate suspected misuse. Structured application logging and health checks monitor service and database availability.
Backup and recovery
Data is backed up on a regular schedule and backups are encrypted. Deleted data is purged from backup rotation within 35 days. Because the mobile applications are offline-first, schools retain access to synchronised data on devices even during a server interruption, which materially reduces the operational impact of an outage.
Secure development
Changes move through source control and automated deployment pipelines. Input is validated at the API boundary, and the platform is built on a maintained application framework so that security fixes in the underlying stack reach us promptly.
Data protection posture
The platform is designed to support GDPR and FERPA obligations: data minimisation by module, role-scoped visibility, export and deletion facilities, audit trails, and a documented sub-processor list. Our commitments to institutions are set out in the Data Processing Agreement.
Reporting a vulnerability
If you believe you have found a security vulnerability, email [email protected] with the subject line Security. Please give us enough detail to reproduce the issue, and give us a reasonable opportunity to fix it before disclosing it publicly. We will acknowledge your report within five working days, keep you informed, and we will not pursue legal action against researchers who act in good faith and do not access or modify data belonging to others.
What we do not claim
We do not currently hold ISO 27001 or SOC 2 certification. We would rather say so plainly than imply otherwise. If certification is a procurement requirement for your institution, tell us and we will discuss timelines.