Bromcom, one of the most widely used MIS providers in England, has confirmed a personal data breach affecting a legacy single sign-on (SSO) registration service. Bromcom is now contacting affected schools and trusts directly. If you use Bromcom, this article explains what we know so far, what you need to decide as a data controller, and the practical steps that reduce your risk, both from this incident and the next one.

What happened?

According to Bromcom's SSO Personal Data Breach FAQs (last updated 30 September 2026), the incident involved older SSO registration functionality within Bromcom's Communication Server environment. This is the component that links a user's Microsoft or Google account to their school so they can sign in to Bromcom with SSO.

Bromcom explains that this functionality had already been replaced, but was still running in production because an internal system was still calling it. Bromcom first identified the incident on 6 September 2026, after schools reported problems signing in with SSO. Earlier versions of the FAQ described large-scale unauthorised deletion of SSO registrations, which is why some schools saw users suddenly unable to log in.

Bromcom's investigation has since found a wider group of schools where registration information was retrieved, including schools where nothing was deleted. In other words, if your staff did not experience any login problems in early September, that does not mean your school was unaffected.

What data was involved?

Bromcom states that the data held in the SSO service was limited to:

• email addresses associated with SSO registrations (staff and pupils), note some of these email addresses could have been personal email addresses;
• which SSO provider was used (for example Microsoft or Google);
• registration and last sign-in dates, where held; and
• internal user and registration reference numbers, and in some cases PIN-related information used for checks after sign-in.

Bromcom is clear that the component did not hold passwords or authentication tokens, that a PIN cannot be used on its own to sign in, and that it has found no evidence that MIS data was accessed or that any Bromcom account was taken over. Parents are not affected because the parent app does not use this service. However, Bromcom also says its investigation into whether data was copied or exfiltrated, and how many records were involved, is still ongoing.

What has Bromcom done?

Bromcom reports that it has withdrawn the legacy SSO functionality, added extra school and account authorisation checks, restricted self-service removal so users can only remove their own registration, improved logging and security audit records, and recovered the deleted email-address records. It has said it will consider a root cause analysis once the investigation is complete.

What is Bromcom used for, and what data could be at risk?

To understand the risk, it helps to remember what sits behind a Bromcom login. Bromcom is a cloud-based management information system (MIS), and for many schools and trusts it is the central record of almost everything they know about their pupils, families and staff. Depending on which modules your school uses, Bromcom may hold:

• Pupil records: names, dates of birth, addresses, unique pupil numbers, photographs, ethnicity, first language and other census data.
• Family and contact data: parent and carer details, emergency contacts, and parental responsibility and contact arrangements.
• Attendance and behaviour: daily attendance, absence reasons, exclusions and behaviour incidents.
• Assessment and exams: progress data, reports, exam entries and results.
• Special category and sensitive data: SEND information, medical conditions and allergies, free school meals and pupil premium eligibility, looked-after status, and, where the safeguarding module is used, safeguarding and child protection records.
• Staff data: contact details, contracts and HR records where the HR module is used.
• Finance and payments: school finance records, and parent payment and dinner money information through MyChildAtSchool and the payment systems.
• Trust-wide data: MATs using Bromcom Vision may also have aggregated data and dashboards across all their schools.

Staff, pupils and parents reach this information through the Bromcom MIS, the Student Portal and the MyChildAtSchool app.

So was this data affected?

Based on what Bromcom has said so far, no. The data involved in this incident is limited to the SSO registration information listed above (email addresses, sign-in provider, dates and internal reference numbers). Bromcom has found no evidence that MIS data was accessed or that any Bromcom account was taken over.

But the SSO registration service is the gateway to all of the data above. Staff who sign in to Bromcom with Microsoft or Google are using that account as the key to pupil records, SEND and medical information, and potentially safeguarding files. If an attacker uses the leaked details to phish a staff member's Microsoft or Google password, and that account is not protected by strong MFA, the attacker could potentially sign in to Bromcom as that person and see whatever their role allows.

This is why the follow-on risk matters so much more than the leaked email addresses themselves, and why it is so important that:

• staff accounts used to sign in to the MIS are protected by MFA;
• staff only have access to the Bromcom modules and data they need for their role, so that one compromised account exposes as little as possible; and
• access to the most sensitive areas, such as safeguarding, SEND and medical records, is restricted to the people who genuinely need it and reviewed every term.

Our article Not everyone needs access covers role-based access in more detail.

Why this matters, even if "it's only email addresses"

It is tempting to treat this as low risk. No passwords, no MIS data, no parents. But look at the dataset from an attacker's point of view: a verified list of school email addresses, matched to a named school, with confirmation of whether each person signs in with Microsoft or Google, and when they last did so.

That is exactly what is needed to run a convincing, targeted phishing campaign. A fake "Microsoft sign-in" page sent to someone known to use Microsoft SSO, branded to look like their MIS, is far more likely to work than a generic scam. Some pupil registrations also used personal email addresses, which takes the risk outside the school's own protected systems.

We saw the same pattern after the DfE cyber attack earlier this year, and in the payroll fraud attacks on Thames Valley schools: the initial breach is rarely the end of the story. The follow-on attacks are where the harm happens.

Watch for the knock-on effects

Bromcom has not yet confirmed whether the data was copied or taken. Until it does, the safest assumption is that it may have been, and that it could end up being sold or shared on the dark web. Lists of verified school email addresses are valuable to criminals, and they can resurface months after the original incident.

Ask your IT support to keep a closer eye on the following, and to tell you if they see a change:

• Increasing login attempts. A rise in failed sign-ins, account lockouts or password-spraying attempts against staff or pupil accounts in Microsoft 365 or Google Workspace.
• Unexpected MFA prompts. Staff reporting approval requests they did not trigger, which can mean someone already has their password.
• More phishing. An increase in phishing emails reaching staff or pupils, especially messages that mention Bromcom, the MIS, SSO, "account verification" or Microsoft or Google sign-in.
• Unusual account activity. Sign-ins from unfamiliar locations or devices, new mailbox forwarding rules, or changes to payroll or bank details.
• Your data appearing elsewhere. Breach-monitoring services and the free NCSC Early Warning service can alert you if your domain or accounts appear in leaked data.

If you notice any of these, treat it as a possible new incident: report it to IT support and your DPO straight away, and record it alongside the original Bromcom entry in your breach log. A pattern of small events is often the first sign of a larger attack.

Above all, staff need to be more vigilant than usual for the coming months. Make sure everyone knows that this incident has happened, why it raises the risk of targeted scams, and exactly how to report something that doesn't look right.

Your responsibilities as a data controller

Bromcom has confirmed that it has not reported the incident to the ICO, because it acts as a data processor for this data. It is contacting each data controller (the school or trust) so that they can assess the incident and decide what to do.

That puts the decision with you. In practice, this means:

• Log it. Record the incident in your breach log now, even if you conclude it is not reportable. Your record should show what you knew, when you knew it, and how you reached your decision. (Accountability under UK GDPR applies whether or not you report.)
• Assess the risk. Consider who is affected (staff, pupils, any vulnerable individuals), whether personal email addresses were involved, and the likelihood of phishing or other harm. Your DPO will support you with this.
• Decide on ICO reporting. If the breach is likely to result in a risk to individuals' rights and freedoms, it must be reported to the ICO within 72 hours of you becoming aware of it. The ICO formally became the Information Commission on 30 September, but reporting works in the same way. DPE cuIf you are not a DPE customer, speak to your own DPO.
• Consider telling individuals. Even where you don't need to notify individuals formally, a short, calm message to staff (and age-appropriate messaging to pupils) warning them about targeted phishing is a sensible, proportionate step.
• Keep updating. Bromcom's investigation is ongoing and its FAQ has changed several times. Revisit your assessment when you receive your school-level data or Bromcom's findings change.

DPE Knowledge Bank subscribers can use the Data Breaches checklist and breach log, and should contact the DPE helpdesk for support with their assessment.

A note on processor timescales

UK GDPR requires processors to tell controllers about a personal data breach without undue delay. Bromcom identified the incident on 6 September, and many schools were contacted towards the end of the month. Bromcom's explanation is that it wanted to provide accurate, verified school-level information. Whatever your view on that, it is a useful prompt to check what your contracts with key suppliers actually say about breach notification timescales, and whether those timescales give you enough room to meet your own 72-hour deadline.

How could this have been mitigated?

It is important to be honest here: this incident happened inside Bromcom's environment, so there was very little an individual school could have done to prevent it. The main lessons for schools are about limiting the impact of supplier breaches and holding suppliers to account. Several of the DfE Digital and Technology Standards are directly relevant.

1. MFA on your SSO accounts: the most important control

SSO is a good thing. It means fewer passwords, easier joiners-and-leavers processes, and one place to control access. But it also concentrates risk: if an attacker gets one set of credentials, they may get everything that account can reach.

The NCSC's guidance on password administration for system owners makes this point directly: because a compromised SSO account gives an attacker access to far more, the NCSC recommends that SSO is implemented to require MFA. The NCSC's guidance on choosing the right authentication method also recommends prompting for an additional factor when sign-in activity looks suspicious, such as a new device or an unusual location. And the NCSC now encourages organisations to use the strongest type of MFA that is practical, ideally phishing-resistant methods such as passkeys or security keys.

In the Bromcom case, the attacker now knows who uses Microsoft and who uses Google. If those Microsoft 365 or Google Workspace accounts are protected by strong MFA, a phished password alone is not enough to get in. If they are not, the exposed data becomes a ready-made target list.

The DfE Cyber Security Core Standard is clear that MFA must be enabled for:

• all staff accounts with access to cloud services or remote access to on-site systems; and
• all IT administrative accounts.

It also says enhanced security such as MFA should always be used where staff handle confidential, personal or sensitive personal data, and that your DPO can advise which systems need it. Your MIS and the Microsoft or Google account that signs into it clearly fall into that category.

For more on getting MFA right, see our guide to multi-factor authentication, our article on MFA bombing (where attackers spam approval requests until someone taps "yes"), and the role of passkeys.

2. What the DfE standards say about SSO

The DfE standards actively encourage SSO. The Cyber Security Core Standard says that where staff access a number of systems, schools should consider an SSO solution. The Cloud Solutions standard goes further, saying schools should use a central ID and access management tool, so that each user has one centrally managed account and access is managed by group. Its technical requirements include:

• using the ID management system as the only way staff and students log on;
• agreed, documented processes for adding and removing users;
• role-based access so each type of user gets the right level of access; and
• making sure IT support has separate, secure access to cloud systems, independent of the ID management system.

That last point is worth highlighting after this incident. When Bromcom's SSO registrations were deleted, some users simply could not get in. A "break-glass" route that does not depend on SSO is part of good resilience planning, and should be covered in your business continuity plan.

The Core Standard also asks IT support to consider tools that link to the MIS to create and remove accounts automatically, and to review accounts every term. Stale accounts and old registrations are exactly the kind of "legacy" exposure that caught Bromcom out.

3. Logging, monitoring and SIEM

You may have heard SIEM (Security Information and Event Management) suggested as the answer to incidents like this. A SIEM collects logs from different systems in one place and raises alerts when it spots suspicious patterns. It is worth being realistic about it:

• The DfE standards do not require a SIEM. What the Core Standard does require is that IT support discuss and agree the right level of logging for your network and systems, actively monitor firewall traffic and alerts, centrally monitor anti-malware, and monitor for possible cyber incidents. It points to the NCSC's guidance on logging and protective monitoring and the free NCSC Early Warning service.
• A school's own SIEM would not have detected this breach, because it happened in Bromcom's systems, not yours, but it might detect the knock-on effects and follow up incidents that can occur following a breach like this.
• Where monitoring does help is the follow-on risk. Sign-in logs and alerts in Microsoft Entra ID or the Google Workspace admin console can flag unusual sign-ins, impossible travel, repeated MFA prompts or new mailbox forwarding rules. Many schools already have these features within their existing licences. Larger trusts may find a SIEM or managed detection service worthwhile across multiple schools; most individual schools will get more value from switching on and actually reviewing the alerts they already have.

Monitoring is also a supplier question. Bromcom's own remediation includes improving logging and security audit records. Ask your key suppliers how they log and monitor access to your data, and how quickly they would detect unusual activity.

4. Supplier assurance and legacy systems

This incident came from a component that had been superseded but never switched off. That is a very common problem, in schools as well as suppliers. The DfE standards ask schools to keep asset and contracts registers up to date, remove unnecessary software, and assess third-party cloud suppliers when procuring. The Cloud Solutions standard also requires that roles and responsibilities for a data breach are clearly documented, and that your agreement with the provider says it will share information promptly if there is a breach.

Practical questions to add to your supplier reviews:

• How do you identify and retire legacy components and integrations that are no longer needed?
• Do you hold Cyber Essentials Plus, ISO 27001 or equivalent, and when were you last independently penetration tested?
• How quickly will you notify us of a personal data breach, and what will you tell us?
• What logging and monitoring do you have on access to our data?
• Will you share a root cause analysis after an incident?

Our articles on supplier due diligence step by step and the multiple dimensions of supplier due diligence cover this in more detail. Academy trusts should also note the new MIS procurement expectations in the Academy Trust Handbook 2026, which comes into effect today, and our DPO lens on the DfE's Choosing an MIS guidance.

5. Awareness: training can't be just once a year

The DfE Cyber Security Core Standard sets annual cyber training as the minimum, covering phishing, MFA, and how to report a cyber incident and a personal data breach. But the same standard says training should happen more regularly where there is a known cyber risk. A breach that hands attackers a list of your staff and pupil email addresses is exactly that kind of known risk.

An annual course in September won't protect anyone from a convincing phishing email in February. Awareness needs to be ongoing:

• Brief staff now about this incident, in a staff meeting, briefing or email, rather than waiting for the next training cycle.
• Use short, regular reminders through the year: micro-learning, briefing slots, posters and real examples of phishing emails your school has received.
• Refresh after every incident or alert, including supplier breaches like this one, so the warning lands while the risk is live.
• Include everyone with a login, not just teaching staff: support staff, supply and agency staff, governors and trustees, and pupils (in an age-appropriate way).

Our article on when the annual training cycle doesn't fit covers how to reach staff who miss the main training window, and Cyber Security Awareness Month, which starts today, is a good moment to restart the conversation.

Use this incident as a timely, real example. Remind staff and pupils that:

• neither Bromcom, Microsoft nor Google will ask them to "re-register", confirm their password or approve a sign-in they did not start;
• unexpected MFA prompts should be denied and reported, not approved;
• messages that mention Bromcom, SSO or "account problems" should be treated with extra suspicion for the next few months; and
• anything suspicious should be reported to IT support straight away, without fear of blame.

Quick action checklist for Bromcom schools and trusts

1. Check whether you have received a notification from Bromcom, and make sure the right contact details are held for your school or trust.
2. Log the incident in your breach log and contact your DPO.
3. DPE customers: pass any Bromcom notification and school-level information to the DPE helpdesk, and we will report to the ICO on your behalf. Other schools: assess the risk with your DPO and decide on ICO reporting within 72 hours of becoming aware, recording your reasoning either way.
4. Brief all staff now about the incident and the heightened phishing risk, and give age-appropriate guidance to pupils. Don't wait for the next annual training session.
5. Ask IT support to watch for knock-on effects: rising login attempts, unexpected MFA prompts, more phishing, and any sign your data has appeared on the dark web.
6. Confirm with IT support that MFA is enforced on all staff Microsoft 365 or Google Workspace accounts and all admin accounts, ideally using phishing-resistant methods.
7. Ask IT support to review sign-in logs and alerts for unusual activity since early September.
8. Check that you have a documented, non-SSO "break-glass" route into critical systems.
9. Review your contract and data processing agreement with Bromcom, particularly breach notification terms, and add the incident to your supplier risk register.
10. Revisit your assessment as Bromcom updates its findings.

Further reading

• Bromcom: SSO Personal Data Breach FAQs
• DfE: Cyber Security Core Standard
• DfE: Cloud Solutions standard
• NCSC: Password administration for system owners
• NCSC: Authentication methods, choosing the right type
• DPE: DfE Cyber Security Standards, June 2026 update
• DPE: A risk-led order for the DfE Digital Standards
• DPE: Safeguarding identity in Microsoft 365
• DPE: Is your IT support provider compliant?

This article reflects Bromcom's FAQ as updated on 30 September 2026. Bromcom's investigation is ongoing and we will update this guidance as more information becomes available. DPE customers: we will report this incident to the ICO on your behalf. Please contact the helpdesk with any notification you receive from Bromcom.