Keeping safeguarding records only the DSL can read

Ask a nursery who can see its safeguarding records and you usually get a confident answer: the Designated Safeguarding Lead, and the manager. Ask how that is enforced, and the answer gets vaguer. Often it is a folder nobody opens, a password a few people know, or a system where the records are technically visible to anyone with an admin login and everyone has agreed not to look.

That is not access control. It is etiquette, and it fails at exactly the moment it matters: when somebody with a login has a reason to look.

Designation is a decision, not a job title

Safeguarding access should follow designation. The nursery decides who is the Designated Safeguarding Lead and who that person nominates, and those people, and only those people, can open a concern.

The important corollary is that being a manager or an owner is not sufficient on its own. This surprises people, and it is the right way round. The person who signs the invoices has no operational reason to read a child's safeguarding record. If they need one, they should be designated, deliberately, and it should be recorded that they were.

A system that grants safeguarding access as a side effect of seniority has made the decision for you, and made it wrongly.

Separate keys, because one key is one failure

There is a version of encryption that sounds reassuring and does very little: everything encrypted under one key, held where the application can reach it. Anything that gets at the data has already got at the key.

The version that helps separates the keys by purpose. At Little Bees, safeguarding data is encrypted under its own key, distinct from the keys protecting personal details, medical information and credentials. That separation has a narrow, precise effect: somebody who obtains the key that protects contact details still cannot open a safeguarding record.

The keys belong to each nursery's own system and cannot be read back out, by anyone. That includes us. It is worth saying plainly because it is the difference between a provider that will not read your records and a provider that cannot. Only the second is a property of the system rather than a promise about behaviour.

Records are separated by nursery, structurally

Most platforms keep every customer's data in one shared database and separate customers with a filter applied when data is read. It works until a filter is missing, a permission is misconfigured, or an edge case nobody anticipated arrives.

Each nursery on Little Bees has its own database and its own file storage, reachable only by software holding the keys to that one pair. One nursery's system cannot name another's. That is a structural separation rather than a rule applied at read time, and it is the reason a breach of another setting is not a breach of yours.

The email problem nobody expects

Here is the gap that catches careful settings out. The access control on the record is tight, and then the notification about the record goes to the office inbox.

A safeguarding alert sitting in a shared mailbox that three people can open has just given three people the information. It does not matter how well-protected the underlying record is if the summary arrives somewhere wider.

The rule that follows is simple and should be non-negotiable: safeguarding notifications go to designated people, at their own addresses, and cannot be redirected to a general address. Other kinds of email can be routed wherever a setting finds convenient. This one cannot.

The audit trail has to be unfalsifiable

Every consequential action on a safeguarding record should be logged: designating a lead, opening or reviewing a concern, changing a court order flag. Most systems do log these things.

The question is whether the log can be edited. A trail that an administrator can quietly amend is evidence of nothing, because the circumstance it exists for is establishing what a privileged person actually did. On Little Bees that restriction is enforced by the database itself rather than by a policy about who ought to behave well, and it applies to us as much as to anyone.

Run the test on whatever you currently use. Ask your provider whether anyone, holding any credentials, can delete a line from the safeguarding audit log. The answer tells you what the log is worth.

Two things that are deliberately not hidden

Being straight about the limits is part of the argument. Children's and staff first names are searchable rather than encrypted, as are the dates and statuses that ratio and funding calculations depend on, because encrypting a column makes it unsearchable and a nursery that cannot search its own register cannot run a session. What that means in practice is that a database obtained without its keys yields first names and very little else: no surnames, addresses, dates of birth, contact details or medical notes.

Accounts and sign-in sessions are shared across the platform and separated by code rather than structurally, because signing in has to work before the system knows which nursery you belong to. We would rather state that than describe the separation as total when it is not.

What to ask your current provider

Three questions, in this order. Can anyone at your company read our safeguarding records, and is the answer a policy or an architecture? Is safeguarding data encrypted under a different key from everything else? Can any administrator delete an entry from the audit trail?

You are entitled to plain answers, and the shape of the answers will tell you most of what you need to know.

Little Bees enforces safeguarding access by designation, encrypts those records under their own key that nobody at Little Bees can read back out, and writes every action to a trail the database itself will not let anyone edit.