Trust center

How student data is protected

Isolation between schools is enforced by the database

Every table carrying school data has PostgreSQL row-level security, and every row carries the organisation that owns it. Isolation is a property of the database rather than a check the application remembers to perform, so a bug in a page cannot return another school’s rows.

Access to student records is written to an append-only audit log

Reads and writes touching personally identifiable information are recorded with the actor, the action, the target, the time and the origin. The table is partitioned monthly and has no update or delete policy. Each entry also carries a hash of the entry before it, so the log can be checked for alteration — with two honest caveats immediately below, because this is the control a district will lean on hardest.

Sessions expire after 30 minutes of inactivity

Enforced for page requests and API routes alike, not only at the login screen. The timeout is a FERPA expectation for shared devices, which in a school is most of them.

The browser is locked down by a strict Content Security Policy

A per-request nonce is required for every script; there is no wildcard script source. The policy also forbids the application being framed at all, which removes clickjacking as a category. Violations are reported back to the platform rather than discarded.

Administrators are required to enrol in multi-factor authentication

Time-based one-time passwords can be enabled on any account, and an administrator who reaches an admin route without an enrolled factor is redirected to enrol before going further. Anyone who has a factor is stepped up to a verified session before an admin route will serve them. Authentication is rate limited to 10 attempts per 15 minutes per address, and the limiter does not fail open when its backing store is unreachable.

Data is encrypted in transit and at rest

TLS 1.3 in transit, with HSTS preloaded. AES-256 at rest for the database and for uploaded files, provided by the managed infrastructure Casiana runs on.

Student work is stripped of identifying information before any AI model sees it

The AI features are optional and consent-gated. Names, email addresses, phone numbers, school names and numeric identifiers are removed before a submission is sent for feedback, no AI suggestion is a grade of record, and every AI interaction involving student data is audit-logged. An administrator can turn student-facing AI off entirely for their organisation.

Independent review

Casiana is a young product built by a small team, and it does not yet hold third-party attestations. Specifically, and so that nobody has to ask:

• —No SOC 2 report — neither Type I nor Type II.
• —No third-party penetration test letter.
• —No signed Student Data Privacy Consortium national data privacy agreement.
• —No completed accessibility conformance report.
• —No 1EdTech certification.

The internal security self-assessment behind the controls above is available to prospective schools on request. When any of the above changes, it will appear on this page with the report attached — not before.