One organisation's data is unreachable from another's.
Every change is checked three separate times, by three things that fail independently — so if one of them is wrong, the other two still hold. This page is written for the person who has to sign it off, and it says what we do not have as plainly as what we do.
How Lurno protects one organisation's data from another's
Lurno checks every change three times over. The screen checks whether you are allowed to do something before it shows you the control. The server checks the same permission again before it touches anything, and refuses if the answer is no. And the platform itself decides what any request is allowed to return, underneath both of them. All three have to agree. The last one is the one that matters most: it means a mistake in the code above it is a bug rather than a data leak, because one organisation's information stays unreachable from another's even if something above asks for it wrongly.
- Three-gate authorisation
- Gate one is the screen: it hides a control you are not allowed to use. Gate two is the server: it checks the same permission again before it touches anything, and refuses if the answer is no. Gate three is the platform itself, which decides what a request may return at all. The first gate is convenience — it keeps you from clicking something that would fail. The second and third are the ones that actually protect the data, and they do it independently of each other.
Three gates, and what is behind each one
One request, authorised three times
A control in the interface asks whether the signed-in person holds a permission before it renders. The handler on the server asserts the same permission before it does any work. Then the database applies a policy that decides which rows the query may see. Three mechanisms, three separate places to be right, and any one of them saying no ends the request.
- The interface check is convenience, not a boundary. It hides a button; it does not protect a table.
- Every check resolves through one permission catalogue and one function. No handler reads a role name and decides for itself what that role means.
- A role granted on a branch of an organisation's tree cascades down that branch — and the database policies read the same tree the interface does, so the two cannot disagree.
separation enforced underneath the platform
Separation is built in, not a convention people follow. Every table carries the same permission rules the rest of the platform uses, and a migration check looks for tables that were granted access without a policy behind them. The number is not a marketing figure — it is what the database returns when you ask it how many policies it is enforcing.
- Policies do not inline their own logic. They call the permission function, so the answer cannot drift from what the server decided a moment earlier.
- Write policies carry a check clause as well as a read clause, so an insert cannot place a row into an organisation the writer has no permission for.
- Where a view exposes personal data, access is granted column by column. A table-wide grant would quietly undo the column-level protection, so it is not used.
Each area of the product kept apart
Each area of the product keeps its own separate store — one for who people are and what they may do, one for organisations, one for media, and so on. Nothing that matters sits in the default public schema, which is the place an accidental grant or a permissive default is most likely to expose. Private media has no storage policies for signed-in browsers at all: every read is signed by a server that checked the owning row first, and every upload is minted the same way.
- Single-use tokens — invitations, password resets, account recovery — are stored as salted hashes. The raw token is shown once, in the email, and never again.
- Only branding is public. An organisation's logo and favicon have to render before anyone signs in; avatars and lesson media do not, so they stay signed.
Proving afterwards what happened
An audit log nobody can check is a log file with better marketing. This one is append-only and tamper-evident, and checking it is a query.
An append-only log
Administrative changes are written as events carrying actor, action, resource, organisation and a before-and-after payload. Nothing updates an audit row. The write path only appends.
A SHA-256 hash chain
Each event stores the hash of the one before it and a hash of itself, both assigned by a database trigger rather than by the code that logged the event. Change one row and every later hash stops matching.
Verification you can watch run
A verification function walks the chain and names the first row where it breaks. We will run it in front of you during a review.
Access reviews
Who holds which role, in which organisation, reviewed on a schedule instead of at audit time. A removal is an audit event like any other.
Two people for the destructive things
Anonymising or deleting a person is a request, then a separate approval. The requester cannot approve their own request, and nobody can target themselves.
Sessions you can end
A signed-in person can revoke their other sessions, and a revoked session is locked out at the next permission check rather than when its token happens to expire.
From consent to erasure, with a clock on each step
Each tenant is the controller of its learners' data and Lurno is the processor. The machinery below is what makes that division real rather than contractual.
- 01
Consent, with a version on it
Every policy a person consents to carries a version. Change the policy and the old consent stops counting: the person is asked again, and what they agreed to and when is recorded. AI processing is a separate consent — withdraw it and nothing is sent to any provider.
- 02
A subject access request, as a wizard
An administrator works through the request instead of improvising it: identify the subject, gather what is held across the platform, produce the export. Portability means machine-readable — JSON and CSV, not a PDF of a screenshot.
- 03
Retention with an end date
Personal data carries a retention timeline per category rather than living forever by default. Inactive accounts, expired invitations and stale sessions all have a date after which they stop existing.
- 04
Erasure under a two-person rule
One administrator requests it, a second approves it, and only then does it execute. The requester can never approve, and neither of them can target themselves. Erasure reaches the tables that reference the person, not only the profile row.
- 05
A breach register with a 72-hour clock
An incident is a row with a deadline computed as 72 hours from discovery, and reminders that keep firing until it is closed. The clock starts at discovery, not at the moment somebody remembers Article 33.
Where the data actually sits
Media storage you can point somewhere else
Files are written through a storage interface with four implementations: Supabase Storage, Amazon S3, Azure Blob Storage and Google Cloud Storage. That is usually the honest answer to a residency requirement — a deployment can write files to a bucket in the region you are required to use, rather than waiting for a vendor to open one. Tell us the requirement early and we will tell you plainly whether it is met today.
- The database, authentication and the functions the API runs on are hosted by Supabase. That is the one dependency you cannot configure away, and it is named in the DPA.
- Per-organisation custom domains are served through Cloudflare with certificates issued automatically, so a learner in Beirut or Milan sees your domain, not ours.
Product analytics in the EU, with learners left out
Platform analytics run through PostHog in its EU region, behind an abstraction so the vendor can be replaced without touching the product. Session replay is masked, and it never records learners — the learner surface is not instrumented for replay at all.
- Text inputs and anything marked as personal data are masked in the browser, before a replay is sent anywhere.
- Analytics are consent-gated and off unless an organisation turns them on. Nothing about a minor is profiled, on any surface.
What happens to text before it reaches an AI provider
A learner's message, an uploaded PDF, a question typed into the copilot: all of it is content, none of it is instruction. That distinction is enforced, not requested in a prompt.
Injection classification
Untrusted input is classified before the real call runs. Text that tries to redirect the model is flagged rather than executed.
A randomised fence
Untrusted text is wrapped in a per-request tag it cannot guess, and that tag is stripped out of the content itself. Truncation re-closes the fence instead of leaving it hanging open.
Redaction before the call
Names, emails and identifiers are replaced before anything leaves for a provider. Grading runs over an anonymised submission; the map back to the learner stays on our server.
Checked before it is used
Every response is checked for the shape we expect. A malformed reply gets one attempt to correct itself and then fails, rather than landing in a course.
A trail from proposal to change
Requests, accepted drafts and rejected drafts are separate entries in the same audit log that cannot be quietly edited. What the model suggested sits next to what a person applied.
How people sign in
Written the way a security reviewer needs it: what ships today, and what does not.
Accounts by invitation
Accounts are created by an administrator or an invitation — there is no self-serve signup. Reset and recovery links are single-use and stored hashed.
Partner sign-on (silent SSO)
A partner system that has already authenticated someone can hand them over with a signed assertion, so the learner never sees a second login. It is configured per organisation, keyed, and revocable.
SAML and OIDC single sign-on
On the roadmapNot built. If your rollout depends on Entra ID or Okta, say so on the first call and we will tell you where it stands instead of implying it is there.
MFA and passkeys
On the roadmapAlso on the roadmap. Today the identity provider handles the password, sessions can be revoked by their owner, and revocation takes effect at the next permission check.
Everyone who touches your data
Five, and each one is named in the data processing agreement rather than discovered later.
| Capability | What it handles | Where it applies |
|---|---|---|
| Supabase | Database, authentication, file storage and the functions the API runs on | The primary processor. Media storage can be pointed at S3, Azure or GCS instead. |
| Cloudflare | DNS, TLS and the custom domain each organisation is served on | Terminates TLS for per-organisation domains; certificates are issued automatically. |
| OpenAI | AI generation, tutoring and grading drafts | Called only when a request needs it, after redaction. Anthropic and Google can be configured instead, and an organisation can connect its own key. |
| Resend | Transactional email — invitations, notifications, resets | An organisation can send from its own subdomain, with its own key. |
| PostHog | Product analytics and masked session replay | EU region. Learner surfaces are not recorded. |
The list that governs is the one in the data processing agreement, alongside the FERPA student-data-privacy addendum for schools. We will send both before a call rather than after one.
WCAG 2.1 AA, and what we do not have
Lurno is built to WCAG 2.1 AA. Automated axe checks run in continuous integration, so a contrast failure or a missing label breaks a build instead of reaching a release. Keyboard paths, visible focus and reduced-motion preferences live in the component library rather than being retrofitted per screen. The product ships in English, French, Arabic and Italian, and Arabic is right-to-left throughout, not a translated left-to-right layout.
We have not commissioned a third-party accessibility audit or published a VPAT. If a formal conformance report is a condition of purchase, raise it early — it is a scoping conversation, not a checkbox.
Answered before you have to send the questionnaire
The pages this one keeps pointing at
Send us the questionnaire.
Most of it is answered above. Bring the rest — residency, retention, sub-processors, the DPA — to a call, and we will answer in the same plain words we used here.