What actually protects a student record.

Encryption at rest

Personal fields are encrypted individually before they are written, not merely protected by disk encryption. That covers names, guardian names, phone numbers, email addresses, postal addresses, dates of birth, blood groups, medical notes and teacher remarks on report cards. Anyone reading the database directly — including a stolen backup — sees ciphertext.

Encrypted columns are still searchable. Alongside each one we store a keyed hash of the normalised value (a blind index) under a key separate from the application key, so an exact-match lookup works without ever storing the value in the clear. The two keys are held apart; neither alone is enough.

Tenancy isolation

Every record belongs to an institution, and that filter is applied globally at the query layer rather than remembered by each developer at each query. A URL naming another school's exam, section or student returns "not found" — deliberately not "forbidden", because a 403 would confirm the record exists.

Passwords and sessions

• Passwords are hashed with a modern adaptive algorithm and are never recoverable.
• Sign-in is rate-limited by address and by account.
• Sessions are stored server-side; the cookie carries an identifier, not your identity.
• Every form submission carries an anti-forgery token that is checked before anything is written.

In the browser

• All traffic is served over TLS; plain HTTP redirects.
• A strict content-security policy blocks third-party scripts, frames and connections.
• X-Content-Type-Options, X-Frame-Options, Referrer-Policy and a restrictive Permissions-Policy are set on every response.
• No third-party fonts, analytics or advertising code is loaded, so no external party learns who visits a school's page.

Publishing rules

Public pages are generated from aggregates, never from rows. A figure derived from fewer than 5 people is suppressed rather than rounded — rounding a percentage over a cohort of three still leaks the individual. Names, contact details and individual marks have no path to a public template at all.

Access and audit

• Roles are enforced on the route, not hidden in the interface: a teacher who types an administrator's URL is refused.
• A teacher reaches only the sections they are class teacher for.
• Changes to records are written to an audit log with the actor, the time and the change.
• Marks lock automatically when results are published, and unlocking is itself an audited action.

Operations

• Backups are taken daily and restores are tested; backups inherit the same field-level encryption.
• Dependencies are pinned and patched; the platform version is printed in the footer of every page so you can tell what you are running.
• We notify affected institutions without undue delay if a breach touches their data.

Reporting a vulnerability

We welcome reports and will not pursue anyone who reports in good faith. Write to security@aiutil.in with enough detail to reproduce the issue. We acknowledge within two working days and aim to fix confirmed issues within 30 days.

Please do:

• Test only against accounts you own, or against a demo institution.
• Stop as soon as you have confirmed a vulnerability exists.
• Give us reasonable time to fix it before publishing.

Please do not:

• Access, modify, download or retain another institution's data.
• Run denial-of-service, spam or social-engineering tests against schools or their staff.
• Use automated scanners heavy enough to disrupt a school's working day.