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's a quiet assumption sitting at the heart of most corporate security programmes: build enough fences and 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's the argument published by CSO Online, and it matters to anyone who runs or 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 doesn't prove you can restore a working business. Modern applications 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. Restore the files without restoring all of that and you're left 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 shifts daily. Development teams push updates constantly. A company's booking system, payment processor and customer database might run through four or five outside providers. If one disappears for days rather than hours, many organisations discover they have a restoration assumption rather than a continuity plan.
Consider what happens if Stripe, Salesforce or Microsoft 365 went dark for an extended period. Many businesses would stop functioning almost immediately, with no documented alternative. Our story from 6 July, "When the Learning Platform Goes Dark, There Is No Backup Plan", showed exactly that dynamic playing out at a university mid-exams: no fallback, just waiting.
The deeper problem is speed. AI-assisted tools that scan software for weaknesses are compressing what used to be weeks of vulnerability research into minutes. Criminals and state-sponsored groups are finding gaps faster. Patch cycles haven't kept up.
None of this makes prevention pointless. Strong perimeter controls and good patching discipline create friction that slows attackers down and reduces exposure. Friction buys time. Time saves businesses. But friction isn't a guarantee, and the organisations that come through serious incidents are the ones that test recovery under realistic, chaotic conditions rather than optimistic ones.
Live telemetry (real-time monitoring of what's happening inside systems at any given moment) and regular unscripted recovery drills are the difference between knowing you should be able to recover and knowing you can. A 2026 survey of 1,200 practitioners we reported on 1 July found awareness is up and resilience is flat. That's the gap nobody wants to talk about at board level.
Should you worry?
Yes, if your continuity plan hasn't been stress-tested against the environment you're actually running today. Four steps worth acting on:
- Run an unscripted recovery drill against your current environment, not the one documented six months ago.
- List every external provider your operations depend on and ask honestly what you'd do if each one disappeared for an extended period.
- Test whether restored backups produce a working application, not just accessible files.
- Train staff to recognise phishing and social-engineering attempts, because expensive technical controls fail when a single employee clicks the wrong link.
The uncomfortable judgement here is that most resilience programmes are measuring rehearsal, not readiness. Unscripted drills will embarrass almost every organisation that runs one honestly. That embarrassment is cheaper than the alternative.
