16 federal states, 16 ideas of the class register

Why, as a teacher and software developer, I ran into a surprisingly complicated problem with a seemingly simple task.

There are things in everyday school life you don’t think about much. You simply use them. The timetable, for example. The chalk. Or the class register.

The class register has been part of a school’s furniture for generations. It lies on the teacher’s desk, travels from room to room, is occasionally hunted for and sometimes only filled in completely on Friday. It is an inconspicuous object whose importance you notice at the latest when it has gone missing.

As a teacher, I know that feeling.

As the developer of Prilog, however, I made the mistake of asking myself a seemingly harmless question:

Why are we actually still doing this on paper?

The answer led me through the school acts and data protection rules of the German federal states. And to the realisation that it is probably easier to build accounting software for sixteen companies than one uniform digital class register for sixteen federal states.

But let’s take it step by step.

Surely this should be quite simple

My first picture was about as simple as it gets.

A teacher opens Prilog in the morning. He sees his class, marks the students who are missing, records the lesson and closes the class register again. By the end of the half-year, the absences have already been added up. Class tutors have an overview. The administration no longer has to decipher handwritten entries.

That would not be a technical challenge.

An application like that can be programmed relatively quickly. The database is manageable, and so is the user interface. Even the link to the timetable is not a fundamental problem.

The good news first: a digital class register is possible in principle in all 16 federal states. No state requires a class register to be kept on paper only. So the real question is not whether schools may work digitally, but under which conditions.

Then you start reading the legal requirements.

And you realise that the class register is apparently something quite different from what you had thought.

It is not just a record of lessons. It is at the same time a piece of evidence, a tool for meeting the school’s obligations and a store of personal data. Depending on the federal state, different rules apply to what goes into it, who may access it, how long it must be kept and under which conditions it may be kept digitally.

Suddenly the question is no longer how to build a good input form.

But: Which class register is this school actually allowed to keep?

Moving from Munich to Berlin suddenly changes the software

Take two schools. One is in Bavaria, the other in Berlin.

Both have teachers, students, lessons and absences. Both want to use a digital class register. And both rightly expect the software to make their work easier.

Even so, they cannot simply use the same settings.

The retention periods alone differ considerably. In Bavaria, for example, § 46 of the Bavarian school regulations (Bayerische Schulordnung, BaySchO) sets specific retention periods for certain school records; for class registers they are comparatively short. In Mecklenburg-Western Pomerania, on the other hand, the rules we looked at for comparable records go up to fifteen years.

At first that sounds like a problem you can solve with a single setting: choose the retention period, done.

It isn’t that simple.

Because it also matters when a period begins, which data it covers and whether different parts of a class register are subject to different rules. The software also has to know when data may actually be deleted, or must be deleted.

A program that simply keeps everything forever, to be on the safe side, is not a good solution.

But neither is one that deletes important evidence too early.

And that is only retention.

In Berlin, for example, requirements for technical safeguards and for how the data is processed play a special role. In Saxony there are specific rules on making changes traceable and on securing or closing records.

That leads to an interesting consequence:

The differences between the federal states do not just affect the wording of a privacy notice. They reach right into the architecture of the software.

Then comes Schleswig-Holstein

During the research there was a point at which I finally had to give up my original idea of one class register for the whole country.

Schleswig-Holstein.

Under § 13 of Schleswig-Holstein’s school data protection regulation (Schul-Datenschutzverordnung), a digital class register run by an external provider requires approval from the education ministry. At first that sounds like an obstacle. In fact it is a regulated procedure: if the legal requirements are met, in particular a proper data processing agreement, the approval must be granted.

This is not a rejection of digital class registers, but a clear requirement for how they are introduced. For development, that distinction matters.

Imagine a school wants to use software that works technically, is operated securely and is wanted by its teachers.

In one federal state, the route to introducing it runs mainly through the school’s own decision and the necessary data protection measures. In Schleswig-Holstein, with an external provider, the ministerial approval procedure is added on top.

That is no small detail.

For the school, it means an additional but plannable step. For the software provider, it means thinking about the required documents and processes from the very beginning.

So anyone who builds an application for schools cannot limit themselves to programming the features and then attaching a data processing agreement.

They have to understand under which conditions each school is allowed to use their software.

For me, that was one of the most surprising aspects of this research.

Sometimes the most sensitive information is a single word

It gets even more interesting with absences.

A student is missing.

The class register records: absent.

Perhaps excused.

Perhaps unexcused.

So far everything sounds unproblematic. But then someone wants to enter the reason.

“Ill.”

Or more precisely: “Migraine.”

And suddenly we are in a completely different area of data protection.

Health information is among the specially protected categories of personal data. Several federal states therefore have specific restrictions on such details in the digital class register.

In Mecklenburg-Western Pomerania and Rhineland-Palatinate, according to the rules there, health details do not belong in the digital class register at all. Other states require special technical or organisational safeguards for certain sensitive information.

From a developer’s point of view, this raises a difficult but necessary question:

What should the software know at all?

Does the class register need to know why a child is absent? Or is it enough for its purpose to know that the child is absent and whether the absence is excused?

In many cases the second piece of information should be sufficient.

And this is exactly where a basic principle of good school software lies, one that has become more and more important to me with Prilog:

Not everything that can be stored should be stored.

Software does not get better by collecting as much information as possible. It gets better when it processes exactly the information needed for the task at hand.

The real opponent is not the paper

Up to this point you might think the biggest difficulty with a digital class register lies in school law.

That is only half true.

The other half is sitting in the classroom at 8:05 in the morning.

She has thirty students in front of her, has to start a lesson, sort out a conflict from the day before and, along the way, work out who is missing.

I know this situation from my own experience.

In moments like that, I don’t care how elegant a software architecture is. Security is necessary; Berlin and Schleswig-Holstein require two-factor authentication for such applications. But a good implementation should make sure I sign in securely once in the morning and don’t have to repeat the same process before every lesson. And of course the application also has to cope with the unpredictability of a school morning.

I want to teach.

That is something developers easily underestimate.

On your own desk, everything works beautifully. The computer is switched on, the connection is stable, and you have plenty of time to test every dialogue carefully.

A school morning is not a development lab.

A digital solution that demands two extra minutes of attention every day already costs more than three working hours a day across a hundred teachers.

Of course digitalisation can save considerably more time elsewhere. But that gain does not happen automatically.

And if, in the end, the digital class register has to be kept and a paper version printed or maintained as well, you may have achieved the opposite of what you wanted.

The paper was not abolished.

It got company.

Maybe we are asking the wrong question

While developing Prilog, I therefore kept coming back to a different thought.

Why do we want to digitise the entire class register in the first place?

What do we actually need from it?

As a teacher, during lessons I care about different things than at the end of a half-year.

During the lesson I need a reliable overview. For school reports, what I mainly need at the end is the relevant absence data.

Not every handwritten note about a lesson has to end up in a database for that.

From this came an idea that seems anything but revolutionary at first glance.

What if we simply keep the paper class register for now?

Not for nostalgic reasons. But because in some schools it is still the most straightforward way to record lessons as they happen.

Alongside it, Prilog could take on a much smaller task: at regular intervals, for example once a week, only the absence data that will later be needed for school reports is transferred.

The first technical building block for this approach has already been developed, but has not yet made it into the released version. So for now this is a development path and not a feature that is already available.

The paper class register remains the authoritative class register. Prilog does not keep a second, complete class register; it supports a limited administrative task.

Of course this processing must also be lawful. Access rights, deletion periods and data protection do not go away.

But the approach changes the starting question.

We no longer necessarily have to reproduce digitally everything that has existed on paper so far.

We can first look at which part of the work actually benefits from a digital solution.

That sounds less spectacular than announcing a completely paperless school.

But in everyday life it could be considerably more sensible.

And then you look beyond the borders

If you think sixteen German federal states are complicated enough, take a look abroad.

The same basic question arises there: how does a school record its lessons and the attendance of its students?

Some of the answers differ even more clearly.

In England, for example, standardised absence codes play an important role. France has its own reporting and recording procedures. In Austria and the Netherlands, special reporting duties can apply when absences meet certain conditions.

In Switzerland, there are differences between cantons on top of that.

And anyone developing software for boarding schools immediately discovers the next level: there it is not only about whether a student is present in lessons. It may also be necessary to record whether they have left the grounds, when they came back or whether they are in the house at night.

At the latest at this point it becomes clear that an international digital class register cannot simply be a German class register with an English user interface.

The real task is to represent different school processes and legal requirements in one system, without having to write a completely new application for each country.

For Prilog, that means: we need a shared technical foundation, but different country and school profiles.

These profiles should be able to define which details are needed, which features are permitted, which security measures apply and which retention rules hold.

Even so, the user interface should stay as simple as possible.

That is the real development work.

Not the input form for “present” or “absent”.

But organising the complexity behind it so that the teacher notices as little of it as possible.

The software should know the rules. The teacher shouldn’t have to memorise them.

For me, this research has a second consequence as well.

If a school wants to introduce a digital class register, it should not first have to work out for itself which technical features its federal state requires.

A good system could ask during setup which country and federal state the school is in, what type of school it is and how it is meant to be operated.

It could then prepare suitable default settings and the documents needed.

For example, information on data processing, templates for internal rules or pointers to the consultations and approvals that are required.

Not as a substitute for a legal review. And certainly not with the promise that a mouse click fulfils every legal obligation.

But as real relief for the people who have to organise such an introduction.

Because this is part of digitalising schools too: it is not only the work in the classroom that counts, but just as much the work that happens beforehand in staff meetings, school offices and working groups.

If a school first has to spend months gathering documents and regulations before it can even try out a digital class register, something is wrong with the introduction process.

The surprising realisation

When I started working on the digital class register, I thought I would mainly be developing a software feature.

I see it differently now.

The class register is a remarkably good example of why digitalisation in schools is often harder than expected.

Not because teachers fundamentally dislike technology.

Not because schools are too old-fashioned.

And not because the programs would be too complicated to build.

But because behind a seemingly simple activity there is a web of legal requirements, established processes and very practical needs.

If you only see the technical task, you build software quickly.

If you also know everyday school life, you have to ask yourself a more uncomfortable question:

Does this really make anything simpler?

For me, that has become the decisive question for Prilog.

I don’t want to build software that keeps teachers busy with new tasks just so they can then be proud of working digitally.

I want to build software that takes work off their hands.

And if the best solution for a particular school is, to begin with, to keep the class register on paper and digitise only a small part of the administrative work, that is not a step backwards.

It may even be the smarter start.

Because the success of digitalisation does not show in how many paper folders have disappeared.

But in how much time teachers have for their students again.

---

Written from the perspective of a teacher and developer of Prilog.

A note on the research: the differences described are based on an analysis of state law and school organisation requirements as of October 2026. The examples are deliberately simplified. Before introducing a system, the regulations in force and the school’s specific circumstances must be checked. This article does not constitute legal advice.