Security and data protection

Entrusting a piece of software with your pupil records, the grades that decide whether a student moves up a year, and the money families pay means knowing where that data lives, who can read it, and what becomes of it if the relationship ends.

This page answers those questions. It is written to be read by a head of institution and then checked by an IT provider: everything that belongs to a technical review is gathered in the appendix.

At a glance

One database per institution

Each institution has its own database, on its own instance. There is no shared table where pupils from several schools sit behind a customer identifier.

Two practical consequences:

1. A filtering mistake cannot expose another school's data. In a shared database, isolation rests on a condition present in every query, and a single omission brings the partition down. Here the partition is the infrastructure itself.
2. An incident stays bounded to one institution. A restore, a migration or an intervention happens on one school without freezing the others.

The cost of that choice is ours: as many instances to deploy and update as there are institutions.

Where your data is hosted

Institution instances are served from addresses registered to LWS (Ligne Web Services), in France. This marketing site is served by Vercel, from its iad1 region (Washington, United States); it holds no pupil records.

The distinction matters: your pupils' data does not leave French hosting, even though the enrolment page that collects it is served elsewhere.

The RIPE registry gives the country where the address range is registered, not the address of the data centre. If you need the exact physical location, for a contractual clause or a formality, ask in writing: we hold it from the provider.

Backups

Who can reach what

Passwords are at least eight characters and mix letters and digits. They are stored as bcrypt hashes, never in clear — including in backups.

Two-factor authentication is available on every account. Each person turns it on from their own space by scanning a code with Google Authenticator, Microsoft Authenticator or FreeOTP, and leaves with eight single-use recovery codes to print for the day the phone goes missing.

Your institution decides which functions require it: protecting a head's office and an accounts office without imposing a phone on two thousand students, many of whom log in from a shared device. The setting locks nobody out — until someone has confirmed their second factor, they sign in as before. A school can therefore turn it on in the middle of the enrolment season.

Rights are granted by permission, not by fixed job title. You compose your own profiles: a registrar who sees enrolments without touching accounting, an external auditor read-only and for a limited period. No change to the software is required.

Removing the access of someone who leaves means deactivating their account: access is cut, while the entries they made stay attributed to their name in the audit log — which is what bookkeeping requires.

Sensitive actions are logged: who validated a payment, changed a grade, cancelled a receipt, with the before and after state. That log cannot be erased from within the application.

If you leave us

An institution that terminates leaves with its data, in a format it can read.

The export produces one file per table, in spreadsheet format, opening directly in Excel and LibreOffice on the registrar's machine. Added to it are the documents uploaded into the platform — report cards, receipts, photographs, logo — and a heading file stating what the package contains and what it does not.

The format is not a detail: handing a raw database dump to a departing school gives it its data without the means to read it.

Password hashes and session tokens are removed from the export. They are not the school's data but the secrets protecting its users' accounts, and an archive like that travels by email and USB stick. A successor has passwords reset; they never need the hashes.

Who is responsible for what

The split is set by Ivorian law no. 2013-450 of 19 June 2013 on the protection of personal data.

Your institution is the data controller. It decides to keep a pupil file, sets its purpose, completes the formalities with the protection authority, and answers access and rectification requests from its pupils and their families.

KLASSCI acts as a processor: we handle that data on the institution's behalf and on its instructions. The law requires a controller to choose a processor offering sufficient guarantees of technical and organisational security.

The split is developed channel by channel in the privacy policy.

Scope and limits

Four points, stated here rather than discovered later.

Live databases are not encrypted at the storage level. Encryption at rest protects against a stolen disk or a discarded drive being read, not against access obtained to a running server.

The relay's rate limiting is a shock absorber, not a guarantee. It divides the effect of a burst of requests; it does not remove it. A watertight limit requires a store shared between instances, and will be put in place if an institution is actually targeted.

No certification is claimed. No external audit, no accreditation and no label has been obtained to date.

The applicable text is Ivorian law no. 2013-450, not the GDPR. The practices described here follow its principles and often meet those of the European regulation, but an institution requiring contractual GDPR compliance should ask explicitly.

Technical appendix

This section is written for your IT provider.

The path taken by enrolment forms

The enrolment and re-enrolment forms are served by klassci.com; the records live in the institution's instance. Between the two sits a relay:

• The shared secret never reaches the browser. The family talks to klassci.com, which signs the call and talks to the institution.
• Every call is signed with an HMAC-SHA256 covering the timestamp, method, path and exact body. A signature issued for one endpoint is not valid for another.
• Only expected fields cross. The relayed body is rebuilt field by field from a closed list, never passed through as received.
• Rate limiting uses the address observed by the platform, never the one a header declares.
• "Record not found" responses are identical whatever the reason, so the form cannot be used to guess which student numbers exist.

What the site keeps

The relay stores no records. It forwards, returns the institution's answer and keeps nothing of it. Only two things are held, in memory and briefly: a per-address attempt counter over a sliding minute, and the catalogue of programmes and levels published by the institution, which contains no personal data.

Technical traces record the institution code and the nature of the incident, never the student number nor the date of birth: those are the two halves of an identifier.

Transport and headers

All pages are served over HTTPS, and an instance address that does not begin with https:// is refused by the configuration.

Logos and colours shown on a school's enrolment page are accepted only if they come from that school's own instance, and colours are revalidated before being written into the page.

Hosting references

Institution instances: LWS, France. Marketing site: Vercel, iad1 region. Address ranges and their registry references are provided on written request, together with the physical location.

A question?

Write to contact@klassci.com. Requests from an IT provider mandated by a client institution — physical server location, detail of a measure, a contractual undertaking — receive a written answer.