Navigating the UKSIC Appropriate Monitoring Guidance
The UK Safer Internet Centre, UKSIC, has updated the Appropriate Filtering and Monitoring guidance for 2026, aligning directly with the upcoming statutory changes in the KCSIE 2026 guidance launching this September.
For schools, there are clear expectations for both you and the monitoring tools you use. We are pleased to say that classroom.cloud’s safeguarding offer meets, and in many cases exceeds, those expectations.
What is the difference between active and proactive school monitoring?
The guidance sets out three monitoring approaches:
- physical supervision,
- logfile-based internet monitoring, and
- active or proactive technology monitoring.
For most schools, the third is the most active area. Active monitoring means the system generates alerts for school staff to act upon; proactive monitoring goes further, with a specialist third party supporting triage and intervention alongside the school’s own team.
How does classroom.cloud meet the 2026 UKSIC active monitoring standard? 
classroom.cloud is a fully active monitoring solution. Its safeguarding toolkit monitors keywords and phrases typed by students across supported devices, drawing on a database of over 20,000 terms covering self-harm, bullying, radicalisation, sexual exploitation, gambling, drugs and more, across multiple languages, including slang terms. The database is developed in collaboration with school counsellors, safeguarding leads, local authorities, the Internet Watch Foundation, leading charities and young people themselves, and is updated regularly. Schools can also view and add their own terms, sharing them across a trust if needed.
For schools that need additional capacity, the optional Assisted Monitoring service, delivered in partnership with the South West Grid for Learning (SWGfL), provides specialist third-party triage. The SWGfL team reviews alerts within the classroom.cloud account, prioritises concerns and actively notifies school safeguarding staff of genuine threats to health or life. This is the proactive monitoring model the guidance describes as most effective in higher device environments, and it extends school safeguarding capacity without placing additional burden on already stretched DSL teams.
How does classroom.cloud manage safeguarding, alert prioritisation and staff capacity?
The guidance is clear that active monitoring only works where there is sufficient internal capacity and appropriate safeguarding expertise to review, prioritise and act on alerts. A system that generates high volumes of false positive alerts without helping staff identify them is not doing its job.
classroom.cloud’s contextual Risk Index assesses each triggered event against a range of factors: the nature of the phrase, the device used, the time of day, websites visited, applications in use and the student’s previous activity and alert history. The result is a numerical risk score, colour-coded from low to urgent, that allows DSLs to see immediately which alerts need attention and which can wait.
Evidence is captured proportionately: low-priority triggers generate a text log; high-priority triggers capture a screenshot; urgent triggers capture a screenshot and a screen recording. Configurable summary reports can be sent daily, weekly or monthly to nominated staff, ensuring nothing falls through the gaps.
Safeguarding Groups add another layer of control, allowing schools to segment students by year group, vulnerability status, AD group or device, and apply tailored monitoring settings, alert thresholds and assigned staff members per group. A student already known to the DSL can be monitored differently from the general cohort, with alerts routed to the right person automatically.
What are the user attribution and audit log requirements for school monitoring?
The guidance requires monitoring systems to identify users and attribute activity to enable timely intervention, and that changes to the system are logged to prevent unilateral alterations.
On school devices, every trigger in classroom.cloud is attributed to a username, device, device group, site, class and teacher where available. Where shared devices are in use, monitoring applies restrictions and configurations based on user profiles. iOS users must be using Google or Microsoft logins for reliable identification.
Six distinct role levels control access to the platform, and a full audit log records all configuration changes, trigger status updates, notes and reassignments with date, time and the responsible user.
Does classroom.cloud support BYOD and mobile device monitoring for schools?
classroom.cloud supports BYOD (Bring Your Own Device) environments. IT teams can manage and monitor student activity from a central web portal, with monitoring conditions configured based on factors such as time, date and network location.
BYOD implementations can include school-owned devices as well as personally owned student devices, subject to each school’s policies and requirements. Schools have full control over how and when monitoring is applied and should ensure that any monitoring of personal devices is appropriate, proportionate and communicated clearly to students and parents.
What are the 2026 guidance requirements for Generative AI logging and reporting?
The 2026 guidance requires schools to maintain robust logging of student interactions with AI tools and to generate reports on AI system usage within the school.
classroom.cloud monitors student interactions with AI platforms, including ChatGPT, Copilot, Gemini, Claude, Perplexity and others. When a keyword trigger is captured while using an AI tool, an AI indicator appears in the source field. DSLs can filter the safeguarding portal to display only AI-context triggers, and the Activity tool supports the oversight of AI usage patterns across the school. For Microsoft Copilot specifically, classroom.cloud captures triggers when the student is signed into Copilot using their school account and can monitor Copilot chat interactions.
Device-level monitoring cannot intercept AI-generated output before it reaches a student’s screen. That is true of every solution in this category, not just classroom.cloud. You should be clear where your monitoring layer ends and where filtering, access controls and teaching practice take over. classroom.cloud captures, logs and alerts on concerning activity after it occurs; that is what the guidance asks of a monitoring tool, and it is exactly what classroom.cloud does.
How does classroom.cloud integrate with safeguarding case management and data protection frameworks?
The guidance expects monitoring systems to integrate with school safeguarding and well-being systems. classroom.cloud has integrated directly with MyConcern and CPOMS for some time, recognising the importance of connecting the dots with safeguarding: triggered events, including screenshots and screen recordings, can be sent directly to a student’s case record from within the portal.
On data protection, classroom.cloud is registered with the UK ICO and processes data under UK GDPR, with public task and substantial public interest as the lawful bases for safeguarding data. A full Data Processing Agreement, Privacy by Design statement and dedicated Privacy Centre are all publicly available. Safeguarding and audit data is retained for 13 months; activity monitoring data for 90 days. The platform holds ISO/IEC 27001 certification and is hosted on Microsoft Azure UK infrastructure. Monitoring is off by default and can only be activated by the school.
Take the next step toward September 2026 compliance
Do not wait for KCSIE 2026 to land before reviewing your digital monitoring strategy. You can access our full compliance mapping document right now to see exactly how classroom.cloud aligns with every single requirement of the updated UKSIC framework.
Get in touch with our education experts today to book a tailored, interactive demonstration for your school, or download the complete compliance resource to share directly with your trust executives and governors.