The cyber attack affecting Bristol schools is a serious incident with consequences for pupils, families and staff. For those affected, the immediate concerns are understandably about personal information, safeguarding and getting schools back to normal.
The investigation is ongoing. Important questions remain unanswered, and we should be careful about drawing conclusions about how the attack happened or what might have prevented it.
However, there are lessons worth considering, particularly for anyone responsible for digital infrastructure across multiple schools.
What we know about Bristol
Bristol City Council says it identified suspicious activity on its Schools IT network in September 2026. Once the cyber attack was identified, 88 schools were disconnected from the network.
On 30 October, the council received information indicating that stolen data had been published online. Its investigation suggests that approximately 320,000 files may have been taken, with 39 schools potentially affected by the data theft.
The council has stressed that being among those 39 schools doesn’t necessarily mean that a school’s data was stolen. Investigators are still establishing which information and individuals have been affected.
Bristol’s School ICT Services provides shared technology services, including internet connectivity, technical support and assistance with school management systems.
The incident therefore raises a question that reaches well beyond Bristol.
If you’re responsible for digital systems and data across a group of organisations, should you bring them into a common ecosystem or deliberately keep them separate?
Consider a multi-academy trust with 40 schools.
You could have 40 schools running their own systems, identities, devices and security policies. Alternatively, you could bring them together.
Both approaches have advantages, and both introduce risks.
Option one: create a common ecosystem
There are good reasons to centralise.
In Microsoft 365, for example, you could establish a common identity system through Microsoft Entra ID, manage devices through Microsoft Intune, apply consistent Conditional Access policies and use Microsoft Defender for monitoring and protection.
A central team can make sure that multifactor authentication (MFA) is enabled, devices meet an agreed standard and security policies don’t depend on the knowledge or resources available within an individual school.
You reduce duplication too.
You don’t need 40 different approaches to device management, identity, security, procurement and support.
However, you’ve also changed the potential impact of something going wrong.
A compromised privileged account with organisation-wide permissions could expose considerably more than an administrator account belonging to one independent school. A poor configuration could affect thousands of users rather than hundreds.
An outage can become everybody’s outage.
A common ecosystem may also present a more valuable target because of the number of systems and records that an attacker could potentially reach.
Centralisation can reduce the number of environments you need to secure. However, the consequences of compromising a powerful shared component can be much greater.
Option two: keep organisations separate
There’s another approach.
Let each school retain its own identity environment, systems, administration and security boundaries.
If one school is compromised, there may be a natural boundary around the incident.
An attacker who compromises School A doesn’t automatically gain access to Schools B, C and D, provided that those environments are genuinely isolated and don’t share vulnerable credentials, management tools or connections.
Local administrators can maintain control of their systems, and schools can choose technology appropriate to their requirements.
However, there’s a significant downside.
You’ve now got 40 environments to secure.
One school might have effective MFA, Conditional Access, Microsoft Intune and device compliance policies. Another might have little of that protection.
Configurations drift. Updates get missed. Suppliers differ. Staff leave, and privileged accounts aren’t always removed.
Central security teams also have a much harder job answering a simple question:
Are all 40 of our schools secure?
Option three: share the platform, separate the risk
A group doesn’t necessarily have to choose between one enormous environment and 40 completely independent ones.
You can centralise some things whilst deliberately separating others.
Take Microsoft 365.
A trust could operate a common tenant but design administrative boundaries between its schools. It could use least-privilege roles, Privileged Identity Management (PIM), separate administrator accounts, Conditional Access and carefully designed permissions.
Microsoft Intune can provide common device standards whilst devices remain organised and managed according to school or organisational boundaries.
SharePoint permissions and information architecture matter too. Being part of the same Microsoft 365 tenant doesn’t mean that everybody needs access to everybody else’s information.
However, there’s an important distinction here.
Administrative boundaries within a shared tenant aren’t necessarily the same as independent security boundaries.
Some privileged roles and services operate across the entire tenant. A sufficiently powerful compromised account, or a failure in a shared dependency, could still affect multiple schools.
Separating risk therefore requires careful attention to which accounts, systems and services retain cross-school access. It also means testing those boundaries rather than assuming that organisational units, groups or labels provide isolation.
The same principle extends beyond Microsoft 365.
You can centralise procurement, monitoring, standards and expertise whilst retaining stronger technical boundaries around sensitive systems and data.
That’s a very different model from simply putting everyone on the same network.
The questions that matter
A practical way to test the resilience of shared infrastructure is to start with a simple scenario:
If one school is compromised at 10 am tomorrow, what can the attacker reach by 10.30 am?
Can they reach another school’s files?
Can they compromise another school’s devices?
Can they reset another user’s password?
Can they access payroll, safeguarding information or management information system (MIS) data?
Can they elevate their privileges?
Can the security team see them doing it?
Those questions reveal far more about an organisation’s resilience than whether its infrastructure is described as centralised or decentralised.
They also provide a practical exercise for a trust’s IT leadership team. Choose one school, assume that an account or device has been compromised, and map the permissions and connections that might allow an attacker to move further.
Then check whether the controls intended to stop that movement work.
What Bristol should make us consider
The Bristol cyber attack remains under investigation. We don’t yet know enough to conclude that shared infrastructure caused the data theft or that a different architecture would have prevented it.
The council and its partners are working to understand what happened, support affected schools and restore services safely. That work deserves recognition, particularly given the disruption that schools have experienced.
Every serious incident gives the wider education sector an opportunity to examine its own arrangements. We can do that whilst respecting the people dealing with the immediate consequences.
For anyone running shared education technology, the question is worth asking now:
We know what we’ve gained by connecting our organisations. Have we been equally deliberate about what keeps them apart?