The Cybersecurity Reality Check: Ten Myths That Matter

Author: Edward Machin

Comparatively few serious cyber incidents begin with a failure of sophisticated technology. Far more often, they start with a misplaced assumption: about who is likely to be targeted, where responsibility within the organisation sits, or what adequate protection actually requires. 

Those assumptions have become difficult to sustain as the threat landscape evolves at a rapid clip and regulatory scrutiny across the UK and EU has intensified. For boards, general counsel and legal and compliance teams, the consequences of getting this wrong can be significant. A cyber incident can give rise to regulatory investigations, contractual disputes, litigation, business interruption and reputational harm. And whether those consequences could have been avoided or contained will often turn on decisions that could – or should – have been taken long before the incident. 

This article tests ten of the most common of those assumptions against the legal and practical realities.

Threat actors often do not specifically select their victims, and many attacks rely on automated tooling to identify exposed systems, exploit known weaknesses or gain access using compromised credentials. Smaller organisations are often more vulnerable, given that they typically have fewer dedicated security resources, more limited monitoring capability and less resilience to prolonged disruption. AI can amplify this exposure: in one study, AI-generated spear-phishing emails achieved a 54% click-through rate, compared with 12% for generic phishing emails. Many smaller organisations also hold sensitive customer data or provide services to larger entities, which makes them an attractive point of entry into wider supply chains.

The adequacy of an organisation’s security is not measured by its size or profile, and rightly so. For example, Article 32 of the GDPR and of the UK GDPR requires controllers and processors to implement measures appropriate to the risk, having regard to the state of the art, the costs of implementation and the nature, scope, context and purposes of the processing. It might be argued that the reference to cost affords smaller organisations some latitude – and to a degree it does. Article 32 does not require every organisation to adopt an enterprise-grade security programme, but cost is only one factor to be weighed against the risk, not a defence in its own right. An organisation must therefore be able to articulate, and evidence, why the measures it has adopted are proportionate to the risks it faces.

IT and security teams run the controls, but they cannot decide how much risk the business is prepared to accept. Risk appetite, investment, supplier strategy, operational priorities and crisis management are matters for the business as a whole – and, ultimately, for its leadership.

Under the NIS2 Directive (NIS2), the management bodies of ‘essential’ and ‘important’ entities must approve and oversee the implementation of cybersecurity risk-management measures, while the Digital Operational Resilience Act (DORA) imposes its own governance and ICT risk-management framework on in-scope financial entities. Neither regime applies in the UK as a matter of domestic law, although UK organisations with EU operations may well fall within their scope. 

In the UK, the rules are spread across several regimes, but they point the same way. The Network and Information Systems Regulations 2018 continue to apply to operators of essential services and relevant digital service providers, and the proposed Cyber Security and Resilience Bill is intended to strengthen that framework. In financial services, the operational resilience rules of the Financial Conduct Authority (FCA) and the Prudential Regulation Authority (PRA) place responsibility for resilience with firms’ boards. More generally, directors’ duty under section 174 of the Companies Act 2006 to exercise reasonable care, skill and diligence applies to cyber risk as it does to any other material risk, and the UK Government’s Cyber Governance Code of Practice offers a voluntary framework for discharging that oversight at board level.

None of these regimes means that directors are automatically liable for every incident, and the applicable duties, the organisation’s circumstances and the nature of any infringement will all be relevant. The key distinction is between delegating the execution of security and delegating responsibility for overseeing it; the former is permissible and necessary, but the latter is not. Boards cannot therefore assume that appointing a chief information security officer, or outsourcing security to a specialist provider, discharges their own obligation of meaningful oversight. And although effective oversight does not require directors to be security specialists, it does require them to understand the organisation’s material exposures, the limits of its controls and the consequences of leaving known weaknesses unremediated, and to be capable of challenging the assurances they receive.

Serious intrusions rarely announce themselves. There may be no ransom note and no outage, and capable attackers will often establish persistence, escalate privileges, exfiltrate data and stage further activity well before detection. The then-UK Information Commissioner’s Office’s (ICO) recent enforcement action against South Staffordshire Plc and South Staffordshire Water Plc is a case in point. The ICO reported that malicious activity had gone undetected for almost two years and identified deficiencies including limited monitoring, outdated software and unpatched systems. AI is compressing the front end of that timeline. To compound matters, in controlled tests AI tools have turned a published software fix into a working attack in under an hour, with some steps taking only minutes. The result is that attackers are moving faster, while the intrusions they leave behind become harder to detect.

Detection capability determines an organisation’s ability to meet its breach notification and incident reporting obligations. An organisation that cannot identify suspicious activity promptly will struggle to establish the scope of a breach, determine which obligations are triggered and make defensible decisions within the time available. One might take the position that late detection at least postpones the point at which the organisation becomes aware of a breach, and with it the start of the Article 33 timetable under the GDPR and the UK GDPR. However, where the delay in detection itself reflects inadequate monitoring, as the ICO found in the South Staffordshire case, it is likely to be treated as evidence of a failure to implement appropriate security measures rather than as mitigation.

An unblemished incident record may reflect effective controls. But it may equally reflect a compromise that has gone undetected, a measure of good fortune or simply the fact that no attacker has yet tested the organisation’s weaknesses in earnest. Indeed, as many organisations adopt AI tools, the systems and data connected to those tools may offer attackers new ways in, so a clean record to date is no guarantee of safety tomorrow. 

Similarly, policies and certifications are useful evidence of an organisation’s intent, but they do not establish that its controls operate effectively in practice. An incident response plan that has never been tested offers limited assurance, just as a backup policy is of little value if systems cannot be restored from those backups and a vulnerability management process cannot be regarded as effective where critical vulnerabilities remain unremediated indefinitely.

Regulators will want to see what the organisation actually did, not just what its policies said. Following an incident, an organisation should expect to explain which risks it identified, which controls it adopted, how those controls were tested and what action it took when weaknesses came to light. The relevant standard is not one of perfection, since no organisation can guarantee that an incident will never occur. Rather, the question is whether the organisation assessed its risks properly and took reasonable and proportionate steps to manage them.

Most organisations depend on an extensive network of cloud providers, software vendors, managed service providers and other third parties to process their data. The result is that a compromise at one provider can affect many of its customers simultaneously, irrespective of how well those customers have secured their own environments. This risk is only growing: cybersecurity vendor Wiz reported a doubling of supply-chain attacks from H1 2025 to H1 2026.

Supplier contracts can allocate responsibility, impose security standards and provide remedies for breach. What they cannot do, however carefully drafted, is ensure that a supplier will prevent an attack, restore the service promptly or remain solvent and able to meet its obligations. And while robust indemnities and liability provisions may compensate for loss, subject to any cap, compensation is not continuity of service. Nor does contractual recourse against a supplier discharge the organisation’s own regulatory obligations, which remain with it regardless of how risk has been allocated between the parties.

Legislators and regulators have recognised that an organisation’s resilience is only as strong as its supply chain. NIS2 imposes supply chain security requirements on in-scope entities, while DORA requires in-scope financial entities to manage ICT third-party risk and establishes a direct oversight framework for designated critical ICT third-party service providers. In the UK, the proposed Cyber Security and Resilience Bill is intended to strengthen the regulatory framework for relevant digital services and supply chain risk. The detail differs between regimes, but each expects an organisation to know which external services it cannot operate without, and what happens if they fail.

Depending on its terms, a cyber insurance policy may meet the costs of incident response, forensic investigation and legal advice, as well as business interruption losses and certain third-party claims. Bought on the right terms, it is a valuable part of an organisation’s wider risk management. However, cover is not automatic. Policies typically contain limits, exclusions, conditions precedent and notification requirements, and whether a particular loss is covered will depend on the facts, the policy wording and the insured’s compliance with the policy terms. A disputed claim may also take time to resolve, and that delay is likely to arise at precisely the point when the organisation requires immediate funding.

Insurance also cannot restore lost trust, reverse the disclosure of sensitive information or protect an organisation from regulatory enforcement. Indeed, whether regulatory fines are insurable at all is doubtful as a matter of public policy, and many policies cover them only ‘where insurable by law’. Nor does the purchase of a policy demonstrate that an organisation has implemented appropriate security measures. A policy may be evidence of prudent financial planning, but it represents risk transfer rather than risk management, and it is the latter with which regulators are concerned.

Lastly, underwriters frequently ask detailed questions about authentication, backups, patching, incident response and other controls. The answers form part of the presentation of the risk, and inaccurate or outdated responses may prejudice a subsequent claim. Although a proposal form completed in good faith by the IT function might be seen as sufficient, the difficulty is that the duty of fair presentation extends to what senior management and those responsible for arranging the insurance know or ought reasonably to know, meaning that responses should be verified rather than assumed.

Where ransomware disables critical systems, payment may appear to offer the quickest means of restoring operations or of preventing the publication of exfiltrated data. That pressure is acute where contractual commitments, customer services or essential operations are affected. That said, payment does not guarantee the provision of a working decryption key, the deletion of stolen data or an end to further demands. AI may also help attackers sift through stolen data more quickly, increasing the risk of its further misuse even if a ransom is paid. Even where data is decrypted, compromised systems may remain unsafe and may require extensive investigation and rebuilding before they can be restored to service.

Paying a ransom can also be unlawful. In the UK, a payment may breach financial sanctions where the recipient is a designated person, and the Office of Financial Sanctions Implementation (OFSI) treats sanctions breaches as strict liability for the purposes of civil monetary penalties (payments that may fund terrorism raise separate criminal law concerns). The difficulty is that the identity of a threat actor may not be clear at the point of decision, so the absence of a known link to a designated person is not, of itself, an answer.

Nor does payment displace regulatory reporting obligations or insulate the organisation from scrutiny of its security measures. The ICO and the National Cyber Security Centre (NCSC) have made clear that paying a ransom does not reduce the risk to individuals and will not be treated as a mitigating factor in enforcement; by contrast, early engagement with the ICO and the NCSC may be. None of this is to suggest that payment will never be a rational commercial choice. The point is that any such decision must be taken within the applicable legal constraints, on proper advice and with a clear understanding of the benefits and risks of payment.

No degree of compliance can render an organisation immune from attack. The UK and EU frameworks overlap in places but diverge in scope, terminology, reporting requirements and enforcement. In the UK, the UK GDPR and the Data Protection Act 2018, the Network and Information Systems Regulations 2018, the Privacy and Electronic Communications Regulations 2003 and sector-specific rules such as those of the FCA and PRA may each impose distinct obligations, enforced by different regulators. For organisations operating in the EU, NIS2 and DORA add a further layer of complexity. Which obligations apply will depend on the organisation’s activities and regulatory status, and a single incident may engage several regimes.

It is also important to distinguish binding legal requirements from regulatory guidance and voluntary standards. A recognised framework, such as the UK Government-backed Cyber Essentials scheme or ISO/IEC 27001 certification, may be persuasive evidence of good practice without carrying statutory force. Certification may help demonstrate that an organisation has taken its obligations seriously, but it is a snapshot against a defined standard and does not necessarily establish that the measures in place were appropriate to the particular risks that materialised.

A compliance exercise limited to documenting policies or completing questionnaires may therefore fail to address the key question: whether the organisation can demonstrate that its approach to risk is effective. Documentation remains important, since it is often the primary means by which compliance is evidenced, but it is the substance it records, rather than its existence, that will ultimately be tested.

A serious incident requires rapid decisions, including whether to isolate systems, how to preserve evidence, when to notify regulators, what to communicate to customers and how to maintain essential services. Those decisions are typically taken under considerable pressure, on the basis of incomplete facts and amid competing priorities. AI continues to shrink this decision-making window. In 2022, the median time between an initial access event and the hand-off to a secondary threat group was more than eight hours, whereas in 2025, that window collapsed to just 22 seconds.

In the absence of preparation, organisations can face delay, inconsistent communications and uncertainty as to who has authority to act. They may also fail to meet statutory reporting deadlines or take steps which, however well intentioned, compromise the evidence on which subsequent investigation and recovery depend. But the purpose of preparation is not to predict the facts; it is to settle in advance the questions of authority, escalation and process, so that decisions taken under pressure are made by the right people, on a defensible basis.

Accordingly, an incident response plan is not merely a technical document. Rather, it should address governance, legal advice, communications, business continuity and the role of external advisers, and anticipate that the organisation’s usual systems and communication channels may be unavailable at the point they are most needed. The plan should also address legal professional privilege. If the organisation wishes to preserve privilege where it can, the engagement of forensic and other advisers should be structured accordingly from the outset, recognising that privilege may not extend to every document and that regulators may still require disclosure of underlying facts.

Ultimately, a plan that has never been exercised provides limited assurance, and a properly structured tabletop exercise, in which the people who would respond to a real incident work through a realistic scenario in real time, can expose weaknesses in escalation, decision-making and coordination before they have operational or legal consequences. The most useful exercises involve the board, senior management and technical teams, test the decisions that are hardest to make (whether to take systems offline, whether and when to notify regulators, and how to respond to a ransom demand), and assume that key individuals or systems are unavailable. 

But exercises are only as valuable as what follows them, and the findings should be recorded, the weaknesses identified should be assigned to an owner and remediated, and the plan should be updated accordingly. A documented record of regular exercises and the improvements made as a result is also one of the clearest ways for an organisation to show a regulator that its preparedness was real rather than theoretical.

The technical breach can often be the least of an organisation’s problems. An incident may require a personal data breach assessment and may give rise to regulatory investigations, contractual notification duties, litigation, insurance claims and scrutiny of directors’ oversight. An incident may also disrupt operations, erode customer confidence and expose weaknesses in supplier arrangements and business continuity planning, with the result that its total financial impact can substantially exceed the immediate cost of technical remediation.

Legal and compliance teams are well placed to manage these consequences. They can identify the legal obligations engaged, clarify reporting responsibilities, assess contractual protections and ensure that decision-makers understand the legal implications of each available option. They can also help the board demonstrate that it has discharged its duties under sections 172 and 174 of the Companies Act 2006 by ensuring that cyber risk decisions are properly informed, recorded and capable of being explained after the event.

That role is most effective when the legal function is engaged well before an incident. It is sometimes said that legal involvement slows the response at the point when speed matters most. The better view is that it is the absence of prior engagement that causes delay, because legal questions then arise for the first time mid-incident. Early involvement allows escalation protocols to be settled, the relationship between internal and external advisers to be defined, and incident plans to reflect the relevant legal and regulatory requirements. For these reasons, cyber risk properly belongs alongside the organisation’s other material enterprise risks, rather than being confined to a technical risk register.

Each of the misconceptions in this article can lead an organisation to treat a risk as smaller, more manageable or less relevant than it is. Resilience means knowing where the organisation is exposed, putting proportionate controls in place, being clear about who is accountable and being able to show that those arrangements work. For boards, general counsel and legal and compliance teams, the following three questions are a good starting point:

No organisation can eliminate cyber risk, but every organisation can reduce avoidable exposure, strengthen its ability to recover and put itself in a defensible position when its decisions are later examined by regulators, customers, insurers or the courts. Ultimately, the test is not whether an incident occurred. It is whether the organisation understood its risks, acted proportionately and was prepared to respond. Organisations that cannot answer that question with confidence should address it now.

Subscribe to Ropes & Gray Viewpoints by topic here.