This is a behind-the-scenes look at a project we are genuinely proud of: a web platform that replaces paper-based assessment records for a children's special educational needs (SEND) charity. It is the kind of build where the hard part is not "make it look nice." It is "handle data about vulnerable children correctly, prove it, and never get it wrong."
We are keeping the client anonymous here, but we can talk openly about the engineering. If you run a charity or a service that handles sensitive personal data, this is the level of care the work actually needs, and most "we'll build you an app" quotes quietly skip all of it.
The Brief: Replace The Paper
Educators in early years settings assess children across the four SEND areas of need: communication and interaction, sensory and physical, social and emotional, and cognition and learning. Historically that happened on paper. Paper does not back up, it does not show progress over time, and it does not have an access policy.
The platform lets an educator complete an assessment, save drafts as they go, submit the work for a site manager to review, and see how a child is developing across terms. Site managers oversee their own setting, review submitted assessments, and manage children and staff. It sounds simple. The simple description hides three genuinely difficult problems.
The Difficult Parts
It Is Special-Category Data About Children
Under UK GDPR, data about a child's health, development, and additional needs is "special category" data. It carries the highest duty of care there is. That single fact reshapes every decision: how you store it, who can read which records, what an administrator is allowed to see, what shows up in a log file, and what happens when a staff member leaves. You cannot bolt this on at the end. It has to be the spine of the system.
Everyone Sees A Different Slice
A platform like this is multi-tenant by nature. A charity has many settings, each with its own children and its own staff, and an educator at one setting must never see children at another. Above the educators sit site managers, who oversee their own setting. The same permission model is built to extend upward to organisation and local-authority oversight, where those higher tiers get only a bounded, aggregated view as that part of the platform is rolled out.
Getting this wrong is the classic data breach: a logged-in user changes a number in a web address and reads a record they should never have touched. So the rule for us was that the permission model is not a UI nicety. It is enforced on the server, for every single request, against the specific record being touched.
The Workflow Has To Be Forgiving
Real assessments get interrupted. A child needs attention, a meeting starts, a laptop closes. So the editor auto-saves every 60 seconds, supports a clean "save and exit," and lets a colleague pick up a draft another educator started. Submitted work can be returned with feedback, updated, and resubmitted. None of that is glamorous, but it is the difference between a tool people actually use and a tool people quietly go back to paper to avoid.
The Security, In Plain English
This is the part most case studies skip, so here is the honest version of what protecting this data actually involved. To sanity-check ourselves, we put the whole thing through a structured security review before sign-off. Here is what that review was checking.
Sign In With Microsoft, Done Properly
Staff sign in with their existing Microsoft work accounts, so the charity controls who has access from their own Microsoft admin centre. Underneath, the sign-in uses the modern, secure version of the OAuth standard (PKCE), pins the exact cryptographic method tokens are allowed to use so a forged token is rejected, and only accounts from the charity's own Microsoft tenant are allowed in. A brand-new account that has never been assigned a role gets zero access by default. Access is something you are granted, never something you get by simply turning up.
Sessions And Cookies
We deliberately did not hand the browser a token it could leak. The browser holds an opaque session cookie that is locked to the site, hidden from JavaScript, and only ever stored on our server as a one-way hash. Every action that changes data is protected against cross-site request forgery with a second matching token. In plain terms: a malicious website cannot ride on a logged-in user's session to make changes on their behalf.
Personal Details Are Encrypted At Rest
Identifying details are encrypted in the database using AES-256-GCM, the same family of encryption used to protect data in regulated industries. The encryption keys live in the server's environment, never in the code. We still needed to be able to look someone up by email, and looking up encrypted data is normally a problem, so we used a "blind index": a keyed one-way fingerprint that lets the system find the right record without the database ever holding the email in readable form.
Two Locks On Every Door
The permission checks run twice, on purpose. The first check happens at the front door of each request: does this user even have this kind of permission? The second check happens at the record itself: is this specific child, in this specific setting, one this user is allowed to touch? Both have to pass. This "defense in depth" is what closes the change-a-number-in-the-URL attack, because even a request that slips past the first check is rejected at the record.
The front end hides controls a user is not allowed to use, but we never trust the front end for security. Every rule is enforced again on the server. The browser is for convenience. The server is the source of truth.
Admins See Patterns, Not Children
The aggregate reporting for organisation and authority-level admins is being built on a strict privacy-by-design rule, and that rule is already enforced in the reporting layer: it only ever exposes anonymised, aggregated trends, and it suppresses any group small enough that an individual child could be identified from the numbers (a technique called k-anonymity). The point is a deliberate ceiling on the admin tier. Understand how a cohort is developing, without ever being handed a list of named, vulnerable children.
Proving It, Not Just Claiming It
For a project like this, "it works on my machine" is not good enough. We ran it across separate development, testing, and production environments, deployed through an automated pipeline so the same code is promoted forward rather than re-built by hand. Production refuses to even start if it is misconfigured in a way that would weaken security, which turns a silent mistake into a loud one.
We also produced a full go-live sign-off pack: an evidence trail of what was tested, what was reviewed, and what was deliberately deferred to a later phase. When you are handling children's data, the paper trail that says "here is how we know this is safe" is part of the deliverable, not an afterthought.
The Result
The charity moved off paper and onto a platform that is genuinely built for the sensitivity of the data it holds. Educators get a forgiving, auto-saving workflow. Site managers get oversight of their own setting. The organisation gets a system whose security was reviewed in depth before it ever went live, and an audit trail to show for it.
This is the kind of work we love: not a brochure site, but a real tool with real responsibilities, built carefully enough that the people relying on it never have to think about any of the above. If you are weighing up a project that handles sensitive data and you want it done properly, get in touch and we will talk it through.