Ofqual reported on 1 October 2026 that 27% of surveyed schools experienced a cyber incident during the 2025–26 academic year, compared with 29% the year before. It also reported that 66% of affected schools recovered immediately, up from 55%. The release nevertheless highlighted uncertainty about responsibility for keeping systems safe. These are findings about the surveyed education setting, not a measurement of all British organisations. For technology suppliers, they raise a useful question: does the customer know who must do what when a service fails? [1]
The NCSC’s Exercise in a Box guidance explicitly brings leadership, cybersecurity and potentially HR or communications into structured discussion. That provides a practical way to examine the responsibility gap without pretending that a written plan proves operational readiness. [2]
A better outcome does not settle accountability
Faster recovery is encouraging, but it does not tell us whether responsibilities are understood before an incident. A service can return quickly because a small number of people work exceptionally hard, while the underlying process remains fragile. Suppliers should avoid using an improving headline as proof that customer support is adequate. Ask instead whether the relevant people can identify the first contact, the decision authority and the fallback arrangement. In a school, those answers may involve leaders, technical staff and an external provider. In a business, the equivalent chain may cross procurement, operations and several contractors.
Describe the service boundary in ordinary language
Contracts can define responsibilities without making them understandable to everyday users. A customer-facing summary should explain what the supplier monitors, what the customer must maintain and what happens outside normal hours. It should identify dependencies without using them to disclaim every difficulty. For an international provider selling into France, the summary needs to reflect the actual local support arrangement, including language and escalation availability. A translated global brochure is not enough if the French customer’s service is delivered through a different partner. Public promises and operating instructions should refer to the same service, not to an idealised standard offer.
Rehearse the non-technical decisions
A cyber exercise should include the decisions that fall outside engineering. Who tells users that a service is unavailable? Who decides whether to continue an activity through a fallback process? Who approves a statement when the cause is not yet known? Ask a manager unfamiliar with the technical system to use the guidance under time pressure. Their questions will often reveal gaps that specialists overlook. The exercise should test handovers and comprehension, not just whether a template exists. A document that can only be interpreted by its author is not a reliable part of incident readiness.
Make recovery claims comparable
The word recovered can describe several different states: the system is online, critical functions are available, normal service is restored or all consequences have been assessed. A supplier should specify which meaning applies when reporting an incident. This avoids announcing full restoration while users still face restrictions. If a company publishes a performance figure, it should define the population, time period and measurement method. The Ofqual figures should not be borrowed to suggest that a particular commercial service performs well. They are a prompt for better questions, not a substitute for the provider’s own evidence.
Protect people from being made the explanation
After an incident, organisations sometimes focus public attention on an individual error before understanding the wider process. That can discourage reporting and hide design weaknesses. Communications should distinguish verified facts from assumptions about responsibility and avoid naming or blaming individuals unnecessarily. Internal messages should tell employees how to report concerns and obtain help. A supplier can acknowledge a problem and explain immediate safeguards while the investigation continues. The goal is not to evade accountability; it is to locate accountability accurately enough that corrective action improves the system rather than simply producing a convenient public narrative.
Turn the survey into a customer conversation
For a technology business, the most useful response to the survey is a practical discussion with customers. Ask them to identify their contact route, their most important functions and the point at which they need a public explanation. Compare those answers with the service documentation. Where they differ, correct the process before producing an awareness campaign. A short, jointly reviewed incident card can be more useful than a long security presentation. It should be updated after changes to personnel or service scope, and its usefulness should be tested rather than assumed because it has been distributed.
What leaders should ask this month
Request evidence that customers and staff understand the incident process, not only evidence that security training occurred. Review the wording used for interruption, containment and restoration. Identify a realistic scenario where the technical solution is delayed and the organisation must still communicate responsibly. Belief System supports crisis preparation, stakeholder information and international coordination alongside cybersecurity teams. The purpose is to make responsibility visible before pressure exposes ambiguity. This article uses Ofqual’s dated survey release as a sector-specific starting point and does not generalise its percentages to other industries or claim that communications alone can prevent cyber incidents.