You are handing us children’s records.
Names, photographs, health notes, who is allowed to collect whom. That deserves a straight account of how it is protected — and of what we have not built yet.
What is actually in place
Each one in plain words first, then the detail your IT person or auditor will want.
One school cannot see another
Every school's records are walled off from every other school's inside the database itself, not merely in the application code above it.
Every table carrying school data has row-level security switched on, with a policy that fails closed: if the request has not established which school it belongs to, the query returns nothing at all rather than everything. The application connects as a restricted database role for which those policies are enforced, and the school identity is set per transaction so it cannot leak between pooled connections.
Passwords are not recoverable, by us or anyone
We cannot tell you your password, because we never hold anything we could read.
Passwords are hashed with argon2id, a memory-hard algorithm designed to make large-scale guessing expensive. A leaked database does not hand an attacker working logins.
A stolen session is detected and killed
If someone copies a signed-in session, using it shuts the whole session down.
Sign-in issues a short-lived access token and a rotating refresh token. Each refresh mints a new one and retires the old. If a retired token is ever presented again — the signature of a copied session — the entire session family is revoked rather than quietly renewed.
Staff see their own classes, not the whole school
Access follows the job. A class teacher does not get the fee ledger.
Roles gate whole areas of the product, and finer checks run underneath — a teacher's own classes, a student's own branch. This is the control the DPDP readiness check asks about, because it is the one preschools most often lack when records live in shared drives.
A photo is checked against consent before it moves
A child's photo cannot reach a parent without a consent check passing first.
Consent is recorded in an append-only ledger — entries are added, never edited or deleted — so what a parent agreed to, and when, can be shown later rather than asserted. Publishing a daily report reads that ledger before any image is shared.
The financial trail cannot be quietly rewritten
Fee entries, attendance and consent records are append-only by design.
Corrections are added as new entries rather than edits to old ones, enforced in the database rather than by convention. Money is held as whole paise in integer arithmetic, so totals do not drift the way decimal rounding lets them.
Files never become public URLs
Photos and documents are served through the application, behind your login.
Uploads are stored privately and streamed back through the API on each request, so a link cannot be forwarded to someone outside the school and keep working.
Checked on every change
Security checks run automatically before code can ship.
Continuous integration runs vulnerability scanning of Go dependencies and container images, secret scanning to stop credentials being committed, and an integration test that proves one school's connection genuinely cannot read another's rows.
What we do not claim
Most security pages only list strengths. Here is the other half, because you are going to find out eventually and it is better that you hear it from us during evaluation than discover it afterwards.
- No security certification
- We do not hold SOC 2, ISO 27001 or any equivalent audit. If a certification is a hard requirement for your group, we are not there yet and will say so rather than imply otherwise.
- Backups are operator-run, not automatic
- Backup and restore are documented procedures a person runs. There is no scheduled backup job and no tested disaster-recovery time. This is on the roadmap and is not true today.
- No encryption-at-rest claim
- We are not going to claim database-level or key-managed encryption at rest, because we have not implemented and documented it. Passwords and session tokens are hashed, which is a different and narrower thing.
- No uptime guarantee yet
- The platform is pre-launch. We are not publishing an availability percentage we have no operating history to support. A formal service level can be agreed for a multi-branch contract.
Found something? Tell us
If you believe you have found a vulnerability, email hello@kibiscope.com with “Security report” in the subject. We will acknowledge it, and we will not pursue anyone who reports a genuine issue in good faith and does not access or change data that is not theirs.
How we handle personal data, including your rights and our Grievance Officer, is set out in the Privacy Policy. If you want to check your own school against the DPDP Act, the readiness check takes about five minutes.