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.
Many providers can actually read your data behind the scenes. PII, medical notes, EYFS records and safeguarding concerns. All visible to the platform and their staff. That is not a security model. It is a liability. 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.
Our architecture has no single point of failure. 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. It cannot be misconfigured, escalated around, or bypassed. because 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.
Safeguarding records, medical notes, and financial data are encrypted before they are stored. The keys that unlock that data are held in a completely separate system. Gaining access to your database alone returns unreadable ciphertext. The keys are behind independent authentication.
No one within Little Bees can read your children's data. We operate the platform infrastructure, not its contents. All personal data is encrypted and we cannot decrypt it on your behalf.
Beyond the architecture, Little Bees ships with a set of operational security controls built into the platform.
Every practitioner only sees the rooms and children they're assigned to. Access is enforced at the database level, not just the interface.
Inactive sessions close automatically, keeping shared devices safe after they are put down.
Unrecognised devices must pass additional verification before access is granted.
Data exports are disabled on unrecognised devices, even with valid login credentials.
Sensitive operations are restricted outside business hours by default, reducing the window for misuse.
Logins from unexpected countries are blocked, automatically flagging unusual access attempts.
If an account accesses records at an unusual speed or volume, the session is paused, re-authentication is forced, and the nursery owner is alerted.
Every action on the platform is logged and tamper-proof. Nursery owners can review who accessed what, when, and from where.
Data exports, bulk deletions, and permission changes require multi-factor confirmation, even within an active session.
Access can be locked to known networks, so your data is only reachable from trusted locations.
Configurable password expiry policies for staff accounts. When rotation is due, access is blocked until the password is updated.
And more
Additional controls are available and configurable from the Security section of your account.
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
The failures identified in the Kido breach in our opinion are architectural. Little Bees is built so that each one is structurally impossible:
Kido blast radius
8,000+
children exposed from one account
Little Bees blast radius
Zero
isolated data + real-time monitoring
MFA on Little Bees
Enforced
cannot be disabled
Platform staff access
Zero
encrypted, we cannot read your data
Book a demo and we'll walk you through exactly how the architecture protects your children's data, in plain language, no jargon.