The following provides a clear update for Schools Broadband customers on how your current filtering and monitoring provision aligns with the latest expectations. Under KCSiE 2026, schools must review and evidence the effectiveness of filtering and monitoring every year. Expectations have moved towards greater transparency, real-world, day-to-day effectiveness, and shared understanding of system capability and limitations. Our aim is to ensure you are fully informed, both in terms of what your solution does well and where operational or policy decisions remain important.
Filtering: Capability and Coverage
Real-time and Dynamic Filtering
Your filtering platform (Netsweeper) uses a combination of categorisation techniques, including AI-driven analysis through its Category Name Service (CNS).
Where content is unknown:
- It is checked against a global database
- If not recognised, it is analysed and categorised in real time
- New classifications are shared and, where required, manually reviewed
This supports filtering beyond static URL lists, particularly as more content becomes dynamic and user-generated.
Locked Illegal Content Blocking
Blocklists covering illegal content categories (such as CSAM and terrorist material) are enforced at system level, hidden in the platform and locked, so they can’t be removed or disabled by anyone, including the school’s own IT staff. This is in line with guidance expectations.
Mobile Devices and App-based Access
We continue to enhance network-based filtering, however we recognise that:
- Some app environments and embedded browsers do not behave in the same way as standard web traffic
- Coverage in these contexts can vary depending on device configuration and connectivity
To extend protection, we work with specialist partners (including Smoothwall) to provide complementary approaches where traditional filtering is less effective.
Transparency and Technical Limitations
The 2026 guidance places greater emphasis on understanding how filtering works in practice, particularly:
- Encrypted (HTTPS) traffic
- Content served within apps
- Real-time or personalised content streams
We are committed to maintaining open and transparent communication through our technical, support and account management teams.
Where limitations exist:
- We will explain them clearly
- We will advise on mitigation approaches
- We continue to review emerging technologies to address these gaps
A key example is live, AI-generated content (e.g. chatbot interactions).
Due to how these services operate, they cannot currently be filtered in the same way as traditional web content. This is an area of ongoing development across the industry.
Monitoring: Supporting Effective Safeguarding Response
Alongside filtering, the updated guidance reinforces that monitoring must support timely and effective safeguarding action.
Our approach provides:
- Visibility of user activity
- Logging that supports attribution to individuals
- Integration with monitoring solutions designed to identify risk indicators
As with filtering, monitoring coverage can vary across:
- Apps and embedded environments
- Mobile device usage
- Off-network access
To strengthen this, we again work with partners such as Smoothwall to extend monitoring capability beyond core network activity.
However, it is important to be clear that:
Monitoring effectiveness is dependent not only on technology, but on how alerts are reviewed, prioritised and acted upon within your safeguarding structure.
Generative AI: An Evolving Area
The updated guidance places increased focus on generative AI tools.
From a technical perspective:
- Some access to AI platforms can be filtered at service level
- Interaction-level filtering and monitoring remain limited due to the dynamic, personalised nature of these tools
We are actively reviewing developments in this space and exploring complementary technologies as they mature.
In the meantime, schools and Trusts should:
- Define which tools are approved for use
- Understand current technical constraints
- Ensure monitoring and policy reflect this evolving risk area
Encrypted (HTTPS / TLS) Traffic Handling
Most web traffic is now encrypted (HTTPS), so our platform is built to inspect it rather than work around it. At full capability, SSL/TLS inspection decrypts traffic against policy and re-encrypts it — giving category-level control and safeguarding keyword visibility inside encrypted sites, not just at the domain name. This works because the platform inspects inline, in the path of the traffic, using a trusted certificate deployed to school devices via your MDM or group policy.
Modern encryption is exactly the “dynamic, encrypted environment” the 2026 guidance highlights, and we maintain visibility across its newer layers:
- TLS 1.3 — supported and inspected via the deployed certificate. TLS 1.3 defeats older passive monitoring appliances that relied on a copy of the server’s key; because we inspect inline, we are not affected by that. The few exceptions are covered below.
- Encrypted Client Hello (ECH) — ECH hides which site is being visited. We resolve DNS through our own servers, so ECH is not negotiated, and the plain destination is exposed for filtering.
- QUIC / HTTP-3 — where a browser tries to use QUIC (which is built to resist inspection), the platform declines it, so the browser falls back to standard HTTPS, which is then decrypted and filtered as normal.
This is a dialable control. A school can run with full inspection for the strongest safeguarding visibility, or scale it back — for example, inspecting pupil traffic but not staff, or excluding specific categories — and change that balance at any time on request.
In the interests of transparency, a minority of traffic cannot be content-inspected and is instead filtered at domain level (allowed or blocked): apps that “pin” their certificate and services using mutual (two-way) certificate authentication — for example some banking and operating-system services — reject any inspection certificate by design; and a small number of sites that operate in ways incompatible with inline inspection are bypassed for compatibility. In all these cases, the site is still subject to allow/block at the domain level; only its content is not decrypted. We will always tell you plainly which traffic is inspected and which is not.
On-device vs Network-level Protection
Filtering and monitoring are delivered from our cloud platform: your broadband traffic is filtered and logged centrally, so protection applies without any filtering software on the device. This is the model for the large majority of in-school use.
What sits on the device is light-touch, and dialable to the level a school wants:
- An inspection certificate — to filter inside encrypted (HTTPS) sites, a trusted certificate is deployed to managed devices via your MDM or group policy. Deploy it widely for full visibility or to a subset of devices — your choice, changeable on request. Without it, encrypted sites are still allowed/blocked at the domain level.
- An authentication helper (where used) — a lightweight agent, identifies the signed-in user so the correct policy (staff/pupil/admin) follows them. It authenticates the user; it does not filter.
Our own filtering and monitoring run in the cloud, not on the device.
Off-network use (a device taken home, or on mobile data) no longer passes through our platform automatically, but it can still be filtered. We provide an off-site explicit proxy that managed devices are configured to use when away from school (typically enforced through your MDM). You choose the level:
- With user identification — if you run a local Active Directory we can connect to, off-site users sign in at a captive portal and are placed in their correct filtering group, so activity is filtered and attributed by username on reports, just as on-site.
- Without identification — devices use the off-site proxy mapped to a single filtering group: traffic is still filtered to policy, but activity is not attributed to named users.
For a device-resident approach instead, we work with a specialist partner (Smoothwall). In every case, enforcing the proxy or agent on the device sits on your side, so off-network protection is something you switch on and scale as you choose. We set out clearly what the network protects and what depends on device configuration, so the boundary is never a surprise.
Monitoring: Model and Configuration
Monitoring works from the logs our platform captures centrally (see section 4), and is delivered through two separate systems — reporting and alerting — each configured independently and each built, at installation, to meet KCSiE requirements.
- Reporting — safeguarding and Prevent Duty reports designed to be KCSiE-compliant and quick to set up, with interval dials and toggles to make a report user-specific, group-specific, or both, delivered to your nominated leads (e.g. DSL, Headteacher) on the schedule you choose.
- Real-time alerting — alerts fire the moment activity matches a managed safeguarding keyword list and go straight to your named safeguarding lead. Alerting is highly configurable: beyond simple keyword matches, it supports contextual, website-specific and frequency-based triggers, so you can set different levels of monitoring and tune exactly what rises to an alert.
Both systems match against curated keyword lists, and the matching is rule-based, not AI — there is no “black box” deciding what counts as a concern. You can see and adjust every list, dial and trigger, and turn sensitivity up or down at any time. Because monitoring reads the same traffic filtering inspects, the few sessions we cannot decrypt (section 1) are also outside content monitoring.
Monitoring supports your safeguarding response rather than replacing it: the platform surfaces and attributes risk in real time, your safeguarding team reviews and acts, and our account and support teams help you interpret what you see (section 5). For schools that want monitoring to extend onto the device itself, including off-network use, we work with a specialist partner (Smoothwall), whose own platform documentation covers the monitoring and alerting on that side.
Logging and Attribution
Every request through the filter is logged, as standard, to our central logging platform — a complete, searchable record of activity for safeguarding review and audit. Schools that take our additional logging and analytics option can include firewall traffic logs as well, for a fuller picture across the whole connection. This logged data is what both the reporting and alerting systems (section 3) draw on.
How users are identified. Logging can attribute activity to an individual, not just a device or an address, and there are several ways a user is identified, suited to a mixed school estate:
- A lightweight authentication agent on managed devices passes the signed-in user’s identity to the filtering platform at login, which places them in their correct policy group and attributes their activity by name. It is available for Windows, Chromebooks and macOS, and can take the user either from the device’s Active Directory sign-in or from the username supplied at login.
- A captive-portal sign-in does the same for devices without the agent — for example BYOD or guest devices on-site, and managed devices on the identified off-site proxy (section 2), where users log in against your local Active Directory.
- Where none of these is in place, activity is still fully logged and filtered, but attributed at the network level (by address) rather than by name.
So whether reports name individuals is your choice, and depends on the identification you deploy — agent, captive portal, and a directory for us to integrate with. Identification is by user or by network address; we do not rely on device hardware (MAC) addresses, which are not preserved across our routed core.
Access and audit. Authorised leads have two routes to the underlying logs. Day to day, you self-serve through our Hub portal, where reports and raw log data are available directly. For anything beyond that (a specific audit request or a historical pull), you raise a ticket with our support team, who extract a raw log report straight from the logging platform. Where deeper analytics or export into your own systems is required, centralised analytics and secure export to a school or trust SIEM/SOC are available as options.
Retention. Logs are retained for three years in line with our data-retention policy and UK GDPR, after which they are securely disposed of.
Responsiveness and Support Model
Our role does not stop at delivering the technology. Your account manager and Technical Account Manager are there to help you get the most from filtering and monitoring — guidance on interpreting alerts and reports, reviewing and adjusting your configuration, and acting as your point of contact when a safeguarding concern needs technical input. KCSiE 2026 is clear that technology alone does not discharge the safeguarding duty, so we work alongside your safeguarding team rather than handing over a dashboard and walking away.
Day-to-day support runs through the same channels as everything else: routine questions and configuration changes go through our Hub portal or a support ticket. Because every control described above is dialable, this is where you adjust it, turning a category up, widening inspection, adding a keyword, or changing who receives alerts — so your configuration keeps pace with your needs rather than being set once and forgotten.
It is important to be clear about where responsibility lies. Your safeguarding team is responsible for ongoing monitoring of alerts and reports: reviewing them, interpreting risk, and acting on concerns. We provide, tune, and explain the tools and data, but we do not monitor alerts on your behalf. If you need us to support a live safeguarding concern, we give it proportionate priority and escalate it ahead of routine support. This support is provided on request, by raising a ticket, rather than proactively, so the decision to involve us always rests with you. The accelerated response target for these requests is safeguarding response/resolution times.
