The essentials
- Matt Riley, European head of information security at Sharp, notes that everyday events—a bad patch, cloud downtime, a supplier outage—test continuity more often than disaster scenarios.
- Two hours down on a delivery system on a Tuesday afternoon can cost more in lost orders than a highly publicised weekend incident, according to his ZDNet France column of 2 November 2026.
- Immediate reaction (contain, understand, IT incident plan) must be separated from business recovery (restoring systems and services in a defined order once the situation is stable).
- If only the CEO can authorise locking systems during an attack, the company can freeze; deputies, manual workarounds, and customer messaging should be set before a crisis.
Your logistics team cannot confirm shipments. The line-of-business app has shown an error since lunch. It is not a flood or a national cyber crisis: a software update failed, or a cloud service stopped responding. Trucks are waiting, customers are calling, and no one knows who may switch to a spreadsheet or defer deliveries.
Ordinary failures that still hurt
In a column published on 2 November 2026 on ZDNet France, Matt Riley, European head of information security at Sharp, highlights a common gap: business continuity plans describe catastrophes—mass attacks, fire, flood—while companies mostly face routine outages: a faulty fix, a supplier down, a key system offline with no clear reason. None of these need to be spectacular to cause real damage. When the system that runs deliveries fails, the impact is immediate. Two hours of downtime on a Tuesday afternoon can cost more—in lost orders and unhappy customers—than a highly visible incident on a weekend.
React first, recover next
Riley separates two notions often blurred together. Reaction is the immediate phase: contain the problem, understand it, usually through an incident management plan owned by IT. Business recovery comes after stabilisation: restore systems, data, and services in a set order to return to normal operations. Continuity planning should cover both—a roadmap back to normal once the first pressure eases, not only an emergency technical runbook.
Priorities and decision-makers: decided early
Building a plan starts by listing the processes, systems, and suppliers you depend on—not everything is equally critical. Riley mentions the end-to-end automated sales cycle and disruption of a strategic supplier: both deserve a prepared response, not improvisation. A business impact analysis (imagining the sudden stop of each key process) can feel formal, but the point is to run it before trouble hits. Another sensitive topic: if only the CEO can authorise locking systems during a cyberattack, the company can stay paralysed if they are unreachable. Manual processes, customer notice when deliveries slip, a named deputy—all of that is decided in calm times. Riley also stresses communication—customers, partners, stakeholders—planned in advance (what to say, when).
- Define recovery order: which service comes back first (billing, stock, mail) and who signs off each step.
- Test or review the plan regularly, even briefly: an untested BCP is not operational.
- Plan degraded mode: who knows the manual workaround or alternate supplier, and for how long it holds.
- Include dependencies: a cloud provider or SaaS vendor is part of continuity, not only on-prem servers.
If your plan only lists catastrophes and never a Tuesday outage, we can review it together and pick a short first exercise.
Sources
This note was drafted with AI tools from the cited sources, then reviewed and published under the responsibility of Jordan FOUASSIER, publication director. We summarise the facts and add our reading; source text and images are not reproduced. An error? Write to contact@aigyrosgroup.com.