A small Church of England primary school in the UK was hit by the SafePay ransomware group this week, with the breach discovered on 28 July. It’s not the kind of incident that makes national news, and that’s exactly the point worth taking from it. SafePay is an active ransomware operation that’s spent the past year working through a mix of targets — some large, most not — and a story like this rarely gets attention because a school isn’t a household name. But the mechanics are identical to the ransomware incidents that do make headlines: a small organisation with limited IT resource, systems worth locking, and no security team standing between an attacker and the network.

Small doesn’t mean low-risk — it means under-defended

The uncomfortable truth in stories like this is that ransomware groups don’t pick targets by size or profile; they pick targets by opportunity. A school, a five-person accountancy practice, and a family-run manufacturer all look the same to an attacker running automated scans for exposed remote access, unpatched software, or weak credentials — what matters is whether the door was left open, not what’s behind it. If anything, smaller organisations are more attractive precisely because they’re less likely to have dedicated security monitoring, tested backups, or an incident response plan sitting ready to go. “We’re too small to be a target” remains one of the most expensive assumptions a business can make.

What actually would have helped here

Without knowing the specific entry point in this case, the pattern across nearly every small-organisation ransomware incident is consistent: an internet-facing system without multi-factor authentication, a patch that was available but not applied, or a phishing email that got through because nobody was expecting to be a target. None of the fixes are exotic — MFA on every remote-access point and every cloud account, a patching cadence that doesn’t wait for a quiet month, and backups that are tested and kept genuinely offline from the live network so they survive an attack rather than getting encrypted alongside everything else. If you don’t currently have visibility into whether your organisation’s credentials or systems have already shown up in a breach or dark-web listing, that’s worth checking rather than assuming — KeepSafe monitors for exactly this kind of exposure so you find out before an attacker does.

Build the response plan while it’s hypothetical

The organisations that recover fastest from a ransomware hit are the ones that had already answered the hard questions before the attack: who makes the call on paying or not paying, who needs to be notified and within what timeframe, and who actually has the technical access to rebuild systems from clean backups. Writing that plan costs an afternoon. Improvising it during an active incident costs days, and days matter enormously when systems are down and people are relying on you.

The cost isn’t just the ransom, and the exposure isn’t just yours

Even organisations that never pay a ransom absorb real cost: lost productivity while systems are rebuilt, and often a legal obligation to notify people whose data may have been affected, on a clock that starts the moment the breach is discovered. Knowing that obligation in advance beats researching it mid-incident — a short, plain-English breach policy is far cheaper to write on a calm afternoon than to improvise under pressure, and Smallprint has templates built for exactly this. It’s also worth extending the same scrutiny to anyone who holds your data or connects into your systems — a payroll provider, an IT contractor, a booking platform. Small organisations are frequently breached not directly but through a smaller supplier with weaker security than they have themselves, and a short conversation about their MFA and backup practices costs nothing.

The takeaway

This week’s story is a school, but the lesson applies to every small organisation running any of its operations on a network: MFA everywhere, patch on a schedule rather than a whim, keep tested backups genuinely offline, and write the incident response plan before you need it rather than while you’re living through it.