I treat public-sector cyber security as an operational resilience problem: if an attacker can stop staff from teaching, billing, issuing permits, or accessing records, the damage is immediate. In the UK, that means councils, schools, colleges, and universities need a security model that is simple enough for busy teams but strong enough to withstand phishing, ransomware, and account takeover. This article breaks down sled cyber security in practical terms, showing how the risk looks in UK organisations, which controls give the best return, and where smaller teams usually lose ground.
The practical version of this topic is about identity, recovery, and control of trusted access
- Most attacks begin with phishing or credential theft, not exotic exploits.
- UK education organisations are already better than average at the basics, but supply chain security and patching still lag.
- MFA, backup isolation, patch discipline, and SaaS hardening are the fastest wins.
- Incidents become expensive when teams do not know which systems matter most or who owns them.
- A small, well-run programme beats a large, incomplete one that nobody can maintain.
What SLED means in a UK public-sector context
The acronym is imported from the US, but the operating reality maps cleanly to the UK. I use it here to mean local authorities, maintained schools, academies, colleges, universities, and the third-party systems they depend on for payroll, email, learning, finance, transport, and records. The risks are similar, but the pressure points are not: a council worries about service continuity and citizen data, a school worries about safeguarding and coursework, and a university worries about identity sprawl, research access, and a much larger attack surface.
| Organisation type | What usually hurts first | What I would prioritise first |
|---|---|---|
| Local authority | Email, case systems, citizen records, remote access | Admin control, supplier assurance, logging, tested recovery |
| School or academy trust | MIS, shared mailboxes, safeguarding data, coursework | MFA, backups, phishing reporting, simple continuity planning |
| Further or higher education | Identity sprawl, cloud apps, research data, remote access | Identity governance, SaaS configuration, segmentation, monitoring |
These are different flavours of the same problem: too much trusted access and not enough disciplined recovery. Once you translate the acronym into a UK setting, the real question becomes how attacks usually enter.
Why phishing and account takeover still dominate
The latest GOV.UK education survey shows how routine the threat has become: 49% of primary schools, 73% of secondary schools, 88% of further education colleges, and 98% of universities identified breaches or attacks in the past 12 months. Among organisations that did suffer a breach, phishing was the dominant entry point, affecting 90% of primary schools, 96% of secondary schools, and 96% of further and higher education institutions combined. That tells me the real fight is still around identity, inbox control, and stopping one compromised account from becoming a broader outage.
- Phishing to mailbox takeover often leads to invoice fraud, payroll diversion, or internal impersonation.
- Stolen admin credentials can turn a single login into mass deletion, encryption, or data exfiltration.
- Supplier compromise can punch straight through a trusted SaaS tenant if access is too broad.
- Password reuse still creates easy unauthorised access to files, records, and remote management tools.
Ransomware is usually the loud end of the story, but it is rarely the first move. In education, it showed up in 6% of secondary schools and 14% of further and higher education institutions among those that had experienced an incident, which is enough to make recovery planning non-negotiable. That is why I spend more time on identity and recovery than on tools that only look impressive in a procurement slide.
The control stack that gives the best return
The NCSC’s public-sector guidance keeps coming back to the same priorities: manage risk, know your suppliers, and be ready to respond when something goes wrong. I read that as a warning against silver-bullet thinking. The controls that matter are the ones that break an attack chain, limit spread, and make recovery boring.
| Control | What it protects | What “done” looks like | Common failure |
|---|---|---|---|
| MFA on privileged and remote accounts | Stops stolen passwords from becoming admin access | Strong MFA everywhere it matters, with phishing-resistant methods for privileged users where possible | Exemptions for convenience or “temporary” access that never disappears |
| Backup isolation and restore tests | Lets you recover after ransomware or accidental deletion | Separate backup credentials, isolated storage, MFA for destructive actions, and regular restore tests | Backups exist, but nobody has restored a real service from them |
| Patch discipline | Closes known flaws before they are exploited | A risk-based patch policy, with exposed or critical systems moved within days rather than weeks | A written policy with no tracking of exceptions or overdue fixes |
| SaaS hardening | Protects email, files, HR, MIS, and learning platforms | Review sharing, conditional access, logging, retention, and third-party app permissions | Assuming the vendor’s defaults are secure enough |
| Logging and alerting | Shows abuse before it spreads | Alerts on privilege changes, mass downloads, mailbox rule changes, and unusual sign-ins | Logs are collected but never reviewed in practice |
| Supplier assurance | Reduces trusted third-party risk | Security questions at onboarding, access reviews, breach notification terms, and offboarding controls | A one-off questionnaire that is never revisited |
I would rather have these six controls working well than ten disconnected tools that nobody can maintain. The next step is sequencing them so a small team can keep the programme alive.
How I would phase the work over 90 days
If I had to tighten a council, school, or university environment quickly, I would not start with a giant transformation programme. I would break the work into three short phases and force each one to produce visible risk reduction.
Days 1-30
Map the critical services, the privileged accounts, and the data that would hurt most if lost or exposed. If you cannot name your finance system, your resident or student records, your email tenant, and your backup location, you do not yet have a cyber programme; you have a collection of tools. This is also the point where ownership matters, because security fails fastest when nobody is accountable for the same asset twice.
Days 31-60
Lock down admin access, remove legacy accounts, enforce MFA everywhere it matters, and test whether backups can actually restore a real service. This is also the stage where SaaS settings should be reviewed with a harsh eye, because cloud defaults are rarely the same as secure defaults. I would especially check sharing rules, guest access, and who can approve new apps.
Read Also: Automated Cloud Security - What to Automate First?
Days 61-90
Run a tabletop exercise with the people who would actually be involved in a breach: IT, service leads, safeguarding, communications, legal, procurement, and leadership. Make the test slightly uncomfortable. If it feels too polished, it probably did not surface the weak points you need to fix. The point is not to rehearse a perfect response; it is to find out where the real bottlenecks are before an attacker does.
The point of a 90-day plan is not perfection; it is momentum that a small team can sustain. That is where the common mistakes start to show up.
The mistakes that quietly undo good security
The biggest error I see is treating cyber security as a set of isolated tasks instead of a system of dependencies. The latest education survey makes the pattern obvious: supply chain security is still the weakest of the ten core areas, with only 44% of primary schools, 48% of secondary schools, and 48% of further education institutions covering it, even though higher education is doing better at 80%.
| Mistake | Why it hurts | What I would do instead |
|---|---|---|
| Training is treated as a yearly checkbox | Staff forget the warning signs and phishing still gets through | Use short, repeated awareness, plus reporting that feels easy and immediate |
| Cloud apps are assumed to be secure by default | Misconfigured sharing and access create silent exposure | Review each tenancy deliberately and document who owns the settings |
| Admin rights are left broad because it is convenient | One compromised account can change or destroy too much | Separate daily use from privileged access and review exceptions regularly |
| Backups are never tested | Recovery time becomes guesswork during an incident | Restore a real workload on a schedule, not just the backup job status |
| Supplier risk is handled once and forgotten | Trusted third parties become the easiest route in | Make supplier assurance part of onboarding, renewal, and offboarding |
Patch management shows a similar gap. A policy to apply software updates within 14 days exists in only 45% of primary schools and 62% of secondary schools, which is exactly why attackers still find easy openings in otherwise well-intentioned environments. When those gaps close, the whole security posture starts to look more coherent. That is why I finish every review by asking whether the organisation can recover without heroics.
The minimum standard I would set before calling the programme resilient
- Every privileged account uses strong MFA, and daily work is separated from admin access.
- Backups are isolated, restore-tested, and protected against destructive changes.
- Critical systems are listed, owners are named, and patch exceptions are tracked.
- SaaS apps are reviewed for sharing, logging, access, and retention settings.
- Staff know how to report phishing and suspicious activity without friction.
- Incident response includes IT, safeguarding, communications, legal, procurement, and supplier contacts.
- Supplier review is part of onboarding and renewal, not a one-time questionnaire.
When those pieces are in place, the organisation is no longer relying on luck. In UK public services, that usually means the difference between a contained incident and weeks of disruption, and it is the point where I would start spending on finer-grained detection and optimisation rather than basic survival.
