The organisations that survive data breaches well aren’t necessarily the ones with the best security. They’re the ones that decided, months before anything went wrong, exactly what they would do when it did. That distinction matters more than most security budgets reflect.
Breach preparedness gets framed as risk mitigation. That framing undersells it. What preparation actually produces is speed — the ability to contain damage in the first hours before it compounds, to notify regulators within legal deadlines, to communicate with customers before speculation fills the gap.
Every hour of delay in a live incident carries a cost. Organisations that have rehearsed the response lose fewer of those hours.
The question isn’t whether a breach will happen. The IBM Cost of a Data Breach Report put the global average breach cost at $4.88 million — and that figure climbs sharply for organisations without a tested incident response plan. The question is what condition the organisation is in when it does.
The Data Inventory Problem Nobody Wants to Admit
Ask any security team whether they know what data the organisation holds. Most will say yes. Press on where customer records from three years ago are stored, which SaaS platforms the marketing team onboarded without IT approval, or what a departed contractor still has access to — and the answer gets complicated quickly.
Data doesn’t organise itself. It accumulates in email inboxes, shared drives, departmental cloud tools, legacy databases that predate the current IT team. Formal classification policies describe the intended state. The actual state is messier, and that gap is where breach exposure hides.
A genuine data inventory maps data by sensitivity — personally identifiable information, financial records, health data, intellectual property — and traces how each category moves through the organisation: where it enters, how it’s handled internally, where it exits, and who outside the organisation can reach it.
Third-party vendors with API access, managed service providers with admin credentials, SaaS platforms handling customer data — all of it belongs on the map.
This isn’t a one-time audit. Data environments shift constantly. The inventory is only useful if it reflects the current reality, not the reality from eighteen months ago when someone last checked.
An Incident Response Plan Is Only as Good as Its Last Test
Most organisations have documented incident response procedures. Fewer have run them under simulated pressure. The gap between those two groups becomes visible the moment an actual incident begins.
A plan that exists as a PDF in a shared folder creates the illusion of preparedness without the substance. What preparedness actually requires is that the people responsible for the response have internalised their roles well enough to act quickly under stress, with incomplete information, while other priorities are screaming for attention.
The plan itself needs to answer specific questions before they become urgent. Who leads the incident response — and who leads it if that person is unreachable? Who notifies legal counsel, and who contacts the cyber insurer?
Who owns external communications, and what’s the approval chain for anything that goes out? How does the team isolate compromised systems without destroying the forensic evidence needed to understand what happened? When does executive leadership get involved, and at what threshold?
Regulatory timelines sharpen the pressure. GDPR Article 33 requires notification to the relevant supervisory authority within 72 hours of a confirmed breach. That deadline runs from discovery, not from resolution. Organisations that spend the first 48 hours figuring out who’s in charge find themselves in regulatory trouble before the technical response is even complete.
Tabletop exercises — quarterly, with realistic scenarios — are what close the gap between documentation and genuine readiness. Simulate a ransomware attack.
Simulate a vendor breach that exposes customer data. Simulate an insider threat where the attacker has legitimate credentials. The friction those exercises surface is far cheaper to address in a conference room than during a live incident.
Access Control Drifts. That Drift Is What Attackers Exploit.
Permissions don’t accumulate dramatically. They accumulate quietly, one exception at a time. An employee moves to a new role and retains access to the previous one. A contractor is granted temporary admin access for a project and never has it revoked.
A department adopts a new tool and connects it to production data without a formal review. Over time, the access map of a typical organisation bears almost no relationship to what its current security policy says it should look like.
This matters because compromised credentials are the most common breach vector. When an attacker gains access to an account through phishing or credential stuffing, the damage they can do is determined by what that account can reach.
In an environment where access drift is unchecked, a mid-level employee’s compromised credentials can provide a path through systems that should never have been connected.
The principle of least privilege — every account holds exactly the access the current role requires, nothing more — is straightforward as a concept and genuinely difficult to maintain at scale. It requires access reviews on a regular cycle, not as a one-time cleanup.
It requires multi-factor authentication applied universally, not selectively for senior staff while the rest of the organisation operates on passwords alone. It requires privileged access management for any credentials that can modify production environments.
The 2020 SolarWinds attack is instructive here not because of its technical sophistication but because of how it spread. Trusted vendor access, granted legitimately and left without adequate ongoing controls, became the mechanism through which a single compromise reached thousands of downstream organisations.
The lesson isn’t that vendor relationships are inherently dangerous. It’s that trust without verification is an architecture flaw.
Encryption Doesn’t Prevent Breaches. It Changes What a Breach Costs.
There’s a category error that shows up regularly in how organisations think about encryption — treating it as a protective measure rather than a damage-limitation one. Encryption doesn’t stop attackers from gaining access. What it determines is whether the data they access is usable.
That distinction has direct regulatory and legal consequences. A breach involving encrypted data, where the decryption keys were not also compromised, is treated materially differently under GDPR and most other data protection frameworks than a breach involving readable data. The harm to affected individuals is different. The notification obligations may differ. The liability exposure is different.
Both data in transit and data at rest require attention, and organisations that address only one create an obvious gap. TLS 1.3 for all network communication — including internal traffic, which is frequently overlooked — handles the transit side. AES-256 encryption for stored data handles at-rest exposure.
Backups deserve specific attention: they’re frequently left unencrypted, and a ransomware attack that reaches backup systems finds readable data it can encrypt or exfiltrate.
Human Behaviour Is the Attack Surface That Doesn’t Get Patched
The Verizon Data Breach Investigations Report attributes 68% of breaches to human involvement. Phishing. Password reuse across personal and professional accounts.
Misconfigured cloud storage made public by an employee who didn’t understand the setting. Social engineering that bypasses technical controls entirely because it targets people rather than systems.
Annual compliance training doesn’t address this. It produces a record that training occurred. What changes behaviour is repetition, relevance, and feedback — simulated phishing campaigns run frequently enough that employees develop genuine recognition of the patterns, with immediate feedback when someone clicks.
Threat briefings tailored to the actual risks facing each department, because the social engineering targeting the finance team looks different from what’s aimed at engineers.
Frictionless reporting channels so that an employee who receives a suspicious email can flag it without navigating bureaucracy or worrying about being blamed for almost falling for it.
The cultural dimension is worth stating directly. In organisations where security mistakes are met with blame, near-misses go unreported. The employee who nearly clicked a phishing link and then quietly deleted the email without telling anyone is the norm, not the exception, in environments that haven’t deliberately built psychological safety around security reporting. That norm is expensive.
Third-Party Risk Belongs Inside the Security Perimeter
Supply chain attacks more than doubled between 2023 and 2025 and the implication is simple and frequently ignored: the organisation’s security posture is only as strong as the weakest vendor with meaningful access to its systems or data.
Vendor security assessments need to happen before onboarding — not as a formality, but as a genuine evaluation of the vendor’s security controls, breach history, and contractual obligations around disclosure.
SOC 2 Type II compliance or ISO 27001 certification provides a baseline. Contractual breach notification requirements matter: how quickly is the vendor obligated to disclose a breach that affects shared data, and what does “notification” actually mean in the contract’s language?
A vendor risk register — maintained, reviewed on a defined cycle, and updated when vendor relationships or access levels change — keeps this from becoming a one-time assessment that drifts out of relevance.
The vendor that was low-risk twelve months ago may have expanded its access since then, or may have itself experienced a breach that changes the calculus.
What Cyber Insurance Covers Is Not What Most People Assume
Cyber insurance sits at the end of most breach preparedness discussions as though it’s a safety net that catches whatever the rest of the programme misses. That’s a misreading of what policies actually provide — and the misreading tends to surface at the most inconvenient moment.
Coverage for breach response costs, legal fees, regulatory fines, and business interruption is real and valuable. What’s also real is the list of conditions under which claims get reduced or denied: absent multi-factor authentication, unpatched known vulnerabilities, inadequate access controls documented in a pre-breach audit.
Underwriters have become significantly more sophisticated about security requirements, and policies issued in 2026 carry assumptions about baseline controls that many organisations haven’t verified they actually meet.
Reading the policy before filing a claim is obvious advice that organisations consistently fail to follow. Understanding what the insurer requires as a condition of full coverage — and confirming that those requirements are met — is the kind of maintenance work that doesn’t feel urgent until it suddenly is.
Preparedness Is a Posture, Not a Project
The organisations that handle breaches well aren’t the ones that ran a security programme once and considered the work complete.
They’re the ones that built preparedness into ongoing operations — access reviews on a regular cycle, response plans tested and updated, training embedded in the rhythm of the year rather than scheduled as a one-time event.
The breach will come with no warning and at no convenient time. What the organisation does in the first hours will be determined almost entirely by decisions made long before that moment. The groundwork either exists or it doesn’t. There’s no preparing for a breach in the middle of one.
Also Read:
