You are handing a supplier records about children. “Private, secure, reliable” is what every vendor writes, so it tells you nothing. Below is how it actually works, named specifically enough that you can check it — and, at the bottom, what we do not have.
Every record carries the school it belongs to, and every query is scoped to the school of whoever is signed in. A request for another school's record is answered as not found rather than not allowed — because refusing tells you the thing exists.
How: Tenant scope applied at the query, not filtered afterwards; cross-school reads return 404.
What a person can reach follows from their role through a single capability layer, rather than each screen deciding for itself. A permission that no page honours, or a page no permission guards, is a defect we can find rather than one a school discovers.
How: A capability map drives both the menu and the server-side gate, and a test refuses a permission with no reachable page.
Publishing a policy, withdrawing a document, changing what someone can see, exporting data — each leaves a record of who did it and when. Not because a regulation asks, but because the first question after anything goes wrong is what happened.
How: A server-side audit trail written by the API itself, not by the screen that called it.
The AI has no privileged view of your school. It uses tools chosen by the asker's role, scoped to the asker's school, and every consultation is recorded — so what the AI looked at can be inspected afterwards.
How: No AI tool accepts a school id from the caller; role is checked before execution and refusals are logged.
When something breaks we keep enough to fix it and nothing more. Tokens, email addresses, query strings and identifiers are stripped before an error is stored, and we do not record which person hit it.
How: Scrubbing runs before the write, not before the display — so the sensitive value never lands in the database.
Encrypted with AES-256 and — the part that matters — actually restored into a scratch database, with the row counts compared, and the steps written down. A backup nobody has restored is a hypothesis.
How: openssl AES-256 with a key held off the database host; a documented restore drill with the known traps listed.
Pages are served under a strict content security policy where every script must carry a per-request nonce, so an injected script does not run even if one is somehow introduced.
How: Nonce-based CSP minted per request; pages render dynamically so no page can ship without one.
Single sign-on against your identity provider, and access that ends when someone leaves — because the most common way school data escapes is an account nobody closed.
How: SSO against your provider; role and access changes recorded in the audit trail.
A page like this with no limits on it is a sales page. If you found one omission here you would be right to stop believing the rest, so here they are.
No SOC 2 report, no ISO 27001. The controls above are real and we will walk through any of them with your team, but we are not going to imply an audit we have not had. If your procurement requires one, tell us — it is a decision about timing, not something we can produce on request.
SSO is built and works, but connecting it to Google or Microsoft requires client credentials from your side. Until those are in place, staff sign in with a password and a second factor.
Backups are encrypted and restorable. Copying them off the server to a second location is configuration your school or ours has to switch on, and it is worth doing before it is needed rather than after.
Some of what a fifteen-year-old vendor has, we do not: a long incident history, a compliance department, a public status page with years behind it. What we offer instead is that the person who wrote the security model will answer your questions directly.
Transparent data practices, role-based permissions, and school-controlled retention. Designed with GDPR, FERPA, and COPPA-minded safeguards so families stay in control of student information.
Encryption in transit and at rest, least-privilege access, continuous monitoring, and secure object storage for message attachments — so sensitive school data never sits unprotected.
Production-ready data plane with Postgres, Redis-backed live sync, and health checks — so the school day keeps moving when teachers and families need skodle most.
A school can export everything held about one student, or erase it. Erasure defaults to a preview showing exactly what would go, and records a school is normally obliged to keep — attendance registers, safeguarding reviews, financial records — are held back and reported with the reason rather than quietly swept up. The school can override that; either way the decision is recorded.
skodle is a platform, not a law firm: retention duties vary by country, so these are defaults your school can change, not legal advice.