Most nursery platforms store every customer's data together: one shared database, one shared risk. We built Little Bees so that your nursery's data is yours alone, isolated by architecture, invisible to everyone else on the platform.
In many systems, children's records, medical notes and safeguarding concerns sit in one shared database that the provider's own staff can browse. We keep each nursery apart, encrypt the sensitive fields, and give our admin tools no route in. Kido breach case study.
91%
of UK universities breached in 2024
44%
of secondary schools attacked in 2024
347
ICO incidents in education and childcare in 2023
+55%
year-on-year increase in reported incidents
Cyber attacks on education are accelerating faster than most platforms can respond. The pattern is always the same: underfunded IT, weak access controls, and no multi-factor authentication, which is itself becoming less reliable as session hijacking allows attackers to bypass 2FA entirely. The sector holds some of the most sensitive data in the country, yet it is one of the least protected. Systems built on older technology will struggle to keep up. Little Bees is built for a new era of technology.
Sources: UK Cyber Security Breaches Survey 2025 · ICO / 4th Platform 2024
Every nursery on Little Bees operates in its own dedicated database, completely isolated from every other customer on the platform. We call this the SILO model.
Most platforms rely on a single shared database with row-level filtering to keep customers apart. That approach creates a single point of failure: one compromised account, one misconfigured permission, one unexpected edge case, and the boundary between customers is gone. Not because anyone wrote bad code, but because software running on shared data has no architectural fallback when something goes wrong.
There is no path through the application, through credentials, through any layer, that crosses from one nursery's database to another. The isolation is structural: a nursery's system can name only its own database, so there is no connection to bypass. Your database simply doesn't exist in anyone else's world.
Four nurseries. Four sovereign databases. One platform.
Every organisation on Little Bees has its own private, dedicated database. Multi-site groups have all their locations within that one database, but it is never shared with any other organisation. There is no connection between customers, and no path through the application that could cross from one to another.
Little Bees runs on a serverless architecture. There are no persistent server processes to compromise, no in-memory data to scrape between requests, and no long-lived server-side sessions accumulating state. Each request executes in isolation and closes.
Contact details, medical notes, safeguarding records and door passwords are encrypted field by field before they are stored, under four separate keys, so the key for one kind of data cannot open another. The keys are held as platform secrets and never in the database, so a copy of your database on its own returns unreadable ciphertext. Keys of your nursery's own are on the way.
Our administrative tools run separately from your nursery's system and cannot open its database. Inside your nursery, only the Designated Safeguarding Lead can open safeguarding records. We write and deploy the software that runs with the keys, so we say it plainly: this is how the platform is built and operated, not a claim that access by us is impossible.
Beyond the architecture, these are the operational controls. Each one is marked Live or Planned: we would rather tell you a control is coming than let you assume it is there.
What each person can see and change follows their role, and is checked on the server for every request, not just hidden in the interface. Safeguarding records open only for the Designated Safeguarding Lead.
Owners and managers use a passkey or an authenticator app, and nothing they change is saved until the session has passed that check.
Adding or removing a passkey or authenticator needs a recently verified session, so a borrowed session cannot swap in its own.
Repeated sign-in attempts from one address are refused before a password is ever checked.
A session that goes unused for seven days ends, and signing in again starts from the beginning.
Consequential actions, such as reviewing a safeguarding concern or changing a court-order flag, are written to a log the database itself refuses to edit or delete.
Making a second factor compulsory for all staff, not only owners and managers.
Pausing a session and alerting the owner when an account opens records at an unusual speed or volume.
Exports blocked on unrecognised devices and confirmed with a second factor.
Restricting sensitive operations outside working hours, and sign-ins from unexpected countries or networks.
Letting owners review who opened which records, and when, from inside the app.
What happened at Kido
In 2024, Kido, a chain of nurseries, suffered a data breach that exposed the records of over 8,000 children along with contact information for their parents and carers. The software at the centre of the breach was Famly, a nursery management platform used to store and share children's photos and developmental information with parents.
Kido said the breach came via Famly, its nursery software provider, although Famly itself insisted its own infrastructure was not compromised. Regardless of where the fault lies, the outcome was the same: child records, family data, medical information and photographs from across the Kido group were accessed from a single compromised account. Attackers issued a ransom demand and publicly shared photographs of children online.
This is not an unusual attack. Credential compromise is one of the most common vectors in data breaches, and it requires limited technical skill to execute. What made this incident so damaging was not how the attacker got in. It was that once inside, there was nothing to stop them reaching everything. No rate limiting, no anomaly detection, and no restrictions on how much data could be accessed from a single session.
The attackers demanded a ransom of £600,000 in Bitcoin and publicly shared photographs of children online when it was not paid. Two suspects, aged 17 and 22, were arrested within weeks on suspicion of computer misuse and blackmail. The attackers later claimed to have deleted the stolen data, though that claim remains unverified. For the families affected, the damage was already done.
How Little Bees protects against this
In our opinion the failures in the Kido breach were architectural. Here is where Little Bees stands on each, including what is not built yet:
Kido blast radius
8,000+
children exposed from one account
Little Bees blast radius
One
organisation, isolated from every other
MFA on Little Bees
Required
for owners and managers
Admin tool access
None
no route into a nursery's records
Book a demo and we'll walk you through exactly how the architecture protects your children's data, in plain language, no jargon.