Ludendo

For school boards, data protection officers and SIVONPrivacy and security

Who sees what.
And what still needs doing.

Who sees what, who viewed what and whose data it is. There is no real student data in Ludendo yet. It is in development and not yet in use at any school. First come an outside review and the agreements with the school.

What still needs doing

All screens show made-up data from Het Voorbeeld College, on Friday 9 October.

Phone screen of school leader Erik Mulder with made-up data: the log for Friday 9 October. At 15:45 he looked up everything about Lotte de Wit, and that is in it too. At 15:31 Mr Bakker opened Lotte’s profile; that is allowed, he is the mentor of 4V2. At 11:52 Mr Kramer tried to open Sem Jansen’s medical details: refused. At 10:12 Ilse de Groot opened the permissions per role, at 08:31 Mr Bakker took attendance in 4V2 and at 07:51 Mark de Wit reported Eva sick.

· Parent · Mark de Wit, on his phone

Signing in.
Parents always with a code.

Students and staff sign in with the school’s account, via Entree. Parents have their own account: a password and then always a code from an app. After that Mark only sees his own children.

Built, not yet in use. The connection to Entree is still simulated for now, for the tests.

Skip the day
  1. An account of his own. Mark signs in with his email address and password.
  2. Always a code. Then the app asks for a code from the app on his phone. Without a code nobody gets in.
  3. Only his own children. Lotte and Eva, and nobody else. After an hour of doing nothing he is signed out by himself.
Phone screen of Mark de Wit with made-up data. He signs in with his email address and password, then with a six-digit code from an app. Then he only sees his own children: Lotte de Wit from 4V2, with English in a different room, and Eva de Wit from 3H3, with a new grade for maths. At the bottom: signed in with a code at 07:50; after an hour of doing nothing he is signed out by himself.

· IT · Ilse de Groot, on her laptop

Who sees what.
Per role, and why.

Ilse de Groot is the IT coordinator. She checks which role may see what. A teacher only sees their own teaching groups, a parent only their own children. Everything is closed, unless a role is allowed.

Built, not yet in use: the rules themselves, at every page and every button. The overview as a screen is a Clickable example.

  1. Seven kinds of data, seven roles. For each role it shows what it may see. These are the default permissions.
  2. One role: the mentor. He sees his mentor class, to guide the students. Not the citizen service number and not medical details.
  3. Medical details. Medical information is only seen by those who need it: the care coordinator, the administration and the parent of their own child.
Laptop screen of IT coordinator Ilse de Groot: a table with seven kinds of data and seven roles. File: the mentor for his mentor class, the administration only the student card, care and school leaders everything; student, parent and teacher not in the app. Grades and absence: student and parent only their own, the teacher only their own groups and lessons, the mentor their mentor class. Leave: the school leaders decide. Medical details: only the parent of their own child, the administration and the care coordinator. The BSN only the administration, with a separate permission. The log only the school leaders. For the mentor role it says: he sees the file, grades and absences of his mentor class, to guide the students, and no medical details, BSN or log.

· Teacher · Mr Kramer, maths, on his phone

Is this allowed?
If not, you see nothing.

At every page and every button the app first asks: may this person do this, for this student, on this date? Mr Kramer teaches maths to 4V2. Sem Jansen is sick today. Mr Kramer sees that, and Sem’s grades for maths. Why Sem is sick, he does not see.

Built, not yet in use. Every page and every action is in one list with the roles that may do it. Those rules are also in the database itself.

  1. What belongs to his subject. Mr Kramer opens Sem. He sees that Sem was reported sick today, and his grades for maths.
  2. No permission, nothing on screen. He taps the medical details. He sees nothing: he does not have that permission.
  3. It is in the log. An attempt that is not allowed also goes into the log. The school leaders see it there.
Phone screen of Mr Kramer with made-up data. For Sem Jansen from 4V2 he sees that Sem was reported sick today, at 07:46 by a parent, and his grades for maths, a 6.3 and a 7.0. He taps the medical details. There is no access: he does not have that permission, so he sees nothing. The attempt was recorded in the log at 11:52.

· School leaders · Erik Mulder, on his laptop

Who looked?
It is in the log.

Mark de Wit asks the school who looked at Lotte’s file. Erik Mulder looks it up. Every sign-in, every refusal, every export and every time someone views one student is in it. In plain sentences.

Built, not yet in use. How long the log is kept, we will agree before any real data goes in.

  1. Who did what, today. Every line is a sentence. The refusal at 11:52 is in it too.
  2. Everything about Lotte. At 15:31 Mr Bakker opened her profile. That was allowed: he is the mentor of 4V2. Nobody else.
  3. For the parent. Erik exports the lines for Mark. That he looked this up is itself in the log too.
Laptop screen of school leader Erik Mulder with made-up data: the log for Friday 9 October, in plain sentences. At 15:31 Mr Bakker opened Lotte’s profile as mentor, at 11:52 Mr Kramer tried to open Sem Jansen’s medical details and was refused, at 11:40 Ilse de Groot viewed Mr Kramer’s permissions, at 10:12 Ilse de Groot opened the permissions, at 08:31 Mr Bakker took attendance in 4V2, at 07:51 Mark de Wit reported Eva sick and at 07:50 he signed in with a code. Erik looks up everything about Lotte: at 15:31 Mr Bakker opened her profile, and that was allowed; at 13:40 he showed her grade. Nobody else opened her data. He exports the two lines. After that the log also says: at 15:45 Erik Mulder looked up everything about Lotte.

· IT · Ilse de Groot, after the bell

The data belongs to the school.
Everything goes along in one file.

The school is responsible for the data. Ludendo will only process it on behalf of the school. Ilse sees what is stored about a student, and exports everything. That way the school can always switch.

Built, not yet in use. One file with a description of how it is built up, so another program can import it.

  1. What is in it. Name and class, contact details and parents, timetable, homework, grades, absences and messages. Care, medical and the BSN only with a separate permission.
  2. What has not been decided yet. How long everything is kept, we will agree with the school. That has not been done yet.
  3. Export everything. All the school’s data in one file, with the log. That export is in the log too.
Laptop screen of IT coordinator Ilse de Groot with made-up data. What is stored about a student: name, class and contact for everyone with a role; timetable, homework, grades, absences and messages by role; care, medical details and the encrypted BSN only with a separate permission. How long it is kept has not been agreed yet. On the right she exports all the school’s data with the log, in one file: voorbeeldcollege-2026-10-09.zip.

What else it can do

Everything about privacy and security.
Honest about how far along it is.

Built means: in the real app, tested with made-up data. Not online anywhere yet and not in use at any school.

Built, not yet in use10
  • Deny, unless: every page and every button first checks whether you may. The rules are also in the database.Built, not yet in use
  • Separated per board: one board cannot see another’s data. The database itself takes care of that.Built, not yet in use
  • The citizen service number stored encrypted, only shown with a separate permissionBuilt, not yet in use
  • No names or other personal data in the app’s technical logsBuilt, not yet in use
  • Students and staff sign in with the school account, via Entree (simulated for now)Built, not yet in use
  • Parents always sign in with a code from an app (two-step)Built, not yet in use
  • Signed in for at most eight hours, signed out by itself after an hour of doing nothing. Signing out of the school account signs you out everywhere.Built, not yet in use
  • The log: sign-ins, refusals, exports and who opened which file. Nobody can change or delete a line.Built, not yet in use
  • The log in plain sentences for the school leaders, searching by student and exportingBuilt, not yet in use
  • Export everything in one file, with a description of the structureBuilt, not yet in use
Planned5
  • All data with one host in the European Union: database, files, signing in, email and logs. Which one, we have yet to choose.Planned
  • Backups in a second place, also in the European UnionPlanned
  • “Is this wrong?” next to an absence: a parent asks the school to correct somethingPlanned
  • When a student turns 18, they choose what their parents seePlanned
  • The parents get an explanation of that, in their own screenPlanned
Clickable example2
  • The permissions in one overview, and adjusting them yourself per roleClickable example
  • Managing accounts: resetting two-step sign-in for a new phone, with a link that is valid for 24 hoursClickable example
Idea1
  • Parents sign in with a passkey, without a passwordIdea

Clickable example: a worked-out design with made-up data, not yet in the real app. How far along we are in total

Rights of parents and students

The school decides
about the data.

The school is responsible. Ludendo will only process the data on behalf of the school. That goes into the data processing agreement, which does not exist yet.

View

Parents and students ask the school what data there is. The school looks up in the log who viewed it, and can export those lines. They do not see the log themselves in the app.

Correct or delete

Is something wrong? Then they ask the school. The school decides; Ludendo carries it out. For an absence there will be a button for that; it is planned.

Switching over

The school can export everything in one file. That way another program can import it, and the school can always leave.

No advertising

There will be no advertising in the app, and we do not sell data.

A person decides

The computer never decides about a student. With every warning, a person chooses what happens.

No AI training

We never use student data to train AI.

If someone disagrees with the school, they can file a complaint with the Dutch Data Protection Authority (Autoriteit Persoonsgegevens).

What still needs to happen

This first.
Only then real data.

No real student data goes into Ludendo before the outside review, the penetration test and the agreements with the school. This is what has not been done yet.

Not done yet

  • No penetration test: a trial attack by a security company.
  • No check by an outside developer.
  • No ISO 27001 certificate, a quality mark for information security.
  • Nothing hosted yet: the app does not run online anywhere. Only this website.
  • No host chosen yet. Everything with personal data will be with one host in the European Union.
  • No retention periods yet and no data processing agreement with a school yet.

Still open from our own check of 30 October

  • The virus scan on files is not connected yet.
  • The app’s pages do not yet have extra protection in the browser (Content-Security-Policy and HSTS).
  • The school leaders and whoever imports data can still query the students of the whole board in the database, not just those of their own school.
  • The encrypted BSN is not yet tied to one student.
  • We will set the database limits and logging as soon as there is a host.

Fixed on 30 October: the database checks more strictly who may read what, and uploads first check whether someone is signed in.

The privacy documents, still drafts

You can request the drafts, for example to have your data protection officer look at them already.

  • Addendum to the data processing agreementDraft
  • Privacy information sheetwhat data, for what and for how longDraft
  • Building blocks for the DPIAthe school’s privacy impact assessmentDraft
  • Data breach procedureDraft
  • List of sub-processorscompanies that store data for usNot yet: the host has not been chosen yet

Draft means: not complete yet and not legally reviewed yet. Status on 1 November. The documents follow the structure of the Dutch education privacy covenant (Privacyconvenant Onderwijs, model 4.0); Ludendo has not joined the covenant yet. About this website itself: the privacy statement (in Dutch).

Questions

What the school board, the participation council
and the data protection officer ask.

Is there student data in Ludendo now?

No. Ludendo is in development and not yet in use at any school. Everything on this site was made with made-up data.

What data about a student goes in?

Name and class, contact details and parents, the timetable, homework and handed-in work, grades, absences and leave, and messages. Care and medical details only for those with a separate permission for them. The BSN is stored encrypted. The full list is in the privacy information sheet (draft, on request).

Can a parent see who looked at their child’s file?

Not themselves in the app. But via the school: the school looks it up in the log and can export those lines.

What if Ludendo stops?

The school can export everything in one file. Agreements about what happens then go into the data processing agreement. They have not been made yet.

Can we have the documents reviewed already?

Yes, you can request the drafts. They are not complete yet and not yet reviewed by a lawyer.

When can a pilot start?

There is no date for that yet. One thing is certain: no real data goes in before the outside review, the penetration test and the agreements with the school.

Would you like to see the documents?

Request the
drafts.

We will send them to you, with what is still open. Parents and students ask the school questions about their own data.

Email us How far along we are