Your dashboards are not your defence: why 'visibility' is not the same as surviving an attack
Security teams can monitor everything and still lose everything. A quietly influential argument making the rounds says the industry has confused watching a system with being able to keep it running, and the gap is getting harder to ignore.
Key points
- Most organisations test their recovery plans in controlled conditions that no longer reflect how their systems actually work.
- Backups prove a company stored data at a point in time; they do not prove the business can keep operating after an attack.
- Cloud concentration means that if a single provider such as AWS or Microsoft 365 goes down for days, many companies have no real plan beyond waiting.
- Nation-state hacking groups and AI-assisted tools are finding software weaknesses faster than most security teams can patch them.
- Continuous, live testing of recovery processes is emerging as the only honest measure of resilience.
There is a quiet assumption sitting at the heart of most corporate security programmes: that if you build enough fences, the bad things stay out. Dashboards. Compliance reports. Annual tabletop exercises, where staff walk through a pretend crisis in a meeting room. Recovery-time targets written into policy documents. All of it adds up to a picture of preparedness. The picture is often wrong.
That is the argument published by CSO Online, and it is worth unpacking for anyone who runs, works at, or simply depends on a business that stores personal data.
Why does having backups not mean you are safe?
A backup is a copy of data saved at a specific moment. It does not prove you can restore a working business. Modern applications are not just files sitting in a folder. They depend on dozens of connected third-party services, temporary computing environments that exist for minutes and then disappear, permission settings that must be exactly right, and live data flows between systems. Restoring the files without restoring all of that leaves you with a shell.
Most recovery models were built in the late 1990s and early 2000s, for simpler, slower-moving systems. The underlying philosophy has barely changed. The systems have changed completely.
Cloud infrastructure now shifts daily. Development teams push updates constantly. A company's booking system, payment processor, customer database, and staff communications might all run through four or five outside providers. If one of those providers goes down for several days, not hours, many organisations discover they have a restoration assumption rather than a continuity plan.
Consider what happens if Stripe (payments), Salesforce (customer records), or Microsoft 365 (email and collaboration) disappeared for 72 hours. Many businesses would stop functioning almost immediately, with no documented alternative.
The deeper problem is speed. AI-assisted tools that scan software for weaknesses, looking for flaws the developer did not know existed, are compressing what used to be weeks of research into minutes. Criminals and state-sponsored groups are finding gaps faster. Governance processes and patch cycles have not kept up.
None of this means prevention is pointless. Strong perimeter controls, good patching discipline, and staff training on phishing (where criminals send fake emails to trick employees into handing over passwords or clicking malicious links) all create friction that slows attackers down and reduces exposure. Friction buys time. Time saves businesses.
But friction is not a guarantee. The organisations that come through serious incidents are increasingly the ones that test recovery under realistic, chaotic conditions, not optimistic ones. Live telemetry (real-time monitoring of what is happening inside systems at any given moment), continuous dependency mapping, and regular unscripted recovery drills are the difference between knowing you should be able to recover and knowing you can.
What should organisations do?
Four practical steps worth acting on now:
- Run an unscripted recovery drill against your current environment, not the one you documented six months ago.
- List every external provider your operations depend on and ask honestly what you would do if each one disappeared for 72 hours.
- Test whether restored backups actually produce a working application, not just accessible files.
- Train staff to recognise phishing and social-engineering attempts, because the most expensive technical controls fail when a single employee clicks the wrong link.
