The Purpose of a System Is What It Does

Photo by Taylor R on Unsplash

By Ryan King, Director - Cyber Consulting, with the assistance of Claude Sonnet 5.0. All opinions, errors, omissions and assumptions are the author’s own.

Executive Summary

Most organisations believe their security programme exists to protect them from cyber-attacks. Stafford Beer’s POSIWID principle, the purpose of a system is what it does, challenges that belief. Judged by outcomes rather than intentions, a compliance-driven security programme is a system optimised to produce certificates. A threat-led security programme is a system optimised to manage real-world cyber risk. The evidence presented in this paper shows that the gap between these two approaches is large, measurable, and consequential.

Thesis

Four high-profile case studies illustrate a consistent pattern: each organisation held a recognised cybersecurity certification at the time of its breach; in three cases, independent auditors had recently issued clean reports. The combined cost runs to hundreds of millions in fines, settlements, and remediation, sustained equity underperformance lasting years, and multiple executive departures. In every case, the compliance system did exactly what it was designed to do, it produced a certificate. What it did not produce was resilience. Verizon’s DBIR data confirms this is not a curated sample: the majority of confirmed breaches year-on-year exploit attack vectors that every major compliance framework already addresses, pointing to a systemic failure of application, not framework design.

Antithesis

The case against compliance frameworks can be overstated. They encode decades of accumulated practice, establish a genuine baseline below which organisations are materially more exposed, and remain a commercial and regulatory condition of operating in most sectors. For smaller organisations without mature security operations functions, they are the only viable starting point. The argument is not that compliance is valueless; it is that treating certification as the goal, rather than as a necessary but insufficient foundation, is where the failure occurs. Threat-led programmes carry their own limitations: without independent external verification they risk replacing compliance theatre with self-assessment theatre, and no programme is immune to novel adversary techniques or genuine unknown-unknowns.

Synthesis

A business is a profit-seeking system; its security programme should be aligned to protecting the mechanisms that produce that profit. Compliance frameworks are generic by design and cannot be calibrated to the specific adversaries targeting a particular organisation’s highest-value assets. Threat-led programmes ask a different question: given what is known about the actors who target organisations like ours, what is needed to deter, prevent, detect, respond to, and recover from an attack? Mandiant M-Trends data shows average attacker dwell time falling from 78 days in 2018 to 10—11 days by 2023—2024, directly correlated with investment in detection capability. The regulatory direction of travel (CBEST, TIBER-EU, and DORA) already mandates threat-led approaches for systemically important financial institutions precisely because compliance audits were failing to surface real-world vulnerabilities. Organisations that shift from treating compliance as a ceiling to treating it as a floor will be structurally advantaged as this regulatory convergence accelerates.

Four questions every board should be asking

The following four questions, each mapped to measurable KRIs, are more diagnostic than asking whether a certificate is current:

“What specific threat actors are most likely to target our organisation, and do we have current intelligence about how they operate?” — KRIs: Threat Intelligence Confidence; Threat Intelligence Freshness.

“When did we last conduct adversarial testing against our production systems, and what did we find?” — KRIs: Threat-Led Testing Freshness; Time-to-Apply Lessons-Learned.

“If we were compromised today, how quickly would we know?” — KRI: Attacker Dwell Time.

“What does our security programme explicitly not cover, and is that where our adversaries operate?” — KRI: Security Programme Coverage.

Part I – Thesis

POSIWID – Compliance-Driven Security Systems Don’t Produce Security, They Produce Certificates

In 1979, British management guru Stafford Beer wrote in the Heart of Enterprise, that:

“A system is defined not by what it claims to do, but by what it actually produces.”

Stafford Beer, Heart of Enterprise, 1979

Beer’s axiom, modified as “the purpose of a system is what it does” and shortened to POSIWID invites us to ignore the stated goals, intentions of a system’s designers and operators, and instead judge its effectiveness on the outcomes it produces.

Applied to cybersecurity, this question can produce some uncomfortable and unexpected answers. Most organisations will tell you that the purpose of their cybersecurity programme, their ISO 27001 certified Information Security Management System, their PCI DSS certified Card Data Environment, is to prevent cyber incidents, to preserve operational continuity and to demonstrate that cyber risk is managed. These are the stated goals. POSIWID asks: “what do these systems actually produce?”

The evidence I will present in this piece suggests that in a significant number of these organisations, the answer is not “security” or “resilience”. It is, in fact: “certificates”. The system produces certifications, attestations, clean audit reports: the documentation of compliance. Then, the system stops, resets, and starts producing the next certificate. It does this reliably, year-after-year, in organisations that got breached, in some cases while the ink on the certificate was wet.

My thesis is straightforward: compliance-driven security programmes are systems optimised to produce certificates. Threat-led security programmes are systems optimised to manage the risk of real-world cyber-attacks. The evidence I will present suggests that the second approach produces measurably better outcomes on the metrics that matter to investors, shareholders, and board members.

The Evidence: Certified and Breached

I have selected four case studies of high profile breaches that illustrate how compliance-driven security programmes that produce certificates can fail to produce security. I will also supplement this with more robust data collected across sectors and geographies to prove that this is a systemic issue.

Between 2017 and 2020, these four organisations suffered major, very public, cyber incidents that between them cost hundreds of millions of pounds in fines, settlements and remediation, as well as triggering regulatory investigations, multiple executive departures and caused sustained equity underperformance that lasted years after the incidents themselves. Each organisation held at least one recognised cybersecurity certification when they were breached. In three cases, independent external auditors had issued clean audits during the period when the attacks occurred.

These are not obscure organisations: they are among the most scrutinised, most regulated and most compliance-conscious entities in their respective sectors. They also illustrate what can happen when the purpose of a security system is to produce a certificate, rather than to manage cyber threats.

Equifax (2017) – Playing games with the scope

Compliance status at the time of the breach: ISO 27001 certified since 2011; PCI DSS certified (with scope gaps, a database holding card data was outside certification boundary).

What happened: 147 million Americans’ personal data compromised including Social Security numbers and ~200,000 credit card numbers. Attackers inside the network for 76 days undetected.

Attack vector: Known, unpatched vulnerability (CVE-2017-5638, Apache Struts). Patch available 76 days before breach. CVSS score: 10.0

Consequences: Up to $700M settlement (FTC/CFPB/50 states); CEO resigned; stock fell 35%; ISO 27001 certificates suspended post-breach

Analysis: In the Equifax example, they had held an ISO 27001 certification since 2011 and were PCI DSS (Payment Card Industry Data Security Standard) certified as a credit reporter. Despite holding these two certificates, attackers penetrated their network and remained undetected for 76 days by exploiting a known vulnerability on the day that it was publicly disclosed. They were able to gain unauthorised access to a database of credit card data that was held in a database outside the scope of the PCI and ISO 27001 certifications.

The compliance-to-resilience gap was traced to the fact that the ISO 27001 certificate did not cover all systems where sensitive data was held, and that 2 specific PCI DSS requirements were violated, 6.2 (patching) and 10.6 (daily log monitoring), despite the independent PCI DSS Qualified Security Assessor (QSA) certifying that Equifax met the requirements of the standard.

Conclusion: The security system traded coverage for the certificate, and that is exactly the gap where the crowbar went in.

SolarWinds SUNBURST (2019-2020) – Framework blindness

Compliance status at the time of the breach: ISO 27001 certified; SOC 2 Type II audit completed in 2019, after infiltration had begun, returned clean results.

What happened: Russian state actors (SVR) inserted a backdoor into signed Orion software updates. c.18,000 organisations infected including US Treasury, Commerce Department, and National Nuclear Security Administration. Undetected for c.14 months.

Attack vector: Software build pipeline supply chain compromise.

Consequences: Stock fell c.35% within a month of disclosure; $26M securities class action settlement; SEC charged SolarWinds and its CISO with securities fraud (dismissed 2025); four downstream victim companies fined separately by the SEC.

Analysis: The fallout of the 2019 SolarWinds SUNBURST breach led to a high-stakes legal battle between the US Securities and Exchange Commission (SEC) and SolarWinds Corporation, as well as the CISO of SolarWinds in his personal capacity. The case was ultimately dismissed, but it sent a clear signal: security posture weaknesses that are masked by valid certificates will be scrutinised through the lens of intentional misrepresentation to investors.

Conclusion: The security system became myopically focused on achieving a certificate and ignored an entire threat surface, which is where the attackers got in.

Marriott / Starwood multiple data breaches (from 2014 to 2020) – False assurances

Compliance status at the time of the breach: PCI DSS compliant.

What happened: 339 million guest records exposed globally including 5.25 million unencrypted passport numbers. Attackers present for four years undetected, including across Marriott’s 2016 acquisition of Starwood. FTC found failure to implement appropriate password controls, access controls, firewall controls, or network segmentation; patch outdated software and systems; adequately log and monitor network environments; and deploy adequate multifactor authentication.

Attack vector: Remote Access Trojan and Mimikatz credential harvesting; M&A cyber due diligence gap.

Consequences: ICO fine £18.4M (reduced from £99M); US 50-state AG settlement $52M; FTC-mandated security programme with annual certification for 20 years.

Analysis: The ICO’s penalty notice confirms that Marriott received two formal Reports on Compliance (ROCs) issued by independent PCI DSS assessors, one on 29 April 2016 (prior to the acquisition of Starwood) and one on 23 May 2017 (post-acquisition), both stating that MFA was in place across the Cardholder Data Environment. Marriott placed particular reliance on the 2017 report. Arguably, the security system that Marriott operated met its objective, which was to achieve a certificate. What it failed to do was prevent, detect, contain and eradicate a four-year intrusion that siphoned 339 million guest records.

Conclusion: The security system produced multiple clean audits and stopped further resilience improvement efforts there. The systemic failure of even the most basic security controls shows how wide the gap between the certificate and the reality can stretch.

NHS WannaCry (May 2017) – Unverified assertions

Compliance status: NHS IG Toolkit self-assessment was the mandated framework. Not a single NHS trust had passed Cyber Essentials Plus before the attack. No mechanism existed to verify patch compliance.

What happened: Ransomware locked 81 of 236 NHS trusts and 603 GP and primary care organisations. 19,494 appointments cancelled including 139 urgent cancer referrals. Five A&E departments unable to treat patients.

Attack vector: Known, patched Windows SMB vulnerability (EternalBlue). Microsoft patch available 59 days before attack. NHS Digital had issued two critical alerts warning organisations to patch.

Consequences: £92M total cost (£20M lost output; £72M IT recovery). No fines --- public sector. Post-attack: all 200 trusts subsequently tested failed cybersecurity checks. Attributed to North Korea.

Analysis: The fatal flaw of the NHS IG Toolkit was that it was an “honour system” with no enforcement teeth. The bar for compliance was so low that the value of the certificate was diminished. Trusts that self-reported compliance, as well as those that did not were equally exposed to the ransomware, unless they had implemented a security system that produced actual resilience.

Conclusion: The security system produced what it was built to produce: a self-assessment. When nobody checked whether the reports reflected reality, the framework hid the reality of how exposed the entire system of systems really was.

Mission Drift: The PCI DSS Lesson

The PCI DSS was not invented as an exercise in compliance. It was a direct, threat-led response by the payment card industry to a specific, quantified threat of over $750 million in fraud losses between 1988 and 1999. Card fraud existed before e-commerce but e-commerce dramatically accelerated both the scale and the attack surface, which is what forced industry action. Since its inception in 1999 with Visa as the Cardholder Information Security Programme, the consolidation across the four major card brands into PCI DSS in 2004, and through every revision, the trigger has been the need to deal with emerging attack patterns.

The problem is not the design or the intent of the standard. It is how the mission drifted under the influence of compliance culture. The Equifax and Marriott case studies highlight that security systems that are built to answer “yes” to the question, “are we compliant?” will do worse than organisations that ask, “are we resilient to how attackers actually operate today?”

Why This Matters to Investors, Shareholders and Board Members

The point I am making with these case studies is not primarily about security. I am making a governance and a financial argument.

Recent data is clear on this:

• An April 2026 ISS STOXX study that analysed Russell 3000 data found that companies that experienced a significant cyber incident underperform the broader market by approximately 5% on average over a three-year period following the event.

• Aon’s 2025 Global Cyber Risk Report analyses more than 1400 global cyber events and found that reputation risk events reduce shareholder value by an average of 27% at peak impact.

• Research published in Information Systems Research in September 2025 found that the negative stock market effects of a breach were lower in companies that emphasised preventive cyber risk management (i.e. preparing for a cyber breach) as compared to companies that focused on mitigative cyber risk management (i.e. reacting post cyber breach).

The market is pricing in cybersecurity resilience, not just with short-term stock price shocks, but with sustained drag that reflects a reassessment of management quality, governance credibility and operational resilience. The mechanism is not the direct cost of the breach, which can be substantial, but also the signal that the response to the breach sends. While it may be that the market is becoming more forgiving of organisations that experience a cyber-attack as it understands that cyber breaches are becoming more prevalent, it is less forgiving of those companies that fail to adequately prepare for the event.

Lastly, there is a shift in tone from authorities and regulators, which is accelerating the exposure of Directors and Officers in their personal capacity. In the SolarWinds case, the SEC did not just file charges against SolarWinds, but against the Chief Information Security Officer personally, alleging that he knew the security programme did not match the assurances being given to investors.

Part II – Antithesis

The Case for Compliance

My thesis is not an argument for abandoning compliance frameworks altogether. It would be practically risky for any organisation to read it that way.

Firstly, compliance frameworks emerge across many disciplines to address the wide variety of outcomes when organisations are asked to determine their own requirements from first principles. In the cybersecurity context, the alternative to compliance frameworks would leave less mature or well-resourced organisations without the structures to achieve a baseline. Frameworks such as ISO 27001, PCI DSS, Cyber Essentials, NIST CSF encode decades of accumulated knowledge about baseline security practices. They establish a foundation: a real baseline below which organisations are genuinely more exposed than those that have it.

The PCI DSS origin makes this point precisely. The standard was conceived as a threat-led response that prevents enormous quantities of card fraud, even when it is treated as a compliance-driven exercise. The counterfactual of the levels of payment card fraud we would be experiencing without PCI DSS is frankly scary. The compliance foundation is a meaningful achievement for any organisation that meets it.

Secondly, threat-led security programmes require a level of maturity of some core functions that a compliance framework does not assume are in place. Threat-led approaches need mature security operations capabilities, access to threat intelligence, the capacity to conduct, or engage third-parties to conduct, red-teaming and the analytical skill to translate all the intelligence into meaningful control decisions. This is beyond many organisations, but especially small and medium enterprises. For these organisations, compliance frameworks are the structure within which they can build the capability to eventually exceed this foundation.

Finally, the regulatory and commercial reality cannot be ignored. Cyber insurance underwriters, customer third-party risk management programmes and industry regulators continue to rely on compliance certifications as the primary indicators of security posture. In many cases, compliance is a condition to operate or to be considered by a potential customer. An organisation that abandoned compliance in favour of a purely threat-led approach would face rising insurance costs, a loss of competitiveness and a weakened position with its regulators, regardless of its real security capability. In practice, compliance-driven and threat-led approaches are not exclusive alternatives, they are sequential and complementary.

The Honest Limitations of Threat-Led Approaches

Thomas Sowell, writing in A Conflict of Visions (1987), observed that, “there are no solutions, only trade-offs.” The threat-led approach offers a better trade-off than the compliance-driven approach, for organisations that have the maturity. It is not a guarantee.

There are two problems present in the threat-led approach: the moral hazard present in self-assessment and the problem of unknown-unknowns. “Threat-led” does not mean “self-assessed.” Organisations that conduct their own threat analysis, define their own controls and verify their own posture risk replacing one form of compliance theatre with another while losing the external verification. As imperfect as it can be, the independent verification that compliance frameworks provide is a feature, not a bug. The threat-led equivalent is to bake the independence into the approach, as mandated in regulations in force in the banking and financial services sectors. CBEST, TIBER-EU and DORA mandate threat-led approaches such as red team testing, threat simulation and adversarial assessments. However, without external verification, these just become a self-issued certificate.

The argument of unknown-unknowns applies equally to compliance frameworks and to threat-led security programmes. You can only build threat intelligence about adversaries that you know about. Nation-state actors, technological shifts, the creation of genuinely novel tactics, techniques, and procedures or the exploitation of zero-day vulnerabilities can defeat threat-led programmes as easily as compliance-driven systems. No programme is immune to the adversary it has not yet encountered.

The temporal advantage of the threat-led approach, its relative speed, adaptability and flexibility compared to compliance framework approaches is a real but not unlimited advantage. Threat intelligence has latency and attribution of attacks is uncertain. Taking a sector lens that positions an organisation well against a known adversary may miss a threat that operates outside of established patterns.

You Cannot Prove a Negative

The strongest challenge to my thesis is that the four case studies presented in Part I are “cherry-picked” precisely because they demonstrate the point I am making. The real counterfactual to this is that there are organisations that hold ISO 27001 certifications, SOC 2 Type II reports, and Cyber Essentials, among many other security compliance frameworks that have not been breached. There are PCI DSS compliant companies whose payment card environments have remained secure. The critic is correct to note this. My thesis does not depend on pretending otherwise.

The response to the cherry-picking critique has three parts. First, the problem cuts both ways in that organisations that were compliant and were not breached cannot be cited as evidence that compliance prevented the breach because the counterfactual does not exist: they may not have been breached because they were not targeted, due to an attacker error, or because controls they had in place independent of the compliance framework prevented the breach. Absence of a breach is not evidence that a compliance-driven system prevented the breach.

Secondly, my thesis does not need compliance to fail in every case, only to demonstrate that compliance treated as the goal and not the foundation produces materially worse outcomes than a threat-led approach. The four case studies demonstrate this. A counterfactual or counter example that demonstrates a compliance-driven approach preventing a breach that a threat-led system would not have blocked only proves that compliance frameworks address real risk: which my argument already concedes. It does not prove that compliance-driven programmes optimise for a profit-seeking entity facing real adversaries.

Thirdly, the case studies are used to bring the issues with a compliance-driven approach to life, but I am also able to point to systemic evidence that is not cherry-picked, sourced from Verizon Data Breach Investigations Reports (DBIR). The DBIR draws on data from thousands of confirmed breaches annually. For consecutive years, the DBIR has found that the majority of incidents exploited attack vectors that every major compliance framework addresses: known vulnerabilities left unpatched, stolen and weak credentials, phishing and malware. Despite the maturity of the frameworks to address these vectors, they continue to succeed at scale, across sectors and geographies. This points to the failure of application of frameworks, not that the frameworks focus on the wrong things: organisations satisfy audit requirements without actually implementing the controls effectively. The system produces a certificate. The certificate is not equivalent to effective risk management.

Part III – Synthesis

Businesses Are Systems for Producing Profit

A business is a system, and Beer’s axiom applies equally to a business as to its security programme. A business must be a profit-seeking system or it ceases to exist. It must do this to generate a return for its shareholders. Far from being a cynical observation, it is the precondition for everything else that the organisation achieves.

Applying this “profit-seeking” lens to investment in security programmes, POSIWID does not ask “are we compliant?” but “does this security programme protect the mechanisms that produce profit?” In this framing, the compliance-driven security programme is structurally misaligned with the purpose of the business in a way that has nothing to do with the quality of the frameworks.

Compliance frameworks have to be generic in order to be applicable and enforceable. They are inherently not designed around the specific operations of a particular business. They address categories of risk that affect all the organisations of a certain type, perhaps within a specific sector. A compliance-driven security programme protects what the framework requires, to the degree that achieves a “pass.” A threat-led programme protects what the adversary targets, which for a profit-seeking business is precisely the mechanisms that produce the most value.

A security programme that produces certificates is less well-aligned to the purpose of a profit-seeking business than a threat-led security programme.

What Threat-Led Looks Like in Practice

The difference between compliance-driven and threat-led security is a question of what the security programme is designed to produce. The compliance-driven approach asks, “what will satisfy an auditor?” The threat-led security programme asks, “given what we know about who targets organisations like ours, and how they operate, what would we need to deter, prevent, detect, respond, and recover?”

There is an implicit shift in emphasis from periodic, pass/fail thinking to continuous vigilance that considers how to operationalise cyber resilience. This is why sophisticated regulators like the Bank of England (BOE) and European Central Bank (ECB) are encoding it into best practices and law. The CBEST (BOE, 2013), TIBER-EU (ECB, 2018) and the EU’s DORA (January 2025) were launched because compliance audits were failing to reveal real-world vulnerabilities in systemically important financial institutions. TIBER-EU defines threat-led testing as tests that “mimic the tactics, techniques and procedures of real-life attackers based on bespoke threat intelligence.” The ECB is explicit in saying that, “the outcome is not a pass or fail.” DORA makes Threat-Led Penetration Testing legally mandatory for financial entities that meet the regulatory threshold across the EU. The institutional judgement is that compliance testing does not reliably produce resilience.

Figure 1: Threat-led vs compliance-driven, the relationship between threat and control specificity

Figure 1 above illustrates the relationship between the two approaches and frames the difference in outcomes as the residual risk that remains unmanaged. Both start at the same point: an organisation without a security programme has zero threat specificity and zero control specificity. The compliance-driven path moves up and rightward, building to a relatively generic level of threat-control specificity until it reaches the “compliance foundation” and plateaus: this is the structured approach to reaching a baseline level of security that many organisations still do not follow (as evidenced by the DBIR and IBM cost of a data breach reports).

The threat-led approach rises more quickly as it establishes verified reality about the actual threat landscape — every control implemented does more to manage the risk than a purely compliance-driven approach. The “compliance foundation” is crossed as a waypoint on the way towards a threat-led optimum. Note that there is a “threat-led ceiling” of risk that cannot be “managed away”. This represents trade-offs that must be made, risk appetites and the uncertainty of unknown unknowns.

The region below each curve represents the managed risk (exposure that the security programme understands and adequately addresses), with unmanaged risk above the curve.

The area between the curves is the difference in effectiveness of each approach to manage cyber risk: this is the better outcome that a threat-led approach buys.

In practice, the threat-led path incorporates three capabilities that compliance frameworks have not incorporated yet:

• Continuous threat intelligence that is specific to the organisation

• Incident response plans that are regularly rehearsed, not merely documented

• Independent red team testing using realistic adversary scenarios

Dwell time is the period between an attacker making a breach and the victim detecting them. Mandiant’s M-Trends records show that the average attacker dwell time has fallen from 78 days in 2018 to 10-11 days in 2023-2024. This correlates strongly with investment in threat detection capability. Contrast this with the four-year dwell time in the Marriott breach.

What Shareholders, Investors and Boards Should Ask

The synthesis of this piece provides four questions that are more useful than asking, “do we have the security certificate?”. Each question corresponds to a Key Risk Indicator (KRI) that can be linked to the business strategy.

1. “What specific threat actors are most likely to target our organisation, and do we have current intelligence about how they operate?” A board that cannot answer this question does not have a threat-led programme. KRIs: Threat Intelligence Confidence and Freshness.

2. “When did we last conduct adversarial testing against our production systems, and what did we find?” This moves independent testing on from compliance checklists to simulations that stress-test the security programme’s ability to respond to real-world threats. It is not a pass/fail exam, but an opportunity to learn lessons before a real attack exposes them. KRI: Threat-Led Testing Freshness, Time-to-Apply Lessons-Learned.

3. “If we were compromised today, how quickly would we know?” Organisations with a strong detection capability identify compromise in days (and this is trending downwards with new tools and approaches built on frontier AI). Most compliance frameworks won’t address this issue because detection speed is not a metric they measure. KRI: Attacker Dwell Time.

4. “What does our security programme explicitly not cover, and is that where our adversaries operate?” Attackers look for weaknesses. The case studies and the systemic DBIR data demonstrate the reality that threats find the gaps in security programme coverage. KRI: Security Programme Coverage.

Conclusion: Back to POSIWID

Beer’s axiom has lost none of its force in the decades since he coined it. The purpose of a system is what it does, not what it claims, not what it intends.

The case studies explored in this piece all operated security systems that were demonstrably designed to produce compliance, and succeeded in that objective. In each case, a breach revealed that systems that produce certificates did not necessarily produce what the organisation needed: resilience against real attackers.

The compliance framework is not at fault. It provides a valuable function as a foundation. The failure of these compliance-driven systems was to treat the foundation as a ceiling. They treated the certification as the goal and stopped at the point that an auditor was satisfied instead of rising to the challenge of the threats they faced.

PCI DSS began as a threat-led programme and became, through mission drift, a compliance exercise. The Equifax scope was drawn to meet a certification, and left a real risk exposed. The Marriott QSA audits were clean while the network was compromised. The NHS IG Toolkit produced self-assessments while the estate remained unpatched. In each case, the system produced what it was designed to produce.

“There are no solutions, there are only trade-offs; and you try to get the best trade-off you can get, that’s all you can hope for.”

Thomas Sowell, A Conflict of Visions, 1987

Sowell’s observation responds to Beer’s provocation: no security programme eliminates risk. The question is not whether to accept residual exposure, but whether the residual exposure is the result of a deliberate, informed trade-off made against a clear understanding of the actual threat landscape, or whether it is the result of a compliance programme that produced a certificate and stopped.

The evidence presented in the paper suggests that the gap between these two positions is large, measurable and consequential. It is measured in equity underperformance sustained over three years post breach and in profit destroyed by operational disruption.

The regulatory direction of travel is accelerating the convergence, visible in regulations promulgated across the EU and the UK and in decisions by enforcement agencies in the US.

What this means is that organisations that have made the shift from compliance-driven security programmes to threat-led programmes that see compliance as a foundation, necessary but not sufficient, will be structurally advantaged. Organisations that still treat the floor as the ceiling will find themselves increasingly exposed, targeted and having difficulty defending themselves to regulators when things go wrong.

For shareholders, investors and board members, the question to ask is not, “are we compliant?”

The question is, “given what we know about who targets organisations like ours, and how they operate, what would we need to deter, prevent, detect, respond, and recover?”

A Cyber Security Maturity Assessment answers that question directly: it benchmarks an organisation’s actual threat-led capability against its real threat landscape, rather than its certification status against a generic standard.

Sources

• Stafford Beer, The Heart of Enterprise, William Morrow, 1979
• Thomas Sowell, A Conflict of Visions: Ideological Origins of Political Struggles, William Morrow, 1987
• Equifax breach investigation — PIPEDA 2019-001, Office of the Privacy Commissioner of Canada
• Equifax $700M settlement — FTC, CFPB and 50 states press release
• Apache Struts remote code execution vulnerability — CVE-2017-5638, NVD
• SolarWinds securities fraud charges, October 2023 — SEC press release
• SolarWinds case dismissal, 2025 — SEC litigation release
• Marriott International penalty notice, November 2020 — ICO decision summary, gdprhub
• Marriott and Starwood settlements, October 2024 — FTC press release
• WannaCry cyber attack and the NHS, October 2017 — National Audit Office investigation
• Cost of a Data Breach Report 2025 — IBM / Ponemon Institute
• M-Trends 2024 and 2025 — Mandiant, Google Cloud
• Global Cyber Risk Report 2025 — Aon
• The Sustained Negative Impacts of Cyber Incidents on Shareholder Value, April 2026 — ISS STOXX / Harvard Law School Forum on Corporate Governance
• Is Prevention Better Than Cure? Effects of Cyber Risk Disclosures on Shareholder Response to Breaches, September 2025 — Information Systems Research
• TIBER-EU framework — European Central Bank
• CBEST threat intelligence-led assessments — Bank of England
• DORA Article 26, threat-led penetration testing requirements — Regulation (EU) 2022/2554, EUR-Lex
• Data Breach Investigations Report — Verizon, annual series