Keeping Children Safe in Education is statutory, it is updated almost every year, and the September 2025 edition is the one in force now. Most of the attention goes to what teachers must read in Part 1. One quieter requirement decides how well a school can defend itself. The Designated Safeguarding Lead must keep detailed, accurate and secure written records. That covers every concern, every discussion and every decision. It includes the reason behind a decision not to refer. This guide covers four things. What KCSIE expects of those records. What changed in 2025. How the main safeguarding platforms compare. Why the real weakness is usually not the safeguarding system. It is the wall between that system and everything else the school knows about the child.
Connect with us about your school system · · Replies within 24 hours
Keeping Children Safe in Education does not name a product and does not require software at all. What it requires is an outcome. Annex C sets out the role of the Designated Safeguarding Lead. It expects the DSL to keep detailed, accurate and secure written records. Those records cover all concerns, discussions and decisions, and the reason for each decision. That phrase carries more weight than it looks. The record must hold what happened, and why you took that course of action. It must also cover the times you considered a referral and did not make one. A decision not to escalate is itself a safeguarding decision, and it has to be recorded with its reasoning.
From the statutory wording, a compliant record has a consistent shape:
The reason for the chronology is early help. One low-level concern means little. The same concern for the fourth time, beside lateness and a change in behaviour, is a pattern. The records exist so that a pattern appears before a situation worsens. That is why one view of the whole child matters so much.
The September 2025 edition kept the record-keeping expectations and added several things that bear directly on the systems a school runs:
KCSIE goes out to consultation and is reissued regularly. A 2026 edition is in draft consultation now. A school's safeguarding system must therefore take a change each year, and not sit fixed on one version of the rules.
A standard MIS does not give the DSL what KCSIE expects. It lacks restricted, structured case management that shows a pattern. Most schools therefore run a dedicated platform beside it. Two dominate the UK market.
Best for: Schools and trusts wanting highly configurable categories and a wide module set covering pupils, staff and visitors.
CPOMS is used across a very large number of settings in the UK and beyond. Its strength is configurability: a school decides what categories of concern it wants to monitor, and the system flags, links and reports against them. StudentSafe holds the pupil welfare records. StaffSafe covers staff concerns and allegations, and there is a visitor module. Related parts of safeguarding therefore stay in one platform. Other school systems can escalate flagged incidents straight into it.
Best for: Schools wanting structured case management and anonymous reporting, within the Tes ecosystem.
MyConcern, part of Tes, is an award-winning safeguarding platform built around reporting, recording and monitoring concerns. It is known for clear case management, and for anonymous reporting. That makes it easier for staff and pupils to raise something they are unsure about. Like CPOMS, its central value is bringing concerns into one place so trends become visible early.
Among the further options are Senso's Safeguard, youHQ for wellbeing-led safeguarding, and modules attached to wider welfare platforms. The market is healthy and the leading products all meet the core record-keeping expectations. They differ on four things. The interface, how you set up categories, anonymous reporting, and the wider range each one belongs to. A short trial with your own DSL therefore tells you more than a feature list.
Here is the part the product comparisons skip. The dedicated platforms are good at what they do. The problem is what surrounds them.
Attendance lives in the MIS. Behaviour lives in the MIS, or in a separate behaviour tool. Safeguarding lives in CPOMS or MyConcern. Special educational needs data sits in the SEN register. Each holds a genuine piece of the same child, and the pieces do not connect without someone connecting them. A pastoral leader may suspect that a pupil's worsening behaviour links to falling attendance and an open safeguarding concern. They then open three systems, take data from each, and build the timeline by hand. The information needed to act early already exists. The joining is manual, and manual joining is what gets missed when staff are stretched.
| Approach | Record-keeping | Connected to MIS data? | Audit trail | Ownership |
|---|---|---|---|---|
| CPOMS | Full, highly configurable | Via integration only | Within the platform | Subscription |
| MyConcern | Full, structured case management | Via integration only | Within the platform | Subscription |
| MIS safeguarding add-on | Variable, often basic | Within that MIS | Within the MIS | Subscription |
| Bespoke (ESRE) | Full, built to KCSIE | Same architecture as attendance, behaviour, SEN | Automatic across the whole system | Owned outright |
A bespoke system from ESRE starts somewhere a dedicated platform cannot. We build it on the engage.re graph. A pupil, an attendance mark, a behaviour note and a safeguarding concern are all data on one foundation. None of them sits trapped in a separate product. The safeguarding module is not a platform bolted on by an integration; it is part of the same system. The DSL still gets a restricted case history that only they and their deputies can read. That history sits beside everything else the school knows about the child. The pattern that needs three logins elsewhere is therefore visible here.
The audit trail is where the architecture changes the game. The system records every action in a log that nobody can alter. Every entry. Every message to a parent about a concern. Every staff access to a record. Every referral. Each one carries an author and a timestamp the system set. The DSL never has to remember a separate application. The school never has to build an evidence trail when an inspector asks. The trail already exists, because of how the system stores the data. The version we are now implementing signs and hash-chains every event, so a record cannot be altered after the fact without the chain breaking. KCSIE record-keeping is no longer a habit staff must keep up. The system makes it certain.
Two things follow that no safeguarding product offers. First, the system shows whether your safeguarding changes outcomes. It records every change to a child's data. A school can therefore see whether the early-help work moved attendance, behaviour and engagement. It shows more than the fact that somebody logged a concern. Second, the school owns the system and keeps shaping it. KCSIE changes each year. A new category, a new report or a new workflow is then added as data, in days. The school can make that change itself. Every build comes with documentation exact enough for an AI to follow, so the work stays in-house. The school owns the code outright, on secure UK servers it controls, with no per-pupil renewal. The full picture is on the School Management Software hub.
KCSIE asks for records that are accurate and secure. Most systems meet the first word. The second is harder than it looks.
A case note holds a date field. In an ordinary database an administrator can change that field, and nothing shows that the value was ever different. The record then states a time, and it cannot prove that time.
This is the difference between a note and evidence. It decides what a school can defend at a serious case review.
On engage.re each entry is an event, and each event carries a hash of the event before it. Altering one entry breaks the chain, so any change is detectable. The timestamp is therefore proof, and not a claim.
The restricted DSL history uses the same design. Access is a narrow grant, and every read is itself an event, so a school can show who saw a child's record and when.
We explain the evidential question in who answers when an AI agent gets it wrong. We cover retention and destruction in can you prove you deleted someone's data.
Whatever system a school runs, the evidence an inspector tends to probe is consistent:
No. KCSIE sets the outcome, and not the tool. The DSL must keep detailed, accurate and secure written records of all concerns, discussions and decisions. Those records must include the reason, and whether a referral was made. Most schools meet this with a dedicated platform, because standard MIS products keep DSL records poorly. The duty is still about the records, and not about the tool.
Both are established case-management platforms that meet KCSIE record-keeping expectations. CPOMS is known for highly configurable categories and modules for pupils, staff and visitors. MyConcern, part of Tes, is known for structured case management and anonymous reporting. The practical differences are interface, configuration and ecosystem, so trial both with your own DSL.
On its own it is not; dedicated platforms do the job well. The difficulty is that safeguarding then sits apart from attendance, behaviour and pupil data. Joining the signals that matter most for early help becomes a manual job across several systems.
Yes, in a bespoke system. Put safeguarding on the same foundation as attendance, behaviour and pupil records. The DSL then gets a timestamped case history, under permission, beside the rest of the child's record. The audit trail is logged as it happens, and not built later. See the school management software hub.
Connect with us about your school system · · Replies within 24 hours