A multi-academy trust does not have a cyber security problem; it has eight or eighteen of them, plus a harder one underneath — governing risk across schools it is accountable for but does not operate day-to-day. This guide is about that estate problem: the central /academy split, honest visibility, and reporting a trust board can actually use.
The split that has to be written down
The single most useful artefact a trust can produce is one page saying which cyber responsibilities are central (identity tenancy decisions, MFA policy, backup standards, incident command, supplier due diligence) and which are academy-local (local devices, local awareness, local incident first response, the site-specific contacts). Every MAT incident post-mortem contains the sentence “we each thought the other had it” — the page is how you delete that sentence in advance. An incident happens to a school, at 8am, locally; a trust-wide plan that is right about the trust and wrong about the school is wrong where it matters.
Estate visibility — and its honest limits
Central teams need to answer “where does the estate stand?” without ringing eight IT providers. That means some standardisation (one identity approach, one backup standard, one reporting route) and some tooling. Two principles keep the visibility honest:
- Consent and privacy have boundaries inside a trust. Central seeing an academy’s security posture is legitimate governance; central quietly reading things an academy never agreed to share is how trust (the other kind) erodes. Make what central can see explicit, per academy — the same discipline the trust demands of its own suppliers.
- Never rank academies against each other. A league table teaches schools to stop reporting, and an estate that under-reports is an estate central is blind to. Compare each academy to the standard, never to its neighbour, and treat a low score as a resourcing question rather than a performance one.
The problems every MAT recognises
- Inherited estates — every joining academy arrives with its own domain, provider, backup habits and surprises. A joining checklist (identity, email records, backups, admin accounts, supplier list) turns conversion chaos into a known process.
- Provider sprawl — five academies, four IT providers, no common standard. Consolidation is a years-long journey; a common standard each provider must evidence against can happen this term.
- The unowned middle — email records, MFA policy and admin-account hygiene sit exactly on the central/academy seam, which is why they are the commonest estate-wide gaps. Assign them centrally; they are cheap to fix once owned. (Email records especially: every academy domain needs its own, and the estate is only as strong as its weakest one.)
- Evidence scattered across mailboxes — due diligence, insurance conditions and DfE expectations all land on the trust, and the evidence lives in eight inboxes. One place, one format, dated.
Reporting a trust board can use
A trust board needs one page: the estate position in words, what changed, the risks with owners, and the decision being asked. Per-academy detail belongs in the appendix; the board governs the trust. The governors’ ten questions work at trust level almost unchanged — with question one sharpened to: who is accountable centrally, who is responsible locally, and where is that written down? The DfE expectations apply per school, so central’s job is knowing the gaps per academy with dates — not asserting estate-wide compliance nobody has checked.
Questions for the central team
- Which academies could we NOT answer “is MFA enforced?” for, today?
- If academy X was encrypted tonight, whose incident is it at 8am — named, not implied?
- Which academy domains have no DMARC enforcement, and who owns fixing that centrally?
- What does our joining checklist actually check — and did the last conversion follow it?
- Could we produce, this week, the evidence our insurer’s conditions assume exists?