The 2025 IBM Cost of a Data Breach Report records a global average breach cost of 4.44 million dollars, with United States organisations now averaging 10.22 million dollars per incident, an all-time high. Twenty percent of the studied organisations experienced breaches involving shadow artificial intelligence, adding an average of 670,000 dollars to the cost. Ninety-seven percent of organisations that reported AI-related breaches had not implemented proper access controls. The ENISA Threat Landscape 2025, covering 4,875 incidents between July 2024 and June 2025, records phishing as the entry vector in sixty percent of cases.
The numbers are not new, in their shape. Twenty years of post-mortems, conducted by every major consulting firm and every major industry analyst, have documented the same recurring patterns of failure. The frameworks have multiplied. The mistakes have not. This article documents the ten mistakes that, in 2026, a Chief Information Security Officer should not make in cybersecurity risk management, with the operational and normative reference points that anchor each of them.
One: Mistaking the framework for the posture
The most frequent strategic mistake in cyber risk management is the confusion between the documentation of the framework (governance charters, policy documents, control statements, maturity dashboards) and the operational posture of the organisation (the directory listing, the legacy authentication endpoints, the service accounts provisioned ten years ago and never decommissioned). The maturity dashboard, in many enterprises, has been the artifact the board reviews, the auditor examines, the insurer prices, and the customer questionnaire references. The directory listing has been the artifact the attacker examines. The two are not the same document.
The corrective is to ensure that the risk function reports against both surfaces in parallel: the documented posture (framework, policies, maturity) and the operational posture (control effectiveness, real-time detection capability, attack surface inventory). The first answers the audit. The second answers the breach.
Two: Measuring what is easy to measure, not what matters
The median enterprise cyber risk dashboard, in 2026, contains between 100 and 250 key performance indicators. The most frequently tracked include policy training completion, incident closure rate, audit finding remediation rate, third-party assessment completion. Each is easy to measure. Each is easy to report. Few of them, individually or in combination, measure whether the organisation is being broken into.
The measurements that matter, by the joint diagnosis of ENISA, NIST, and the FAIR Institute, are operational. Time-to-detect for credential-based intrusions. Mean time-to-contain. Percentage of privileged accounts using just-in-time access. Percentage of internet-facing assets with documented vulnerability disclosure status. These metrics are harder to produce. They require integration with operational telemetry. They are also the metrics the next auditor with a serious mandate will ask to see.
Three: Treating the risk register as a document, not as a decision
A risk register without prioritisation is a list. A list without an owner is noise. The risk register, by the design of ISO 27005 and DORA article 6, is a decision-making instrument. Each entry should be associated with a quantified impact, a quantified probability, an owner, a treatment decision, and a measurable due date. In most observed registers, the first three are present, and the last two are not.
The corrective is to enforce, at governance level, that no risk enters the register without an owner and a treatment decision dated and recorded. The register, in this configuration, is a sequence of decisions the organisation has taken. In the absence of that configuration, the register is documentation, not management.
Four: Confusing “control implemented” with “control effective”
The risk function, in many enterprises, records the implementation of a control as the completion of the risk treatment. The implementation may be technically complete and operationally ineffective. The control may be present in the configuration baseline and bypassed by ninety percent of the actual transactions. The control may be enabled in production and never triggered, because the trigger condition was never reproduced in operational testing.
DORA article 24 and NIS2 article 21 both require continuous monitoring of control effectiveness, not merely of control implementation. The corrective is to schedule, at periodic intervals, the operational validation of every critical control through controlled exercise (red team, purple team, control test). Presence is not performance.
Five: Ignoring the time dimension in risk classification
Most risk matrices in use, in 2026, classify risks against two axes: impact and probability. The cumulative effect, in the typical enterprise risk register, is that more than half of all recorded risks are classified as “high” or “critical.” When every risk is high, no risk is prioritisable, and the register collapses into a flat list.
The missing axis is proximity. A risk that materialises in the next forty-eight hours requires a different operational response than a risk that materialises over the next three years, even if both are classified as “high” on impact and probability. NIST SP 800-39, in its guidance on enterprise risk management, recommends explicit handling of the temporal dimension. Most operational risk registers do not handle it. The corrective is to add the time-to-materialisation axis and to recalibrate the register against it. High everywhere is the same as high nowhere.
Six: Outsourcing accountability to the vendor
The procurement of a cybersecurity platform, however expensive and however technically sophisticated, does not transfer accountability for the risk to the vendor. Article 28 of DORA explicitly assigns accountability for ICT third-party risk to the financial entity, not to the service provider. Article 21 of NIS2 makes the same point for essential and important entities. The platform is a tool of risk management. It is not a substitute for the exercise of due diligence and continuous oversight.
The corrective is to maintain, alongside the procurement of vendor tooling, the in-house competence to assess, audit, and supervise the vendor performance against the contracted commitments. The vendor is an extension of the risk function, not a replacement.
Seven: Running tabletop exercises on reassuring scenarios
The tabletop exercise is a useful instrument of risk preparation when it forces the organisation to confront scenarios it has not already anticipated. It becomes performance theatre when it rehearses scenarios the organisation has already documented, prepared playbooks for, and trained against. The breach you have already imagined is the one that will not happen. The breach that will happen is the one that combines two failure modes you have considered separately.
The corrective, in the design of NIST SP 800-84 and ENISA’s tabletop guidance, is to engineer scenarios that combine an unknown initial vector, an unfamiliar internal failure (a missing log, a delayed decision, a compromised privileged account that the SOC does not have visibility on), and a public dimension (regulator notification, media exposure, customer escalation). The tabletop that the participants find uncomfortable is the tabletop that prepares them.
Eight: Confusing compliance with security
Passing the audit is not the same as being protected. The auditor verifies, in most cases, the documented presence of the controls described in the regulation or the standard. The auditor does not, in most engagements, verify the operational effectiveness of those controls against the current generation of offensive tooling. A bank that passes its DORA assessment in February 2026 and is breached via credential-stuffing in July 2026 has, by the formal record, been compliant. It has not, by any operational record, been secure.
The corrective is to manage compliance and security as adjacent functions with overlapping but distinct success criteria. Compliance ensures the framework. Security ensures the outcome. The CISO who reports only against compliance is reporting against half of the mandate.
Nine: Treating technical debt as an asset, not as an active risk
The legacy authentication endpoint provisioned in 2003 and never decommissioned, the service account whose owner left the organisation in 2014, the SaaS subscription whose contract auto-renews without review, the certificate that expired and was replaced by an exemption ticket, the platform that the migration plan was supposed to retire in 2021. Each of these is, in the typical enterprise asset register, listed as an active asset. Each of these is, in the operational reality, an active risk.
Technical debt that has accumulated for more than five years is, by every observed pattern in post-incident analysis, the most frequent vector of compromise. The corrective is to maintain a separate sub-register of legacy components with risk-weighted prioritisation, scheduled review, and explicit accountability. The endpoint provisioned in 2003 is on the risk register, or it is on the next forensics report.
Ten: Communicating to the board in CVE, not in euros
The board does not understand CVE identifiers, CVSS scores, MITRE ATT&CK techniques, or PCAP analyses. The board understands euros (or dollars, or pounds), time, and reputational exposure. A risk that has not been translated into those three quantities is, structurally, ignored by the governance layer that should be deciding on it.
The corrective, in the framework of the FAIR (Factor Analysis of Information Risk) methodology and the ISO 31000 enterprise risk management standard, is to express every material cyber risk as a quantified financial exposure, with a probability distribution, a time horizon, and a downstream impact on revenue, regulatory exposure, and reputation. The CISO who has not done this translation has not communicated the risk. The board that has not received this translation has not decided on the risk. Twenty years of post-breach narratives are populated by boards that did not understand, and CISOs that did not translate.
Cybersecurity risk management, in 2026, has accumulated more frameworks, more methodologies, more standards, more certifications, and more tooling than at any previous point in its history. The infrastructure of the discipline is mature. The discipline itself, measured against breach outcomes, has not improved at the rate the infrastructure would predict. Twenty years of post-mortems document the same ten mistakes recurring across organisations of every sector and every size.
The ten mistakes are not a knowledge gap. The ten mistakes are an organisational equilibrium. The frameworks have not corrected the equilibrium. The risk function that corrects the equilibrium, in 2026, is the function that has integrated the documentation surface with the operational surface, has prioritised the risks against time as well as impact, has held the vendor accountable while exercising its own due diligence, has tested against scenarios that make participants uncomfortable, has translated every risk into the language the board understands, and has treated technical debt as the active risk it is.
The risk function that has done these things, in 2026, is the rare one. The risk function that has done none of them is the data point in the next IBM report.
All my books on cybersecurity and governance are here 👉 https://www.amazon.it/stores/author/B0FB47T6Q4/allbooks
My “unfiltered” podcast SPYK :
🎧 Apple Podcasts 👉 https://podcasts.apple.com/it/podcast/spyk-uk-edition/id1896617808?i=1000767770385
🎧 Spotify 👉 https://open.spotify.com/show/033fU0Ds43aJrquCYYltWV?si=4eaafac135e848df
Also on #iHeartRadio, #AmazonMusic / #Audible, #Castbox, #Deezer, #PodcastAddict, #Podchaser.
Sources: IBM, Cost of a Data Breach Report 2025; ENISA, Threat Landscape 2025; NIST SP 800-39, Managing Information Security Risk; NIST SP 800-84, Test, Training, and Exercise Programs; ISO/IEC 27005, Information Security Risk Management; ISO 31000, Risk Management; Regulation EU 2022/2554 (DORA); Directive EU 2022/2555 (NIS2); FAIR Institute.