It’s a question of how organisations govern risk, make decisions, and allocate accountability.
1. The Wrong Frame
Most organisations didn’t choose to treat cybersecurity as an IT problem. It happened gradually, and for understandable reasons.
When digital infrastructure first entered the enterprise, the people who understood it sat in IT departments. Security followed the same path. Firewalls, antivirus, access controls — these were technical problems with technical solutions, and the people who managed them reported to technology leadership.
That model made sense for a simpler environment.
It no longer reflects the environment most organisations operate in.
Cloud platforms, SaaS ecosystems, AI systems, complex integration layers and deep dependencies on third-party providers have made organisations operationally far more interconnected — and far more exposed to disruption — than the original IT security model was designed to address.
A ransomware attack today does not look like a technical incident contained within an IT perimeter. It looks like an operational crisis: production stops, customer-facing systems go dark, contractual obligations cannot be met, regulators ask questions, and the board discovers — often for the first time — that the organisation’s ability to function depended on infrastructure it did not fully understand.
The technology changed. The governance model largely did not.
That gap — between the complexity of modern digital dependencies and the organisational structures designed to govern them — is where most serious cyber incidents begin. Not in the absence of technology. In the absence of the right decisions, made by the right people, with the right information.
2. What the Data Shows
The disconnect is not anecdotal.
Research published in Management Research Review (Romanosky & Petrun Sayers, 2024), based on interviews with risk practitioners across industries, found a consistent pattern: in most organisations, cyber risk is managed separately from the enterprise risk management process. It is collected differently, characterised differently, and reported differently — often by a different function, using different language, to a different audience.
The result is predictable. Risk registers capture financial, operational and strategic risk in an integrated framework. Cyber risk sits alongside them on paper — but is rarely connected to them in practice. Business units set priorities based on one picture of organisational exposure. Security functions work from another. The board receives reporting that reflects neither with sufficient clarity to support informed decisions.
This is not a failure of intent. Most organisations want to manage cyber risk well. The problem is structural. Cyber risk has been placed inside a function — technology or security — rather than inside a process: the enterprise risk management process that connects exposure to decisions, decisions to accountability, and accountability to governance.
A parallel finding emerges from academic work published by Monash University researchers (Oh, Hoang, Sturdy & Guo, 2025): effective cybersecurity governance cannot be optimised as a standalone function. It requires integration across the interdependent functions of the organisation — technology, finance, operations, human factors — within a coherent governance framework embedded in ERM. The whole, as the authors put it, is greater than the sum of its parts. The inverse is also true: a cybersecurity function optimised in isolation will consistently underperform against the actual risk profile of the organisation.
NIST recognised this problem explicitly. NIST Interagency Report 8286 — Integrating Cybersecurity and Enterprise Risk Management — maps cybersecurity risk directly onto enterprise risk categories: financial risk, reputational risk, operational risk, legal and regulatory risk. The document exists because the gap between cyber and ERM was wide enough, and consequential enough, to require a formal framework for closing it.
The gap is still wide.
3. The Compliance Trap
There is a belief, widespread and persistent, that a well-governed organisation is one that passes its audits.
It is understandable. Audits are visible. Certifications are concrete. A passed audit produces a document that can be shown to regulators, to boards, to insurers. It creates a sense of closure — the work is done, the box is checked, the risk is managed.
The problem is that audit-readiness and incident-readiness are not the same thing. And in a serious incident, the difference becomes impossible to ignore.
An organisation can have formally documented policies that are not operationally embedded. It can hold a certification that evaluates whether a management system functions — not whether specific regulatory requirements are met, not whether the organisation can detect and respond to a sophisticated attack within a timeframe that limits damage. It can pass every scheduled assessment and still discover, under pressure, that ownership is unclear, that escalation paths were never tested, that third-party dependencies were not mapped with sufficient granularity to know which ones are critical.
McKinsey has documented several of the misconceptions that drive this pattern. Among the most consequential: the belief that security investment produces security outcomes in a linear relationship, and that compliance with a recognised framework is equivalent to operational resilience. Neither holds under scrutiny. Security spending without governance integration produces activity, not capability. Compliance without operational embedding produces documentation, not preparedness.
The regulators writing NIS2, DORA and the AI Act understand this distinction. This is why NIS2 places explicit accountability on management bodies — not on security functions. Why DORA requires documented testing of operational resilience, not just the existence of resilience plans. Why both frameworks impose incident reporting obligations that assume an organisation has the detection and escalation capability to meet them.
The compliance question is necessary. It is not sufficient.
An organisation that treats regulatory compliance as the destination has misread the map. Compliance defines the minimum. Governance determines whether the organisation can actually function when something goes wrong.
4. What Integration Actually Requires
Integrating cyber risk into enterprise risk management is not a reporting exercise.
It is not achieved by adding a cyber risk line to the existing risk register, or by asking the CISO to present at the next board meeting, or by mapping security controls to a recognised framework and calling the result a governance programme. These are visible actions. They produce the appearance of integration without the substance.
Substance requires three things.
A shared language for risk.
The enterprise risk management process runs on a common currency: business impact. Financial exposure, operational disruption, reputational damage, regulatory consequence. Cyber risk, expressed in technical terms — vulnerability counts, patch rates, mean time to detect — does not convert naturally into that currency. It requires translation. Not simplification. Translation: the discipline of connecting a technical condition to a business consequence, in terms that allow a non-technical decision-maker to understand what is at stake and make an informed choice about how much of it the organisation is willing to accept.
NIST IR 8286 provides the structural framework for this translation. It maps cybersecurity risk categories directly to enterprise risk categories and establishes the concept of cyber risk appetite as a component of the broader organisational risk appetite. The document is technical in places. The underlying logic is not: organisations cannot govern what they cannot express in terms their decision-makers understand.
Clear ownership above the security function.
Cyber risk that is owned exclusively by the security function is cyber risk that stops at the boundary of that function. It does not inform procurement decisions, vendor selection, product development timelines, market entry strategies or acquisition due diligence — unless the governance structure explicitly requires it to.
The World Economic Forum’s principles for board governance of cyber risk are direct on this point. Cyber risk is an enterprise risk. Responsibility for governing it belongs to the organisation’s leadership, not to a specialist function within it. The CISO’s role is to provide expertise, analysis and recommendation. The decision about what risk to accept, transfer or mitigate — and on what basis — belongs to the leadership that is accountable for the organisation’s overall risk posture.
This is also what NIS2 means when it places accountability on management bodies. Not that management must become technically proficient. That management must be sufficiently informed to make defensible decisions — and must be able to demonstrate, if asked, that those decisions were made consciously, on the basis of adequate information, with appropriate oversight.
Risk appetite that is explicit and operational.
Most organisations have a risk appetite statement. Few have one that is specific enough to guide decisions at the point where they are actually made.
A risk appetite statement that says the organisation has a “low tolerance for cyber risk” does not tell a business unit leader whether a particular third-party integration is acceptable. It does not tell a procurement function what due diligence is required before onboarding a critical vendor. It does not tell the board whether the current security investment is calibrated to the organisation’s actual exposure — or to last year’s threat landscape, or to what a peer organisation was spending three years ago.
Operational risk appetite translates the general statement into specific guidance: what categories of risk are acceptable at what levels, under what conditions, with what compensating controls, reviewed on what basis. It connects the governance framework to the decisions the framework is supposed to govern.
Without it, cyber governance is a structure without a function. It exists. It does not operate.
5. What the Board’s Role Actually Is
The board’s role in cyber risk governance is frequently misunderstood — in both directions.
One misunderstanding is that the board should not be involved in cyber risk at all. That it is too technical, too operational, too far from the strategic questions that belong at board level. Under this model, cyber risk is delegated entirely to management, surfaces in board reporting as a status update, and receives serious attention only after a significant incident.
The other misunderstanding is that board involvement means board expertise. That directors need to understand security architecture, threat intelligence or technical controls to discharge their oversight responsibility effectively.
Neither is correct.
The board’s role in cyber risk is the same as its role in any material business risk: to ensure that the organisation has an adequate framework for identifying, assessing and managing that risk; that management is accountable for operating within it; and that the board itself receives the information it needs to exercise meaningful oversight.
That is a governance question, not a technical one.
What makes it difficult is that the information boards typically receive about cyber risk is not designed to support governance decisions. It is designed to demonstrate activity. Patch compliance rates, vulnerability counts, security tool coverage, training completion percentages — these metrics answer the question “what is the security function doing?” They do not answer the question the board needs to be able to answer: “what is our actual exposure, what have we decided to accept, and on what basis?”
PwC’s work on board oversight of cyber risk identifies this as one of the most persistent gaps in current practice. Boards are receiving cyber reporting. They are not consistently receiving cyber risk information in a form that connects to business impact, strategic priorities or the organisation’s stated risk appetite.
The WEF principles for board governance address this directly. Effective board oversight requires that cyber risk be integrated into the organisation’s overall risk framework — not reported as a separate technical domain. It requires that boards have access to expertise, whether internal or external, sufficient to interrogate the information they receive. And it requires that the organisation’s approach to cyber risk be reviewed regularly against an evolving threat environment, not treated as a static compliance posture.
In practice, this means the board needs to be able to ask — and receive credible answers to — a specific set of questions.
Not “are we secure?” That question has no meaningful answer.
But: what are the scenarios that would materially disrupt our operations, and what is our assessed exposure to each of them? What risk have we consciously accepted, and who made that decision on what basis? Where are our critical dependencies — on third parties, on specific systems, on key personnel — and do we understand what happens if any of them fail? What would a serious incident cost us, operationally and reputationally, and are we satisfied that our current posture is calibrated to that exposure?
These are business questions. They require cyber expertise to answer well. They do not require the board to possess that expertise itself.
The governance failure that precedes most serious incidents is not that the board lacked technical knowledge. It is that the organisation had no structure for connecting cyber risk to the decisions the board was already making — about strategy, about investment, about operational priorities, about the risk the organisation was willing to carry.
That structure is what governance is for.
6. The Real Question
Organisations that manage cyber risk well are not necessarily those with the largest security budgets.
They are not always those with the most mature technical controls, the most comprehensive tool coverage, or the most recently updated policies. These things matter. They are not sufficient, and they are not the differentiator.
The differentiator is a question.
Not “how secure are we?” — which is unanswerable in any meaningful sense, and which tends to produce reporting designed to reassure rather than inform.
The question is: what risk have we consciously accepted, and can we demonstrate that the decision was made by the right people, on the basis of adequate information, with appropriate oversight?
That question changes what governance looks like in practice.
It means that a risk acceptance decision — to proceed with a third-party integration despite identified exposure, to delay a remediation because of competing business priorities, to enter a new market before the risk framework has been updated to reflect the new regulatory environment — needs to be documented. Not because documentation is the goal. Because documentation is the evidence that a decision was made consciously, rather than by default.
It means that the CISO’s role is not to own cyber risk. It is to make cyber risk visible, quantified in business terms, and actionable for the people who do own it — which is the leadership of the organisation.
It means that the board’s oversight function is not discharged by receiving a security update. It is discharged by ensuring that the organisation has a structure for making and recording risk decisions, that management operates within it, and that the board can demonstrate — if a regulator, an auditor, or a court asks — that its oversight was real and not ceremonial.
This is what NIS2 means by management body accountability. This is what DORA means by ICT governance. This is what every serious governance framework converges on when it addresses cyber risk at the enterprise level.
The research supports it. The regulatory direction confirms it. The pattern of incidents over the past decade illustrates what happens when it is absent.
Cyber risk is not a technology problem with a technology solution.
It is a governance problem — a question of how an organisation makes decisions about risk, who is accountable for those decisions, and whether the structure exists to ensure that accountability is real rather than assumed.
The organisations that understand this are not necessarily better protected against every possible threat. No governance framework eliminates risk. But they are better positioned to manage it — to know what they have accepted and why, to respond coherently when something goes wrong, and to demonstrate, when asked, that they took their responsibilities seriously.
That is what defensible governance looks like.
And in a regulatory environment that is moving — rapidly and consistently — toward personal accountability at management level, the difference between governance that is defensible and governance that only looks defensible is no longer an abstract question.
It is a business risk.
If your organisation has invested seriously in security — and still isn’t confident it would hold under regulatory scrutiny or a real incident — the gap is usually not in the technology. It’s worth understanding where it actually is.
Senad Džananović is a senior Cyber and AI Governance advisor with 20+ years of experience across Central and Eastern Europe. He works with boards, CISOs and risk managers to translate governance and regulatory requirements into systems that hold under audit, regulatory scrutiny and real incidents.
