How learner information is protected

A school is being asked to put children’s information into somebody else’s system. That is a real decision, and it deserves a real answer rather than a page of assurances. This chapter says what is actually held, how it is held, and who can reach it.

What the school records about a learner

The learner record is deliberately small. It holds the learner’s name, their class and grade, the badge or badges they carry, and the school’s own register number for them — the number already written on the register and the report card.

Three things are optional, and each is optional for a reason.

A photograph. Most schools want one, because a face is the real identity check at a gate. A school that does not want to hold photographs simply does not upload them, and the gate falls back to initials.

A national identity number. This is a child’s ID number, and it is optional precisely so that a school which cannot justify holding one does not supply one. It is never collected in bulk: a class list mailed between offices carries the register number and nothing else, so a spreadsheet can never become four hundred children’s ID numbers. Where one is entered, it is entered on that learner’s own record, by somebody looking at the document.

A custody note. Where a custody arrangement exists, a learner can be flagged with short guidance for staff. It is staff-only, it is never shown to a parent or guardian, and who set it and when is recorded.

Alongside the learner sit the guardians the school may contact, their relationship to the learner, and — where the school has recorded them — the adults who may not collect that learner.

What is encrypted, and what that actually buys you

Encryption is worth explaining rather than asserting, because “encrypted” on its own means very little.

Photographs are encrypted before they are stored, with a key that belongs to that one school. Each school’s key is itself locked away under a master key, and the lock is tied to that school — a key issued for one school cannot be presented for another, and it cannot be reused for a different purpose. When a face has to appear on a screen, the system issues a link that works for one image for about a minute and then stops working.

A learner’s national identity number is stored in two forms and neither of them is readable. There is a one-way fingerprint, which lets the school match a learner arriving from another school without anyone reading the number, and there is an encrypted copy for the rare occasion a lawful read is needed. There is no third column holding the number in plain text; the design started that way rather than migrating to it. A build check enforces the rule structurally: if anybody adds either of those fields to a screen, a list, an export, a log line or an audit record, the build fails. That matters more than care does, because this is not the kind of thing that leaks through a dramatic bug — it leaks through somebody widening a query on a screen that had no business seeing it.

Guardian phone numbers and email addresses are stored encrypted, with a separate one-way fingerprint kept so that a reply arriving by message or email can be matched to the right family without anything having to read the number itself. When a contact is saved and the school’s key is available, only the encrypted form is written — the readable column is deliberately left empty. Contacts captured before this change are converted in a separate, supervised step for each environment rather than silently in the background.

If the encryption key is ever unavailable, saving a contact fails rather than quietly writing it in the clear. That choice is worth naming: a service that starts up without its key and carries on regardless is exactly how personal information ends up permanently exposed.

Audit records never carry contact details

Every sensitive action writes an entry to the school’s audit trail: who did it, when, and to which record. Those entries carry references, not personal details. A build check scans audit payloads, log lines and internal messages for contact-shaped fields and fails if one appears, so the audit trail cannot become a second, unprotected copy of the contact book.

Who can see what

Access is decided by the role a person signs in with, and it is checked on the way in to every request — not by hiding buttons in the interface.

• A gate officer sees what the gate needs: who is on the roster, who is expected, the face at the moment of the decision, and who may collect a learner.
• A class teacher sees their own class.
• A school administrator sees their school’s workspace.
• A parent or guardian sees only their own children, through a link, with no account and no password. The link is read-only. It stops working when the guardian’s contact details change, and a school administrator can revoke a leaked link on demand, which invalidates every link issued before that point.

Certain administrative actions require more than being signed in. They require a passkey on the device in front of you, tied to that specific action — the privacy screens described in POPIA rights and how to use them are the clearest example.

One school cannot see another

Which school a request belongs to is taken from the signed-in session and nothing else. The browser does not get to say which school it is asking about, so there is no value a curious or malicious client can change to reach another school’s data.

The separation runs deeper than the check. Each school’s encryption key is its own, and the lock on that key names the school, so a stored file cannot be carried across to another school and opened. The same is true of encrypted contact details and of the encrypted visitor record.

When platform staff look at your screens

Sometimes a support problem cannot be diagnosed without seeing what the school sees. When that happens, a member of the platform team can open a school’s screens in a session that is deliberately constrained.

It is read-only — the system refuses every change made on such a session, not because the screens hide the buttons but because the refusal sits in the one place every request passes through. It expires after fifteen minutes and cannot be extended in place. The person using it sees a permanent banner saying so. And the fact that it happened is written into your school’s own audit trail, not only into a platform log, so a school administrator can see every occasion a platform operator looked at their screens.

That last point is the one to hold on to. Support access is not the problem; silent support access is.

Devices are part of the picture

A gate phone can hold a copy of the roster so that scanning keeps working when the connection does not. That copy is encrypted on the device, it expires, and a school administrator can turn it off, set how long it lives, and decide whether it includes photographs.

The app says the quiet part out loud on that setting screen: “Photos saved on a device are personal information (POPIA). Only enable this if your device-loss process is sound.” A copy of four hundred children’s faces on a phone that goes home in somebody’s pocket is a decision, and it is presented as one.

How long things are kept

Every school starts with a retention policy it can change. Check-in and check-out records are kept for a little over a year by default, audit records for two years, and visitor records for two years. Once a record passes its window it leaves the live system and is kept in an encrypted archive instead.

A conversation with the school moves as one piece. When it reaches the end of its window, the parent’s messages and the school’s replies to them go into the archive together and leave the live system together — so a school asked later what it told a family can still answer. This used to be only half true: the replies were deleted with the conversation and kept nowhere. It was written on this page while that was the case, and it was corrected in August 2026.

Because a reply is always written after the message it answers, a reply can be newer than the window its conversation has just left. It travels with the conversation anyway. Keeping the answer live after the question had gone would leave half a conversation in each place, which helps nobody, and holding the whole thread back until the last reply aged out would keep a parent’s own message for longer than the school said it would.

The policy has floors and ceilings, so it cannot be set to something nobody could defend in either direction. The reasoning behind the ceilings is a deliberate position: no more than about two years of data needs to be available at any one time. Visitor records are the single documented exception, because a school can carry an insurer or occupational-health duty on its visitor register that runs longer.

Who can change the policy, and how, is covered in POPIA rights and how to use them.