Skip to content
CISOteria

Author: CISOteria

The CISO-CIO Relationship: The Collision Between Security, Speed, and Business

Posted on by CISOteria

The CISO-CIO Relationship Is Difficult for a Good Reason

The CISO-CIO relationship is often described as a problem of personalities, communication styles, or competing executive agendas, but that explanation is too simple. A CIO who wants technology to remain available, efficient, scalable, and capable of supporting the business is doing the job the organization expects. A CISO who questions whether the same environment is resilient, defensible, compliant, and sufficiently protected is doing exactly the same.

The difficulty begins because both executives increasingly govern different consequences of the same decisions.

A cloud migration may improve scalability and simplify infrastructure, while simultaneously changing data flows, third-party dependencies, access models, and recovery assumptions. Connecting manufacturing systems to analytics platforms may increase operational visibility, but it can also pull previously isolated systems into the cybersecurity perimeter. Generative AI may improve productivity while creating new questions around data exposure, identity, intellectual property, and misuse.

The technology decision and the security decision are no longer easy to separate.

That change is reflected in recent research on the CISO role itself. Christopher Ramezan’s 2025 analysis of 250 CISO job postings across 27 countries found that organizations increasingly define the CISO as a strategic and management-focused executive rather than a deeply tactical technical specialist. Risk management, policy, strategic planning, incident management, communication, governance, and business alignment appear far more prominently than programming or expertise with specific software.

The CISO is no longer merely protecting systems after the technology organization has designed them. The role is moving directly into decisions about how technology should be governed, what risk is acceptable, where investment should go, and how business strategy should account for cyber exposure.

The boundary between CIO and CISO is therefore becoming harder to draw at exactly the moment when organizations need that boundary to be better governed.

Five Points of Tension in the CISO-CIO Relationship 

Technology Speed vs. Security Risk

The easiest version of the CISO-CIO conflict is the familiar one: the CIO wants speed, while the CISO wants control. In practice, however, most of the difficult decisions are not that clean.

The CIO may be accountable for availability, modernization, digital transformation, service delivery, and technology costs. The CISO may be accountable for cybersecurity strategy, resilience, risk management, security policy, and incident readiness. Operations wants systems to keep running, finance wants investment discipline, and the business wants new capabilities without unnecessary delay.

Eventually, all of those priorities meet in the same architecture.

The 2025 interview with Nestlé Group CIO Chris Wright and CISO John Petersen illustrates this particularly well. Their environment has changed from relatively centralized IT systems to a much more complex landscape involving cloud services, SaaS, connected factories, operational technology, AI, global data movement, and geopolitical risk. Wright notes that a growing portion of the CISO’s work no longer concerns conventional IT applications at all, yet many security decisions still require the CIO’s teams to act quickly.

The CISO may identify the exposure, but the CIO often controls much of the environment required to change it. The CIO may own the technology program, while the business ultimately owns the consequences of delaying it or accepting the remaining risk.

Once the disagreement is framed as “security versus the business,” the conversation is already too shallow. The real question is how much security, resilience, speed, cost, and operational flexibility the organization is willing to buy, and what risk it is prepared to keep.

That is not a decision either executive should have to make alone.

Should the CISO Report to the CIO? 

Few questions generate as much debate as whether the CISO should report to the CIO.

The argument for separation is obvious. If the CISO reports to the executive responsible for technology delivery, the person expected to challenge technology risk may also be subordinate to the person whose priorities they occasionally need to slow, question, or escalate.

The opposite argument is equally practical. Cybersecurity recommendations eventually have to change networks, platforms, applications, endpoints, identities, cloud environments, and operational processes. A CISO who is organizationally independent but too far removed from technology execution may have authority on paper and very little influence in practice.

Nestlé keeps the CISO within the CIO organization. Both executives say this helps security and IT act faster when infrastructure teams need to change priorities. Petersen also argues that, unlike CISOs who mainly advise on policy from outside IT, having operational responsibility gives him more direct influence over security outcomes. 

That does not mean every CISO should report to the CIO. The authors themselves note that there is still limited research capable of identifying one reporting model as universally superior.

The more useful question is whether the organization preserves both influence and challenge.

The CISO needs enough proximity to technology decisions to shape them before they become expensive to reverse, but also needs a credible escalation route when security concerns cannot be resolved inside the technology organization. The CIO needs the authority to run technology without every disagreement becoming a governance crisis, but should not quietly absorb enterprise cyber risk simply because the affected systems sit inside IT.

The reporting line matters. The decision rights around it matter more.

Security Budgets: Who Pays, Who Prioritizes, Who Accepts Risk? 

Budget conversations expose the CISO-CIO relationship particularly quickly because security spending competes with every other technology priority.

The security function can almost always identify another control, monitoring capability, specialist, redundancy layer, or remediation program that would reduce risk. The CIO can almost always identify another modernization project, reliability improvement, automation initiative, or capacity investment with obvious operational value. Somewhere outside both functions, the business is asking why either one needs more money.

Wright describes cybersecurity investment alongside other technology and resilience investments such as failover systems, reliability, and upgrades. Petersen similarly emphasizes that security spending needs to be tied to the risk being reduced rather than defended as a principle in itself.

In many cases, budget disagreements are actually disagreements about risk. The CISO should be able to explain what exposure an investment reduces, what remains afterwards, and what happens if the decision is delayed. The CIO should be able to explain which competing technology or operational objective will be displaced. If the trade-off is significant enough, the final decision may need to move above both executives.

Cybersecurity then becomes part of normal enterprise risk allocation rather than a protected category of spending that must be justified through fear.

How CISO-CIO Trust Shapes Incident Response 

Governance is relatively easy when there is time to prepare the presentation, gather evidence, schedule a committee, and debate the options. Cyber incidents rarely provide that luxury.

The CIO-CISO relationship becomes especially important when decisions must be made quickly and without a large steering group. Incidents, third-party issues, false breach claims, and reputational threats may require technical analysis and external communication to move almost at the same time. Wright describes situations in which a public claim can spread quickly enough that the organization has very little time to prepare a response, even when no genuine breach has occurred.

In those moments, trust stops being a soft leadership concept and becomes part of incident-response capability.

A CISO who has to spend the first hour convincing the CIO that a warning deserves attention has already lost time. A CIO who has learned that every security concern arrives labelled as urgent may hesitate when urgency is finally justified. A relationship in which difficult information is carefully packaged to manage perception will move more slowly than one in which uncertainty can be discussed openly.

Trust is especially important in these situations. Both executives need to be able to raise difficult concerns and discuss uncertainty without turning the conversation into a defence of their own function. 

For that reason, CIO-CISO collaboration should be tested in the same way organizations test technical recovery and crisis communication. Tabletop exercises should force disagreements about shutting systems down, restoring potentially compromised services, delaying remediation, accepting degraded operations, prioritizing business units, and acting on incomplete information.

The point is not to make the CIO and CISO agree beforehand.

The point is to understand how they make decisions when they do not.

Cyber Risk Ownership: Responsibility Without Authority 

The modern CISO is frequently held responsible for protecting an environment they do not fully control.

Ramezan’s study shows how broad the role has become, covering areas such as risk management, incident response, privacy, strategy, and business continuity. Yet many of the systems creating those risks belong elsewhere. Infrastructure may sit with the CIO, operational systems with business units, and vendor decisions with procurement. 

This creates a dangerous gap between responsibility and authority.

The CISO may be accountable for cybersecurity without having the authority to determine every technology architecture. The CIO may own the systems without having the authority to accept every business consequence of the risks they create. Business leaders may own the outcome without understanding the technical exposure underneath it.

When those distinctions remain implicit, the same risk can be identified by security, technically owned by IT, delayed by operations, financially deprioritized by leadership, and still appear after an incident as a failure of the security team.

That is not a communication problem. It is a governance problem.

Shared Cybersecurity Responsibility Needs Clear Decision Rights 

It is tempting to solve this by saying that cybersecurity is everyone’s responsibility, but broad shared responsibility can become just another way of avoiding precise accountability.

The organization still needs to know who sets mandatory security requirements, who owns implementation, who can approve an exception, who accepts residual business risk, and when disagreement must be escalated.

Those answers do not need to live entirely with either the CIO or the CISO.

They do need to exist before the decision becomes urgent.

The same principle applies earlier in the technology lifecycle. When security first enters a major project after the architecture has been selected, contracts signed, and launch date announced, almost every control becomes more expensive. The CISO is then forced either to accept exposure or become the executive delaying the initiative, while the CIO is forced to defend decisions that may have been reasonable before security entered the conversation.

Early involvement changes the economics of the disagreement.

Security can shape architecture while alternatives still exist, and technology teams can challenge security assumptions before they harden into requirements.

That is where productive CIO-CISO collaboration actually begins.

Conclusion: Stop Trying to Remove the Tension

There will always be moments when the CISO wants more control, the CIO wants more speed, or operations cannot support the remediation window security would prefer. 

That does not mean the relationship has failed. 

The failure begins when the trade-off remains hidden, when nobody knows who has authority to make the decision, when security is left accountable for a choice it could not control, or when technology quietly absorbs a level of business risk it was never authorized to accept.

The goal is not perfect agreement between the CIO and CISO. It is productive friction supported by clear governance and decision rights. 

As their responsibilities continue to overlap, organizations will need to get better at managing the space between security, technology, operations, and business priorities.

The key question is simple: when the next technology decision creates both business value and cyber risk, does everyone already know who gets to decide what happens next?

For Further Reading

This blog post is based on insights and analysis from:

  • Johnson, M. Eric, and Hans Brechbühl. “The CIO–CISO relationship in a globally networked business – An interview with Nestlé AG.” Electronic Markets 35.1 (2025): 44. 

https://doi.org/10.1007/s12525-025-00786-8 

  • Ramezan, Christopher A. “Understanding the chief information security officer: Qualifications and responsibilities for cybersecurity leadership.” Computers & Security 152 (2025): 104363. https://doi.org/10.1016/j.cose.2025.104363

Executive Decision Rights: Who Decides in a Cyber Crisis?

Posted on by CISOteria

Why Cyber Crisis Decisions Stall 

Executive decision rights define who has final authority to approve consequential business actions during a cyber crisis, including accepting risk, suspending operations, and authorizing external disclosure.

Yet executive decision rights rarely seem urgent while everything is working. There is time to consult another executive, ask Legal for an opinion, move an uncomfortable question into the next committee meeting, or let an ambiguous responsibility survive because nobody is paying a visible price for it.

Then the incident begins.

Security believes an attacker may still have access to a critical environment and recommends isolating several systems. Operations warns that doing so could interrupt a major service. Legal cannot yet confirm whether the incident crosses a disclosure threshold. Communications wants to know what can be said publicly, and leadership is waiting for more certainty before approving anything irreversible.

The organization has people responsible for every part of the problem, yet the decision itself seems to belong to no one.

Recent research on cyber crisis readiness identifies this kind of responsibility ambiguity as a real weakness. Björck and colleagues found that undefined responsibilities can increase inefficiency during cyber crises, while stronger readiness depends on clear roles, cross-functional coordination, leadership involvement, and the ability to internalize responsibilities before pressure arrives.

That still leaves a harder question than who participates in the crisis.

Who actually decides?

When Cybersecurity Decisions Become Business Decisions 

Many technical actions already have clear owners. Security teams can isolate endpoints, block malicious activity, revoke credentials, or activate incident-response procedures within established authority.

The difficult decisions appear when the security action creates consequences somewhere else in the business.

A shutdown may contain an attacker while stopping revenue. A delayed shutdown may preserve availability while expanding compromise. Early disclosure may protect trust while exposing incomplete information. Waiting may avoid unnecessary alarm while giving someone outside the company control over when the incident becomes public.

Harel and Carmeli’s 2025 cybersecurity oversight framework describes this separation between operational management and strategic decision control. Their research argues that boards should focus on matters such as organizational criticality, risk tolerance, strategic consequences, resource allocation, and accountability, while operational execution remains with management and technical teams.

That distinction becomes particularly important during a crisis because several legitimate authorities suddenly meet around the same decision.

The CISO understands the security risk, the COO understands operational consequences, Legal sees regulatory exposure, Communications sees stakeholder reaction, and senior management sees the broader business.

All of them should influence the decision.

They do not all need to own it.

Three Cyber Crisis Decisions That Need Clear Authority 

Risk Acceptance: Who Gets to Say, “We’ll Live With It”? 

The CISO can determine that a system is unsafe, explain the uncertainty, estimate potential exposure, and recommend containment, but that does not automatically mean the CISO should accept the resulting business risk on behalf of the organization.

Risk acceptance becomes a business decision precisely because its consequences reach beyond cybersecurity.

Harel and Carmeli argue that organizations should establish their tolerance for functional disruption and define the relative importance of critical assets before a breach occurs. Those discussions belong in routine governance because they create the boundaries within which crisis decisions can later be made quickly.

If the CISO is recommending continued operation despite known exposure, the organization should already know who has authority to accept that exposure.

Operational Shutdowns: Who Gets to Pull the Plug? 

Shutdown decisions create the opposite problem. Security may believe isolation is necessary while Operations sees the shutdown itself as the larger immediate threat.

Harel and Carmeli use Colonial Pipeline as an example of this trade-off. The company shut down its pipeline network as a precaution even though the operational technology itself had not been infected, accepting major operational consequences to reduce further uncertainty and potential harm. Their framework explicitly treats shutdowns and service prioritization as strategic questions during an attack.

The point is not that shutdown is always the right decision. The point is that deciding who can authorize one should not begin after the recommendation has already been made.

Incident Disclosure: Who Approves What Goes Public? 

Disclosure creates another collision of expertise. Security understands the evidence, Legal interprets regulatory obligations, Communications considers public impact, executives understand commercial consequences, and the board may need visibility where the incident becomes strategically significant.

Harel and Carmeli specifically identify questions around whether to disclose proactively, what information should be shared with customers, investors, and regulators, and how quickly that communication should happen.

Those perspectives need to meet, but collaboration cannot leave the final authority undefined.

A crisis committee where everyone can advise and nobody can close the decision is still a slow crisis committee.

When a RACI Leaves Decision Authority Unclear 

Organizations often respond to governance ambiguity by documenting more roles.

That helps, but it is not enough.

Björck and colleagues distinguish between preparedness and readiness. Preparedness includes plans, procedures, simulations, and escalation protocols, while readiness includes the leadership, behavior, trust, communication, and adaptive capacity required when a situation no longer fits the script. Their findings show that an organization can be well documented without being genuinely ready to act.

A RACI can tell everyone why they are in the room and still fail to answer who has the final authority when those people disagree. A more useful approach starts with the decisions themselves.

Who can accept residual risk above normal tolerance? Who can suspend a business-critical service? Who can authorize emergency expenditure? Who approves external disclosure? Which decisions reach the CEO, and which require board involvement?

Once those decisions are named, the organization can attach authority to them instead of hoping authority will emerge naturally from job titles.

CISO Authority: Where Delegation Starts and Stops 

Giving the CISO stronger authority is often part of the answer.

A security leader who needs executive approval for every containment action does not have a workable incident-response mandate. The CISO and security function need enough delegated authority to investigate, contain, escalate, activate specialist support, and enforce approved emergency controls without waiting for permission at every step.

The danger appears when that authority quietly turns into ownership of every business consequence associated with cybersecurity.

If shutting down a system will stop production, interrupt a critical service, create major financial losses, or affect customers at scale, the CISO’s recommendation remains essential, but the final business-risk decision may belong elsewhere.

This is where Executive Decision Rights create a healthier boundary. The CISO can act decisively within predefined limits while knowing exactly when authority moves to another executive because the consequence has crossed an operational, financial, legal, or strategic threshold.

The organization avoids two equally weak models: one where security cannot move without executive permission, and another where the CISO becomes the default owner of risks the business itself has chosen to take.

Five Rules for Executive Decision Rights Under Pressure 

Drawing on the two studies, the following five rules translate their governance and readiness insights into practical recommendations for defining decision authority.

1. Tie authority to consequences

Incident severity alone is often too technical to determine who should decide. Escalation thresholds should also consider operational downtime, customer impact, financial exposure, sensitive-data compromise, regulatory consequences, safety, and critical dependencies.

Harel and Carmeli place this preparation in the pre-incident phase, where leadership should already understand critical assets, risk tolerance, and acceptable levels of disruption.

2. Separate advice from decision authority

Security can recommend shutdown without owning the commercial consequences. Legal can identify regulatory exposure without becoming the owner of every communication decision. Operations can explain continuity impact without deciding how much cyber risk the enterprise should accept.

The stronger the expertise in the room, the easier it becomes to confuse influence with authority.

A mature structure protects both.

3. Keep strategic and operational decisions separate

Boards should not become incident commanders, just as CEOs should not approve every forensic action.

Harel and Carmeli note that boards should receive information and consider strategic implications during an attack while avoiding continuous operational decision-making. Their role becomes more relevant when the issue reaches major shutdowns, ransom, stakeholder communication, legal exposure, or broader strategic prioritization.

Clear boundaries allow operational teams to move while leadership focuses on the decisions that actually require executive judgment.

4. Design decision rights for uncertainty

Cyber crises rarely wait until the facts are complete.

Björck and colleagues describe cyber crises as opaque, fast-moving, and difficult to manage through predefined procedures alone. Their research emphasizes situational sensemaking, where teams must interpret incomplete signals and make judgments under pressure when existing scripts no longer provide a complete answer.

Decision rights therefore need to work before certainty exists.

Someone must know who can approve precautionary action, when uncertainty itself justifies escalation, and when an earlier decision must be revisited because the evidence has changed.

5. Test authority in tabletop exercises

Most tabletop exercises test whether the organization knows what to do.

They should also test whether the organization knows who can authorize it.

Björck and colleagues found scenario-based exercises valuable because they expose managerial as well as technical gaps and help teams internalize their roles under stress. Their study also describes one organization using separate strategic and operational crisis structures, allowing one group to make decisions while another executed them.

A useful tabletop should therefore create disagreement deliberately.

Security recommends taking a critical service offline, Operations objects, Legal has incomplete information, and leadership wants another hour.

Who decides?

The attacker claims data exfiltration, the investigation remains uncertain, rumors are already circulating, and disclosure may become unavoidable.

Who decides now?

The exercise is not only testing whether the organization chooses correctly. It is testing whether the organization can choose at all.

Consensus Should Improve the Decision, Not Delay It

Cyber crisis management has to be collaborative because no single function sees the full picture.

The problem begins when collaboration quietly turns into a requirement for consensus.

Björck and colleagues found that cyber crisis leadership requires a balance between directive and collaborative approaches, particularly because cross-functional coordination becomes more important as uncertainty grows. Their research also shows how siloed leadership can weaken response when organizational boundaries remain stronger than the shared crisis structure.

Clear decision rights make disagreement safer.

The CISO can argue for containment, Operations can explain the cost, Legal can identify uncertainty, Communications can challenge the timing, and Finance can quantify the exposure without everyone needing to reach the same conclusion.

The decision owner hears the arguments and closes the decision.

That is not weaker collaboration. It is collaboration with an endpoint.

Conclusion: Define Decision Rights Before the Crisis 

During routine operations, unclear authority is cheap. Another meeting can be scheduled, another executive can be consulted, and an ambiguous responsibility can survive for months without becoming visible.

A cyber crisis converts that ambiguity into delay.

Björck and colleagues argue that cyber crisis readiness depends on much more than documented procedures; organizations need internalized roles, adaptive behavior, leadership, and coordination that can survive pressure. Harel and Carmeli reach the same point through governance, arguing that organizations should establish tolerance levels, priorities, accountability, and crisis decision capacity before the attack begins.

Executive Decision Rights cannot guarantee that leaders will always make the perfect choice, because cyber crises rarely offer perfect choices.

They can ensure that when Security wants to shut something down, Operations wants to keep it running, Legal wants more evidence, and the clock is still moving, the organization does not have to solve one additional mystery.

Who decides?

For Further Reading

This blog post is based on insights and analysis from:

  • Björck, Albena, et al. “Advancing cyber crisis readiness: context, microfoundations and the role of leadership.” Journal of Communication Management 30.3 (2026): 322-341. 

https://doi.org/10.1108/JCOM-01-2025-0006 

  • Harel, Yaniv, and Abraham Carmeli. “A strategic cybersecurity oversight framework: a board’s imperative.” Journal of Cybersecurity 11.1 (2025): tyaf021. 

https://doi.org/10.1093/cybsec/tyaf021 

Decision-Making Under Uncertainty: How Security Leaders Decide Without the Full Picture

Posted on by CISOteria

Fog Is Part of the Forecast 

Decision-making under uncertainty is not an unusual condition in cybersecurity; it is the environment in which most consequential security decisions are made. A CISO deciding whether to accelerate an investment cannot know exactly which threat will materialize next, a board reviewing ransomware exposure cannot know how well every control will perform under real pressure, and an executive evaluating a critical supplier rarely has complete visibility into everything that could go wrong.

The difficulty is not simply that information is missing. Some of the information that leaders want cannot be measured with the precision they would prefer, while other assumptions may become outdated before the decision has had time to prove itself. Recent research suggests that the more useful goal is therefore not to eliminate uncertainty, but to understand where it sits inside the decision and make sure it is not hidden behind dashboards, risk scores, or numbers that appear more certain than the evidence behind them.

Rule 1: Stop Waiting for the Full Picture 

A 2026 study examined cybersecurity decision-making across strategic, tactical, and operational roles, drawing on interviews with 36 professionals across six organizations, including senior executives, board members, governance specialists, and operational security teams. The researchers describe cybersecurity decisions as being shaped by uncertainty, time pressure, information asymmetry, technical constraints, organizational priorities, and human judgment, all at the same time.

What makes this especially important is that the study identified 23 different factors influencing effective decision-making, ranging from resources, regulation, and organizational structure to risk profile, experience, confidence, teamwork, bias, and cybersecurity posture. More than half of those factors operated across several organizational levels rather than belonging neatly to one team or one decision-maker.

This means a security decision is rarely just a technical response to a technical problem. The same threat can lead to very different choices depending on the organization’s appetite for risk, the maturity of its security program, the experience of the people involved, the resources available, and the consequences the business is prepared to accept. The real question is therefore not simply whether the organization has enough data, but whether leaders understand what is shaping the judgment they are about to make.

More Information Does Not Remove Judgment

It is tempting to imagine that better telemetry, more dashboards, or a more sophisticated risk model will eventually turn cybersecurity into a clean optimization problem, where the organization identifies the threat, calculates the likelihood, measures the impact, and selects the best control. In practice, every one of those steps still depends on interpretation, and interpretation is where uncertainty enters.

The same 2026 study found that professionals rely not only on formal information, but also on experience, awareness, confidence, team dynamics, and their understanding of the wider threat landscape. In other words, data matters enormously, but it does not arrive pre-labeled with the correct decision attached to it.

Rule 2: Do Not Mistake Precision for Certainty 

A 2025 study examined cyber risk management in five multi-billion-dollar organizations through 27 in-depth interviews with cybersecurity professionals, executives, board members, risk managers, and internal auditors. The researchers expected to find mature quantitative risk management in at least some of the organizations they studied, but instead found that many supposedly quantitative approaches still depended heavily on qualitative judgment. 

The authors describe this as a “quantitative veneer”, where numbers create the appearance of rigorous measurement even though the assumptions underneath them remain subjective. Organizations may present risk scores, probability scales, technical metrics, or financial estimates, but the route from raw information to the final number is often far less precise than the result suggests. 

That tension becomes especially visible when organizations attempt to estimate likelihood and consequence. Historical cybersecurity data is limited, attack techniques change quickly, and even when comparable incidents exist, their relevance may fade as architectures, controls, and business dependencies evolve. The study also shows that the consequences of a cyber incident can include downtime, customer loss, reputational damage, legal exposure, regulatory costs, contractual penalties, and other effects that interact rather than add up neatly. 

A Precise Number Can Still Be an Estimate

The danger is not the number itself. Quantification can help leadership compare risks, prioritize investments, and communicate more clearly, but it becomes misleading when precision in presentation is mistaken for certainty in knowledge.

A loss estimate of several million dollars may be useful, yet it still depends on assumptions about the duration of disruption, the effectiveness of current controls, the systems affected, customer behavior, recovery time, and regulatory consequences. A risk score can organize discussion, but it should not end it.

For security leaders, the better question is not simply, “What is the number?” but, “How was this number built, what assumptions support it, and how much would the conclusion change if one of those assumptions moved?”

Rule 3: Data Needs a Human in the Room  

The same study introduces a useful concept for understanding what organizations are actually doing: qualculation – a combination of quantitative analysis and qualitative judgment. Rather than treating numbers and professional judgment as competing approaches, the researchers argue that cyber risk management often requires both because perfect quantification is rarely available.

This is especially important at executive level, where the decision is rarely about a single technical metric. A CISO may have vulnerability counts, patching rates, control maturity scores, threat intelligence, historical incident data, and financial information, yet leadership still has to decide what those signals mean for the organization’s current priorities.

Professional judgment fills the space between evidence and action, but that judgment should not remain invisible. If a recommendation depends on experience, assumptions, or expert interpretation, leadership should be able to see that clearly rather than receive a conclusion that appears mechanically produced.

Make the Reasoning Behind the Number Visible

If a CISO presents a ransomware exposure estimate, the board should understand more than the headline figure. It should know what probability was assumed, which controls were considered effective, what recovery time was used, which business processes were treated as critical, and whether indirect effects such as reputational or regulatory damage were included.

That does not make the decision less rigorous. In many cases, it makes the rigor more visible, because it reveals where the analysis ends and judgment begins.

The strongest decisions are not those in which judgment disappears. They are those in which judgment is explicit enough to be challenged.

Rule 4: Kick the Assumptions and See What Breaks  

Another research from 2025 focuses directly on uncertainty in cybersecurity decision-support models. Their starting point is that cybersecurity metrics, particularly estimates of security-control effectiveness, are inherently imprecise. 

Even a seemingly simple question such as whether a control is effective can be difficult to answer with confidence. A firewall that has never been breached may be highly effective, but it may also have avoided a sophisticated enough attack, while the absence of incidents does not automatically prove that the control will perform equally well against a different threat in the future. 

Instead of assuming one precise value for control effectiveness, the researchers model several possible scenarios and ask how different security decisions perform across them. One of the approaches they examine is minmax regret, which looks for a choice that minimizes how badly the organization could regret that decision if reality turns out differently from what was expected. They also develop a min-product approach designed to reduce risk more consistently across a range of scenarios.

The mathematics is not the most important lesson for executives. The more useful principle is that a security decision should not only be tested under the assumptions that make it look correct.

Ask What Happens When the Assumption Moves

A security investment may appear attractive when the expected control effectiveness is high, the estimated recovery time is short, and the supplier dependency is believed to be manageable. The decision becomes much more revealing when leaders ask what happens if one of those assumptions changes.

Would the investment still make sense if the control delivered only half the expected protection? Would the organization make the same prioritization if recovery took twice as long? Would a supplier still be considered acceptable if the business later discovered that several critical processes depended on it?

The point is not to invent endless worst-case scenarios until no decision feels safe. It is to understand whether the decision remains defensible across several plausible versions of reality rather than only under the one forecast that was used to justify it.

Rule 5: Give Executives Context, Not More Noise

The 2025 cyber risk management study also found a recurring gap between technical teams and senior leadership. Security and IT professionals often hold much deeper technical knowledge, while executives and boards depend on those teams to translate the meaning of that information into something that can support business decisions.

The problem is that more reporting does not automatically close that gap. The organizations in the study often provided leaders with information from different functions, using different metrics, methodologies, and levels of detail, which could make cyber risk reporting more complicated rather than more useful. Executives and boards were often more interested in forward-looking questions: what is changing in the threat landscape, what is happening to peers, and how prepared the organization would be if a similar event occurred.

The board does not need every vulnerability, every control metric, or every technical exception; it needs enough context to understand what those signals mean for the business, where the uncertainty lies, and what decision is actually being requested.

How CISOteria Makes the Mess Make Sense 

CISOteria does not try to eliminate uncertainty from cybersecurity decisions, because that would create exactly the kind of false confidence this post warns against. Instead, it helps make the information behind those decisions more connected, current, and easier to interpret. 

Instead of forcing CISOs to piece together risk, vulnerabilities, compliance, third-party exposure, remediation progress, incidents, and workplans from separate systems and spreadsheets, CISOteria brings them into one operational view. That makes it easier to see how technical findings connect to business impact, who owns the next action, what has changed, and where residual exposure remains. 

The platform also helps bridge the gap between technical evidence and executive decision-making. Current risk, compliance, third-party, and incident data can be translated into board-ready reporting, while risks and vulnerabilities can be connected to business context, priorities, treatment plans, ownership, and remediation progress. 

That does not make the underlying uncertainty disappear. It gives leaders a stronger basis for working with it: a more current picture of the cyber program, clearer connections between evidence and business impact, and less dependence on fragmented reporting that may already be outdated by the time a decision reaches the boardroom. 

Conclusion: The Goal Is Not Certainty 

Decision-making under uncertainty is not a sign that the organization lacks maturity; in cybersecurity, it is often the reality of making consequential choices before the evidence is complete. What matters is whether leaders can separate what is known from what is estimated, recognize where judgment is filling the gaps, and understand how much the decision depends on assumptions that may later prove wrong.

The three studies point in the same direction from different angles. Cybersecurity decisions are shaped by organizational context and human judgment, quantitative risk analysis can create an illusion of certainty when assumptions remain subjective, and stronger decisions are those that remain reasonable across several plausible scenarios rather than only one expected future.

The goal is not to predict the future perfectly, because cybersecurity rarely offers that luxury. It is to make a decision that can be explained, challenged, and revisited when the evidence changes, while remaining clear about why that decision was defensible with the information available at the time.

For Further Reading

This blog post is based on insights and analysis from:

  • Dawson, Niamh, et al. “Informed cybersecurity decisions: A synthesis of expert perspectives.” Computers & Security (2026): 104927. 

https://doi.org/10.1016/j.cose.2026.104927 

  • Zhang, Yunxiao, and Pasquale Malacaria. “Dealing with uncertainty in cybersecurity decision support.” Computers & Security 148 (2025): 104153. 

https://doi.org/10.1016/j.cose.2024.104153 

  • Slapničar, Sergeja, Micheal Axelsen, and Marc Eulerich. “Cyber risk management: an illusion of a risk-based approach.” Journal of Management Control (2025): 1-36. 

https://doi.org/10.1007/s00187-025-00401-z 

Cybersecurity Risk Ownership: Why Security Shouldn’t Own Every Risk

Posted on by CISOteria

 The Problem with “Security Owns Security”

Security ownership is often concentrated in the security team, even when the decisions creating cyber risk are made elsewhere in the business.

In many organizations, the security function defines the controls, identifies the risks, monitors threats, responds to incidents, pushes remediation, and explains what went wrong when something fails. On paper, the business may be expected to support security. In practice, accountability often stays concentrated with the CISO and the security team.

The problem is that this concentration of accountability does not reflect how cyber risk is actually created across the organization. The security team can own the security program, but it cannot own every business decision that creates cyber risk. 

Panteli, Nthubu, and Mersinas describe cybersecurity as a collective responsibility that spans multiple stakeholders rather than a technical problem that should remain in the hands of cybersecurity professionals. Their research emphasizes shared responsibility, leadership involvement, and organizational collaboration.

The gap appears when organizations agree with that principle in theory, but continue to behave as if security is responsible for every outcome.

The Alarm Bell Doesn’t Own the Fire

The security team has a clear role: it defines standards, provides expertise, assesses exposure, monitors controls, challenges decisions, and helps the organization understand the consequences of risk.

But many of the decisions that create cyber risk happen elsewhere.

A procurement team selects a supplier. A product team postpones remediation to meet a release date. An operations team continues using a legacy system because replacement is too expensive. A business unit requests an exception because a control creates friction.

These are business decisions with security consequences.

If the security team identifies the risk but the business decides to proceed, the risk should not automatically become “owned” by security.

The distinction matters because responsibility in cybersecurity includes involvement, agency, and ownership across the organization, not only within the security function.

Everyone’s Favorite Place to Dump Risk 

The problem often starts with unclear accountability.

A vulnerability exists, so security owns it. A supplier has weak controls, so security owns it. A project cannot meet a requirement, so security owns the exception. A business unit accepts exposure, but security is still expected to explain the outcome later.

Over time, the CISO becomes the default owner for risks that originate in business decisions.

That may simplify escalation, but it weakens governance.

The security team should make the risk visible, explain the impact, recommend controls, and challenge weak decisions. It should not automatically absorb accountability for decisions made by other functions.

Business Leaders Still Own the Decision

Chatterjee and Leslie argue for a whole-of-enterprise approach to cybersecurity preparedness, built on the idea that cybersecurity readiness is everybody’s business. One of the core characteristics they identify is getting ownership, responsibility, and accountability right.

That does not mean everyone owns everything.

It means ownership needs to be assigned at the right level.

Security Owns the Security Capability

The security team should own the mechanisms that help the organization manage cyber risk.

That includes frameworks, policies, standards, monitoring, assurance, threat expertise, and security guidance.

The Business Owns Business Risk Decisions

Business leaders should own decisions about priorities, budgets, operational trade-offs, supplier choices, product deadlines, and risk acceptance.

When those decisions increase cyber exposure, accountability should remain with the decision-maker.

Leadership Owns the Governance Model

Senior management and the board need to ensure that risk ownership is explicit, escalation paths are clear, and accepted risks are visible.

Chatterjee and Leslie note that cybersecurity was historically treated as a technical issue for technical people, but that boards and executives are increasingly expected to play a direct role in driving security outcomes.

They also emphasize the role of senior management in building a shared understanding of cyber risk and empowering security experts with the mandate and resources required to respond.

Accountability on Paper Is Still Just Paper 

Organizations can assign accountability on paper and still fail to create it in practice.

A policy may state that business owners are responsible for cyber risk. A RACI matrix (Responsible, Accountable, Consulted, and Informed) may assign ownership. A committee may review risk decisions.

But if every difficult decision is still pushed back to security, the governance model has not really changed.

Gao and Calderon found that effective board oversight and cybersecurity expertise are associated with stronger cybersecurity risk disclosures, while the effect weakens when oversight becomes symbolic.

They also highlight the risk of superficial, check-the-box oversight when governance lacks sufficient expertise or meaningful involvement.

The same principle applies below board level. Accountability has to exist in actual decision-making, not only in governance documents.

Risk Acceptance Needs a Real Owner

One of the clearest places to see the ownership gap is risk acceptance.

Security may identify that a control is missing or that exposure exceeds the preferred level. But if remediation requires budget, delays a launch, affects a supplier relationship, or changes a business process, the final decision belongs to the relevant business owner.

Security can recommend, challenge, or escalate. But if the business chooses to accept the risk, that acceptance should be explicit and traceable.

Otherwise, organizations create a situation where the business receives the benefit of the decision while the security team retains the accountability.

Shared Responsibility Needs Clear Boundaries

“Security is everyone’s responsibility” is useful as a cultural message, but it is too vague as a governance model.

Shared responsibility works only when the boundaries are clear. Employees need to understand what is expected from them. Business owners need to know which risks they own. Security needs authority to challenge and escalate. Executives need visibility into material risk acceptance.

The goal is not to spread accountability so widely that nobody clearly owns anything.

It is to place accountability where the relevant decisions are actually made.

Conclusion: Security Should Not Own Every Risk

The security team should own the security program, the expertise behind it, and the mechanisms used to identify and manage cyber risk.

That does not mean it should own every cyber risk across the organization.

Research increasingly supports a broader model in which cybersecurity depends on participation across business functions, leadership, and governance structures rather than remaining solely with cybersecurity specialists.
The CISO should make risk visible and help the organization manage it.

The business should remain accountable for the decisions that create or accept it.

For Further Reading

This blog post is based on insights and analysis from:

  • Chatterjee, Dave, and Anne Leslie. “Ignorance is not bliss: A human-centered whole-of-enterprise approach to cybersecurity preparedness.” Business Horizons (2024). 

https://doi.org/10.1016/j.bushor.2024.10.009 

  • Gao, Lei, and Thomas G. Calderon. “Cybersecurity risk governance and companies’ cybersecurity risk disclosures in their 10-K filings.” Journal of Accounting and Public Policy 54 (2025): 107376. 

https://doi.org/10.1016/j.jaccpubpol.2025.107376 

  • Panteli, Niki, Boineelo R. Nthubu, and Konstantinos Mersinas. “Being responsible in cybersecurity: A multi-layered perspective.” Information Systems Frontiers 28.1 (2026): 209-227. 

https://doi.org/10.1007/s10796-025-10588-0 

Regulatory Change Management: Build Once, Map Many

Posted on by CISOteria

 Why Regulatory Change Creates So Much Rework 

Regulatory change management becomes difficult when security frameworks are built to mirror regulations too closely. Security frameworks are built over years. Regulations are not. 

A new regulation, amendment, supervisory expectation, or reporting obligation can introduce requirements much faster than an organization can redesign its security program. If the framework was built too closely around the wording of a particular regulation, even a relatively small regulatory change can trigger a disproportionate amount of work: controls need to be rewritten, policies updated, evidence requirements reconsidered, and teams asked to implement processes that may already exist elsewhere. 

A mature security framework should be able to absorb regulatory change without being rebuilt from zero. The goal is to maintain a stable set of security controls, policies, and processes while allowing regulatory requirements to be added, removed, or modified through a separate mapping layer. 

Recent research supports this direction. Canavese et al. examine five overlapping EU regulatory instruments and argue that treating them as isolated regimes creates unnecessary complexity. Their compliance-by-design approach instead looks at how obligations intersect and how overlapping requirements can be satisfied without duplication.

The practical question for CISOs is therefore not simply: Are we compliant with the regulation today?

It is: If the regulation changes tomorrow, how much of our security framework will we have to rebuild?

 

What Is Regulatory Change Management?

Regulatory change management is the ongoing process of identifying new or amended requirements, assessing their impact, and updating the controls, policies, processes and evidence they affect. In cybersecurity, the aim is to maintain compliance as requirements evolve without duplicating work or destabilising the underlying security programme.

 

Principle 1: Build Around Security Objectives, Not Regulatory Clauses

One of the easiest ways to create future compliance work is to structure the security framework as a mirror of a particular regulation. 

A regulation says organizations must manage vulnerabilities, so a regulation-specific vulnerability control is created. Another regulation introduces a similar requirement, so another control is added. A third framework addresses the same underlying security objective using slightly different terminology, creating yet another policy, assessment, or evidence request. 

Over time, the organization may end up managing several compliance structures that describe largely the same security activities. 

This becomes increasingly difficult as regulations overlap. Canavese et al. note that legal acts may have overlapping scopes but different thresholds, procedures, and timelines, including in areas such as vulnerability management and reporting. Managing several regulations concurrently therefore increases day-to-day operational complexity. 

A more resilient model separates the security requirement from the regulatory requirement. 

For example, the organization may maintain one internal control for vulnerability management that defines: 

  • ownership and responsibilities;
  • vulnerability identification;
  • risk-based prioritization;
  • remediation expectations;
  • exception handling;
  • reporting;
  • evidence requirements.

Different regulatory requirements can then be mapped to that same control. 

The internal control remains relatively stable. The regulatory mappings are designed to change.

Different regulations often converge on similar security outcomes. In their cross-regulatory analysis, Canavese et al. explicitly focus on translating legal requirements into actionable artifacts such as security controls, architectural constraints, and organizational processes.

Instead of building a new security program every time another regulation becomes applicable, the organization can first ask: Which parts of this requirement are already covered by our existing controls?

Only the remaining gap should create new work.

Principle 2: Map Requirements to Reusable Controls  

For this model to work, the relationship between controls and regulatory requirements cannot live only in someone’s spreadsheet or institutional knowledge.

It needs to be explicit.

Trace Requirements to Controls 

Akinsanya’s 2025 security-by-design framework includes a dedicated compliance mapping component designed to connect security controls with regulatory requirements. The model emphasizes bidirectional traceability, allowing an organization to see both which regulatory requirements a control supports and which controls support a particular requirement.

That traceability becomes particularly important when regulation changes.

Follow the Change Path 

Consider an organization with an existing incident-response control. A new regulatory amendment introduces a shorter reporting deadline.

If the relationship between the regulation, control, policy, procedure, and evidence is already mapped, the organization can identify exactly where a regulatory change has an impact without reviewing the entire cybersecurity framework. It can trace the changed requirement to the relevant control, then to the affected policy or procedure, and finally to the evidence that may need to be updated. 

Perhaps the incident-response process, roles, escalation paths, and testing remain valid. Only the notification timeline and the procedures or evidence connected to it need to change.

Without that traceability, even a small regulatory amendment can become an organization-wide discovery exercise.

Principle 3: Assess the Regulatory Delta 

The objective of regulatory change management should therefore be to identify the delta: what has actually changed between the organization’s current framework and the new requirement. 

That sounds simple, but it requires the framework to be designed for it.

Controls should be sufficiently modular that one requirement can change without forcing unrelated parts of the framework to change with it. Policies should describe durable organizational principles rather than copy regulatory language unnecessarily. Regulatory references should be maintained separately from the operational logic of the control.

The same principle applies across multiple regulations.

Canavese et al. argue for viewing cybersecurity legislation as an interconnected system rather than a collection of independent regimes. Their analysis specifically considers how overlapping obligations can be addressed in ways that avoid duplication.

What Actually Needs to Change? 

For CISOs, the practical implication is significant. When a new regulation appears, the first task should not be to build a new framework. It should be to map the new requirements against the framework that already exists.

The result will usually fall into three groups:

  1. Already covered.
    The existing control and supporting policy already satisfy the requirement.
  2. Partially covered.
    The existing control is relevant, but a parameter, procedure, evidence requirement, or scope needs to change.
  3. Not covered.
    The regulation introduces a genuinely new obligation that requires a new or substantially expanded control.

Only the third category should normally require additional control design or implementation. 

Keep the Security Core Stable 

There is another reason to avoid designing the framework directly around regulatory clauses: compliance and security do not change at the same speed.

Akinsanya argues that traditional compliance-centric approaches can prioritize retrospective audits over proactive risk mitigation and describes the need to bridge regulatory requirements with actionable security practices.

The proposed framework addresses this by combining compliance mapping with continuous validation and adaptive governance. Findings such as compliance gaps, vulnerabilities, and incident data are fed back into governance decisions so that policies and controls can be updated as both threats and regulatory requirements evolve.

That adaptability becomes critical when regulatory requirements change.

A regulatory update may require the organization to change how quickly it reports an incident, how long it retains particular evidence, who approves a decision, or how a control is documented.

Those changes should be possible without destabilizing the underlying security program.

The security architecture should provide continuity. The regulatory layer should provide adaptability.

Build Once, Map Many: How CISOteria Supports Regulatory Change Management 

CISOteria is built around a shared compliance structure rather than treating every framework as a separate project.

Controls are mapped across multiple frameworks, so the same control does not need to be assessed and managed again for every regulation. This creates a common control layer that can continue to support the security program even as regulatory requirements change.

Policies are connected to those frameworks and controls as well. When a regulatory requirement changes, CISOteria’s Cyber OS can surface the policies affected by that change, helping teams identify where an update is actually required instead of reviewing the entire policy library.

The same structure keeps evidence connected to the relevant controls and maintained continuously. This creates a clear path from regulatory change to the specific areas that require attention. 

Instead of reviewing the entire compliance program, teams can see where action is needed, what must be updated or completed, and which existing controls and policies remain valid.

Conclusion: Build for Change

Regulatory change should not force organizations to rebuild their security programs from the ground up.

The more resilient approach is to maintain a stable control framework, map regulatory requirements to it, and treat each change as a gap-analysis exercise. Existing controls, policies, and processes should remain in place where they still satisfy the requirement, while updates are limited to the areas where expectations have genuinely changed.

For CISOs, this keeps compliance connected to security rather than allowing every new requirement to create another isolated layer of work. The goal is not simply to comply with the regulation that exists today, but to build a framework capable of adapting to the one that comes next.

For Further Reading

This blog post is based on insights and analysis from:

  • Akinsanya, Ayokunle. “Security by design: a risk-based framework for cybersecurity compliance and critical infrastructure protection.” International Journal of Information Security 24.6 (2025): 234. 

https://doi.org/10.1007/s10207-025-01155-4   

  • Canavese, Daniele, et al. “Uncovering challenges of cybersecurity cross-regulation in EU legislation.” Information and Software Technology (2026): 108033. 

https://doi.org/10.1016/j.infsof.2026.108033  

Technical Debt Is Cyber Risk in Disguise

Posted on by CISOteria

Technical Debt, Cybersecurity, and Software Vulnerabilities 

Technical debt rarely announces itself as a security problem.

It usually appears as something more familiar: an old system that still works, a temporary integration that became permanent, code that nobody wants to touch, documentation that was never completed, or an upgrade that keeps moving to the next quarter.

Individually, these decisions may look reasonable. The problem is what happens when those decisions accumulate.

Technical debt is commonly described as the cost created when organizations prioritize short-term objectives over longer-term technical quality. Recent research defines it in terms of delayed technical work and poor solutions adopted to achieve immediate objectives, with additional effort appearing later as the “interest” on those decisions.

For CISOs, that interest can include cyber risk.

When Technical Debt Becomes a Security Problem: “Old but Gold” Doesn’t Work Anymore

Legacy technology often survives for a good reason: reliability, integration into business processes, individual applications, familiarity.  All these make replacement difficult.

Research describes technical debt as accumulated maintenance obligations originating in shortcuts and temporary solutions. As systems evolve, that debt can consume increasing amounts of the IT budget, leaving fewer resources available to resolve the underlying problem. Debt can accumulate through obsolete software, poorly designed code, undocumented system changes, excessive customization, and the integration of new systems into obsolete architecture. Over time, dependencies become harder to identify and increasingly expensive and risky to change.

A legacy system does not become a cyber risk simply because it is old. The risk comes from what has accumulated around it: unsupported components, architectural dependencies, difficult updates, missing knowledge, fragile integrations, and the growing operational cost of making changes safely.

Eventually, the organization may know that something should be fixed while becoming progressively less able to fix it.

How Technical Debt Increases Cybersecurity Risk

Technical debt often begins with a tradeoff: accepting an imperfect implementation to meet a launch deadline, keeping an existing dependency to avoid delays, or deferring refactoring because the code still works. 

Those decisions can be rational at the time.

The problem is allowing a temporary compromise to become an unmanaged permanent condition.

Asatiani and colleagues describe how technical debt can increase architectural rigidity, reduce development efficiency, and create additional maintenance obligations. They argue that the issue becomes self-reinforcing: resources are increasingly consumed maintaining debt-heavy environments, while fewer resources remain available to reduce the debt itself.

From a security perspective, the important question is therefore not whether an organization has technical debt. Almost every mature environment does.

The question is which debt is beginning to affect the organization’s ability to secure, update, understand, or change its systems.

Where Technical Debt Meets Software Vulnerability 

Technical debt is often discussed as a software-quality or maintenance problem. Recent empirical research gives CISOs another reason to pay attention.

A 2025 IEEE Access study examined real-world code and vulnerability data from six software projects. The researchers analyzed technical-debt indicators including code smells, bugs, software metrics, and refactoring activity and found a significant association between technical debt and software vulnerabilities.

The results are especially important because the study looked at actual vulnerable code changes rather than treating technical debt only as an abstract engineering concept.

Code smells were particularly informative. The researchers found that including code-smell information improved vulnerability-prediction models and concluded that code smells were strong indicators of security risk in their dataset.

That means the separation between technical quality and cybersecurity is weaker than organizations sometimes assume. Poor design choices, accumulated complexity, bugs, and unresolved technical weaknesses can create conditions in which vulnerabilities become more likely or more difficult to detect and remediate.

For a CISO, that makes technical debt relevant to risk prioritization.

Cyber Risk Can Hide Inside the IT Backlog

Most organizations already track some components of technical debt.

They may appear in engineering tickets, modernization programs, architecture reviews, patching queues, end-of-life inventories, exception registers, or infrastructure roadmaps.

The problem is that these records are often viewed independently, with each issue assigned to a different team. 

Taken separately, none may appear critical. Taken together, they may describe an environment that is becoming increasingly difficult to secure.

This is where the CISO has a different role to play.

The objective should not be to move every technical-debt item into the cyber risk register. That would create another backlog rather than improve decision-making.

Instead, CISOs should identify the debt that changes security exposure.

That includes asking whether a technical limitation prevents timely remediation, increases dependence on unsupported technology, makes security changes unusually risky, reduces visibility into system behavior, or creates dependencies that could expand the impact of a compromise.

Technical debt becomes particularly relevant when it begins restricting the organization’s security options.

Managing Technical Debt as a Cyber Risk 

Some Debt Is Worth Carrying 

Technical debt is not inherently evidence of poor management.

Sometimes accepting debt is the right business decision.

A company may deliberately postpone modernization because replacing a stable critical system creates more operational risk than continuing to use it. A development team may accept a temporary architectural compromise to deliver an urgent capability.

The important distinction is whether the debt is known, understood, and governed.

The Green Cargo case illustrates why simply attempting to replace legacy systems in one large transformation can fail. The research instead recommends understanding the origins and extent of technical debt, connecting it to business priorities, and gradually reducing legacy dependencies rather than assuming that a single “big bang” replacement will solve the problem.

Their managerial recommendations also emphasize prioritizing debt according to the capabilities it constrains and creating closer collaboration between IT and business functions.

For cybersecurity, the same principle applies.

A CISO does not need a technical-debt-free organization.

The CISO needs visibility into the debt that materially changes risk.

From Inherited Debt to Deliberate Risk

Technical debt becomes dangerous when nobody is explicitly deciding to keep it.

An unsupported component remains because migration is complicated. A workaround survives because replacing it has never reached the top of the roadmap. A fragile application continues running because the people who understand it are focused elsewhere.

The organization may technically know about every individual issue while still failing to see the accumulated exposure.

CISOs can change that by connecting technical debt to the same questions used for other forms of cyber risk.

  • What business process depends on the system?
  • What security capability is constrained by the debt?
  • What happens if remediation is required urgently?
  • How difficult would it be to patch, isolate, replace, or recover the component?
  • Which dependencies make a seemingly local problem larger?
  • And what is the organization consciously accepting by postponing action again?

The answer may still be to defer the work, but then it becomes a risk decision rather than an invisible inheritance from an earlier technical decision.

Conclusion: The Debt Eventually Comes Due 

Technical debt is created gradually.

A temporary solution stays in production. A legacy system remains because replacement is difficult. Complex dependencies make the next change more expensive. Maintenance consumes resources that could otherwise improve the environment.

Eventually, the organization is no longer dealing with one old decision. It is dealing with the accumulated consequences of many of them.

Recent research gives CISOs good reason to treat that accumulation seriously. Technical debt can constrain modernization and organizational agility, while empirical evidence also links technical-debt indicators with software vulnerabilities.
The goal is therefore not to eliminate every shortcut or replace every legacy system.

It is to know where the debt is, understand what security options it limits, and decide which debt the organization can continue carrying.

Because once technical debt begins limiting the ability to secure the environment, it is no longer just an IT backlog.

It is cyber risk.

For Further Reading

This blog post is based on insights and analysis from:

  • Asatiani, Aleksandre, et al. “Technical debt is killing digital transformation, but there is a way out.” California Management Review 68.1 (2025): 55-75. 

https://doi.org/10.1177/00081256251370795  

  • Halepmollasi, Rusen Akkus, and Ayse Tosun. “Predicting Vulnerable Code Changes Using Technical Debt Indicators.” IEEE Access (2025).
    https://doi.org/10.1109/ACCESS.2025.3602480  

Cyber Crisis Communication: What to Say While an Incident Is Still Unfolding

Posted on by CISOteria

Cyber Crisis Communication Starts Before You Have All the Answers

In one of our previous discussions on post-incident recovery, we looked at the role communication plays after the immediate crisis begins to ease. Even when systems are restored, customers, employees, partners, regulators, and the board may still need explanations, evidence of corrective action, and reasons to believe the organization has regained control.

But communication does not begin when the incident ends.

Cyber crisis communication begins before the investigation is complete. While security teams are still containing the incident and establishing the facts, executives, employees, customers, and regulators may already need answers. 

At that stage, the forensic investigation may still be incomplete. The scope may change. Some information may be too sensitive to share. Different stakeholders may need different answers, and every statement the organization makes can affect what happens next. 

The organization is therefore expected to communicate at exactly the moment when certainty is lowest. 

This is where crisis communication differs from post-incident trust repair. The immediate challenge is to keep people informed while containment, investigation, recovery, and sometimes negotiations with the attacker are still underway.

Recent research identifies this as one of the characteristics that makes cyber crisis communication different from more traditional crisis communication. In many crises, communication follows the disruptive event. In a cyber incident, communication frequently happens while forensic investigation and operational response are still in progress.

A public statement can affect a ransomware negotiation. Information shared internally may reach an attacker. In a third-party breach, an organization may depend on another company’s investigation before it can answer its own customers. 

For CISOs, the challenge begins before the full picture is available: how do you communicate while the incident is still unfolding?

Communication Is Part of Cyber Incident Response

Cyber incident response is often described through technical activities such as detection, analysis, containment, eradication, and recovery.

Communication runs through the same process.

A 2025 study on cybersecurity crisis communication argues that organizations need structured communication protocols throughout the incident lifecycle rather than ad hoc messaging. Its proposed model integrates communication into notification and escalation, analysis and response, external stakeholder communication, and post-incident review. 

Poor communication can make an already difficult incident harder to manage. Different teams may work from different versions of the situation. Executives may receive information that has already changed. Customer service may answer questions before an agreed position exists. Employees may learn developments through the media. Legal, security, communications, and management may each apply a different standard when deciding what can safely be shared. 

The result is fragmentation at exactly the moment when the organization needs a common understanding of what is happening.

The same 2025 research emphasizes predefined roles, escalation paths, communication responsibilities, and structured information sharing across technical, legal, management, and public relations teams. 

Knowing who communicates is therefore only the first step. The harder decision is determining what can responsibly be said while the facts are still changing.

The Goal Is Clarity Under Uncertainty

In the early hours of a serious cyber incident, the organization may still have only a partial picture. Even so, waiting to communicate may not be practical. 

The organization should clearly separate confirmed facts from information that is still uncertain. A useful update can explain what has been confirmed so far, what the investigation is still examining, what actions are already underway, which groups appear to be affected based on current evidence, and when more information is expected. 

The 2026 study supports this approach by highlighting the value of communicating what is known, what remains under review, and what is still unclear. 

This allows the organization to provide useful information without presenting an incomplete forensic picture as a final conclusion.

Build a Cyber Crisis Communication Plan Before You Need It

The worst time to decide how cyber crisis communication works is when the incident is already unfolding.

By then, information is changing quickly. Technical teams are focused on containment. Legal teams may be assessing reporting obligations. Executives want answers. Employees and customers may already be asking questions.

A communication plan therefore needs to define the process rather than predict the exact wording of a future statement.

The 2025 research emphasizes predefined roles, escalation paths, communication channels, stakeholder engagement, and coordination between security, management, legal, and communications functions. The 2026 research goes further, arguing that communication should remain closely connected to forensic and operational work because communication decisions can directly affect negotiations, investigations, and containment. 

For CISOs, preparation means establishing how technical information reaches decision-makers, how uncertainty is communicated, how earlier statements are updated, how alternative channels are activated when normal systems fail, and how critical suppliers are expected to share information during an incident. 

The aim is to reduce improvisation when pressure is highest and keep communication connected to the live response. 

CISOteria can support this process by keeping risks, responsibilities, decisions, and follow-up actions connected in one operational view. This gives security leaders a clearer picture of what is known, who owns the next step, and which stakeholders need to be involved as the incident develops.

One Incident Does Not Mean One Message

A cyber incident rarely has a single audience. 

The 2025 research identifies audience adaptation as an important part of structured cyber crisis communication. Technical teams, executives, regulators, customers, and the media have different information needs, requiring messages to be adapted to each audience to reduce the risk of misunderstanding. 

Employees Need Direction

Internal communication becomes especially important when the incident begins affecting daily operations.

Employees may lose access to systems, remote work tools, shared files, or normal communication channels. They may also receive questions from customers, partners, or other external contacts before the organization has published a broader update.

The 2026 study describes employees as both affected participants and important parts of the wider information environment. What they understand, what they repeat, and how they respond to questions can influence the course of the incident.

Internal communication should therefore focus on practical direction. Employees need to understand which systems are safe to use, which alternative channels have been approved, where questions should be directed, and what information should remain restricted.

Executives Need Decision-Relevant Information

Executives have a different information need.

They usually do not need every forensic artifact or technical hypothesis. They need enough reliable information to understand the business consequences and make decisions while the investigation continues.

The CISO therefore has to translate a changing technical picture into decision-relevant information. That may include the operational impact, possible exposure of customer data, regulatory implications, dependencies on third parties, the status of recovery, and any communication decision that could affect the investigation or negotiations.

The Attacker May Be Listening Too

Cyber incident communication must account for the possibility that threat actors are monitoring what the organization says publicly – and potentially internally.

The 2026 research repeatedly notes that threat actors may monitor public communication and, depending on their level of access, may also be able to observe internal communication.

External communication can unintentionally reveal useful details to the attacker. A statement may expose information about disruption, recovery progress, priorities, or the organization’s negotiating position. 

Organizations should therefore consider the operational impact of a message before publishing it. 

Cyber Crisis Communication Depends on the Type of Incident

Cyber crisis communication does not follow one fixed template. The right approach depends on the type of incident and the operational risks created by disclosure. The 2026 research highlights several important differences: 

  • Ransomware: Communication may affect negotiations, reveal the scale of disruption, or expose recovery capabilities. Organizations need to keep stakeholders informed while preserving enough flexibility to adapt as the incident develops.
  • Third-party compromise: The organization may need to communicate with its own customers while depending on the compromised supplier for forensic information. Clear pre-incident agreements on information sharing, update timing, and external communication can reduce delays and confusion.
  • Nation-state espionage: Broad communication may compromise an ongoing investigation or alert an attacker who is still active. Early communication may therefore need to remain limited to a small need-to-know group, sometimes through alternative channels.

The key point is that timing, transparency, and the level of detail should reflect the operational context of the incident. In some cases, faster communication is necessary. In others, restraint protects the response. 

Message Framing Comes After Evidence

Once the organization has established what it can responsibly confirm, it still has to decide how to explain the incident. 

Research presented at ECIS 2025 examined 7,941 U.S. data breach disclosures and found that organizations rarely rely on a single response strategy. The researchers identified 18 distinct combinations, including approaches such as compensation, apology, justification, excuses, and presenting the organization as a victim of the attack. 

These choices shape how the organization explains responsibility and responds to those affected. 

For CISOs, however, the factual foundation needs to come first. The organization may want to reassure customers or explain the actions already taken, but the message should remain within the boundaries of what the investigation can support. 

Conclusion: Communicate With the Incident as It Develops

Cyber crisis communication takes place while the facts are still developing.

Security teams may still be investigating while executives, employees, customers, partners, and regulators already need information. The organization therefore needs a communication process that can evolve with the incident.

That means keeping messages aligned with the current evidence, adapting information to the needs of different audiences, and considering how disclosure could affect the operational response.

This is what separates crisis communication from post-incident trust repair. Post-incident communication addresses what happens after the immediate crisis. Crisis communication helps the organization navigate the period when the outcome is still uncertain.

A mature incident response plan should therefore define how communication works before the first urgent request for an answer arrives.

For Further Reading

This blog post is based on insights and analysis from:

  • Covarrubias, Jersain Zadamig Llamas. “Effective communication as a pillar of cybersecurity: Managing incidents and crises in the digital era.” Journal of Risk Analysis and Crisis Response 15.2 (2025): 34-34.
    https://doi.org/10.54560/jracr.v15i2.564 
  • Jechle, Deinera, Sebastian Schuetz, and Heiko Gewald. “Decoding Data Breach Response Strategies: Insights from Situational Crisis Communication Theory using Topic Modeling.” ECIS. 2025. 

https://www.researchgate.net/publication/393568155_Decoding_Data_Breach_Response_Strategies_Insights_from_Situational_Crisis_Communication_Theory_using_Topic_Modelling 

  • Jong, Wouter, Kelly Mikelatou, and Marcel Vielvoije. “When Crisis Communication Meets Forensics: Managing Narratives in Ransomware, Third-Party, and Nation-State Attacks.” Computers & Security (2026): 105082. 

https://doi.org/10.1016/j.cose.2026.105082 

The Board Is Asking Cybersecurity Questions. But Can It Judge the Answers?

Posted on by CISOteria

The Board Has the Answers. Does It Understand Them?

A board can review every cybersecurity report, ask every recommended question, approve more investment, and still fail to govern cyber risk properly.

Cybersecurity has quietly changed the job description of the board, not because directors are expected to understand malware, analyse attack techniques, or debate the merits of competing security technologies, but because cyber incidents increasingly determine whether an organisation can continue operating, comply with regulatory obligations, preserve stakeholder trust, and execute its strategy. 

The discussion has therefore moved from technology to governance. This raises an uncomfortable question that many boards still need to answer: what does real accountability for cybersecurity look like?

For years, the answer seemed simple. Cybersecurity became a regular board topic, the CISO gave quarterly updates, dashboards became more detailed, and directors approved more spending or asked for independent reviews. From the outside, this looked like strong governance.

Recent academic research suggests that the reality is more complicated.

When Oversight Becomes Theatre 

A Full Agenda Is Not Proof of Governance 

One of the most important findings from recent research is not simply that boards struggle with cybersecurity. It is that many directors believe they are providing effective oversight, while cybersecurity specialists looking at the same process disagree.

The researchers interviewed directors, cybersecurity executives, and senior consultants, while also reviewing 1,000 firms from the Russell 3000. Only 14.7% reported having at least one director with cybersecurity or closely related expertise. More than half of the non-expert directors interviewed believed that specific cybersecurity expertise was not necessary for effective oversight, while none of the expert directors agreed.

The difference was not about effort. Non-expert directors attended meetings, reviewed reports, completed training, and asked questions just as expert directors did. The problem was that these activities could still remain symbolic if directors did not have enough knowledge to understand which information was truly reassuring and which information should change the board’s view of risk.

Governance is not measured by how many meetings are held or how many reports are reviewed. It is measured by whether directors can challenge assumptions, influence important decisions, and recognise when positive metrics hide serious weaknesses.

The researchers describe this as the difference between symbolic and substantive oversight. Symbolic oversight looks like governance. Substantive oversight improves the decisions that follow.

More Dashboards, Same Blind Spot 

Reports Still Need Context

The natural response to weak oversight is often to give directors more information: more dashboards, more indicators, more reports, and more external reviews.

But the problem is often not a lack of information. It is a lack of context, interpretation, and challenge.

A lower number of critical vulnerabilities may mean security has improved, but it may also mean the organisation changed how it measures them or reduced the scope of its scanning. High compliance scores may show that processes are being followed, but they may say very little about whether the organisation can continue operating during an attack. A positive assurance report may confirm that a review took place without showing whether it covered the systems, suppliers, and dependencies that matter most.

Without context, information can create confidence instead of understanding.

The information gap may also be larger than boards realise. In a supporting survey, CISOs estimated that the median share of peers who filtered reports to make themselves or their managers look better was 40%. The study does not prove that 40% of board reports are false, but it does show that experienced security leaders see selective reporting as a real governance risk.

A board without enough expertise may not notice when information has been softened, simplified, or framed to highlight progress. More importantly, it may not realise that there is anything to notice.

Monitoring Does Not Mean Governing 

Another study offers a useful way to think about this issue. Instead of treating oversight as a regular reporting task, the authors argue that boards should approach cybersecurity as an ongoing process of strategic sensemaking.

They describe three activities: scanning, interpretation, and action. These should continue before an incident, during an attack, and throughout recovery.

The board’s role is not to manage cybersecurity operations. It is to make sure the organisation keeps identifying important risks, understands what they mean for the business, and makes decisions that improve long-term resilience.

Accountability Starts Before the Incident

Governance failures often begin long before a cyber incident reaches the boardroom.

They begin when ownership of important risks is unclear, when business leaders assume cybersecurity belongs only to the security team, when supplier risk is reviewed separately from business continuity, or when management’s confidence is not supported by evidence the board can examine.

By the time an incident happens, many of the decisions that shape its impact have already been made. The organisation has already decided which systems are most important, which risks it will accept, which remediation deadlines can move, and which recovery capabilities deserve funding.

Strategic oversight therefore starts with clear ownership, clear decision rights, reliable evidence, and a direct link between cyber risk and business priorities.

The Questions Have Changed

For many years, boards asked whether the organisation had the right controls, whether regulatory duties had been met, or whether audits had found serious weaknesses. Those questions still matter, but they are no longer enough.

A stronger governance discussion asks whether the board understands which cyber risks could affect the organisation’s strategy, who owns those risks outside the security team, what evidence supports management’s confidence, and how directors would know if their current view of risk was no longer correct.

These questions are harder because they do not only ask for information. They ask for understanding.

Smart Directors Can Still Ask the Wrong Questions 

The study does not say that every board must appoint a former CISO. It does show that boards without real cybersecurity knowledge face a greater risk of confusing visible governance activity with effective oversight.

Directors with cybersecurity expertise are more likely to notice gaps, challenge assumptions, test reports, and separate technical detail from business impact. Their value is not mainly in explaining technology. It is in improving the board’s judgement.

One of the most important findings is that directors without cybersecurity expertise often do not realise that their oversight may lack depth. This creates a serious blind spot because boards cannot easily fix a weakness they do not recognise.

That does not mean one expert should carry the responsibility for the whole board. All directors still need to understand how cyber risk affects strategy, operations, finance, compliance, and trust. Expertise should improve the board’s work, not replace shared responsibility.

If Everyone Owns Cyber Risk, No One Does

Both studies point to the same basic issue: effective cybersecurity governance depends on visibility.

Directors need to know who owns important risks, how decisions are made, what evidence supports management’s confidence, which dependencies affect resilience, and how risk is changing across the organisation. Without that visibility, accountability is difficult to test or prove, even when everyone is acting in good faith.

Technology cannot create board accountability, but it can make accountability easier to see, challenge, and support with evidence.

This is where a governance platform can help. Its value is not in creating another separate dashboard, but in connecting risks, ownership, controls, evidence, compliance duties, and third-party relationships in one place.

Conclusion

The Board Will Be Judged by What It Can Prove 

Regulators, investors, customers, and executive teams increasingly expect boards to show not only that cybersecurity appears on the agenda, but that directors understand how cyber risk is governed, challenged, and connected to strategy.

That expectation cannot be met through reporting alone. It requires boards that are willing to question their own assumptions, organisations that can prove accountability instead of only describing it, and governance processes that turn cybersecurity from a technical issue into a business decision.

The boards that govern cyber risk well will not necessarily be those that receive the most information. They will be those that can challenge what they are told, recognise what is missing, and connect cyber risk to the decisions that shape the organisation’s future.

For Further Reading

This blog post is based on insights and analysis from:

  • Lowry, Michelle R., Anthony Vance, and Marshall D. Vance. “Inexpert supervision: Field evidence on boards’ oversight of cybersecurity.” Management Science 72.2 (2026): 783-804. https://doi.org/10.1287/mnsc.2023.0414

The Policy Says One Thing. The Organisation Does Another. Why?

Posted on by CISOteria

Approved on Paper. Ignored in Practice

Most organisations already have security policies.

They explain how employees should handle data, approve access, share files, use devices, and report incidents. On paper, the rules are clear. Responsibilities are assigned, controls are documented, and the organisation can point to a formal process.

Then the policy meets daily work.

An employee cannot complete a task quickly enough through the approved system, so they create a workaround. A manager uses a faster channel because the official process feels too slow. A team adopts an unauthorised tool because the approved one does not fit the work.

The problem is not always that employees do not know the rules. The policy describes how work is supposed to happen, while employees deal with how work actually happens.

On Paper, Everything Works

Knowing the Policy Is the Easy Part

Recent research on information security policy compliance shows that awareness alone is not enough. Employees may understand the rules and still behave differently when the approved process feels difficult, time-consuming, unclear, or disconnected from the pressures of their role. The research describes this as a “knowing-doing” gap: people may know what the organisation expects without consistently following it in practice.

Organisations often assess policy strength through formal evidence: an approved document, completed training records, and a successful audit review. Those signals show that the process exists, but they reveal far less about how employees behave under pressure.

Deadlines, slow systems, unclear instructions, and competing business demands often shape daily decisions more than the policy itself.

Green Checks Can Hide Grey Practices 

A policy may be formally approved, communicated across the organisation, included in training, and reviewed during an audit, yet still remain weakly connected to daily work. From a governance perspective, those visible signs can create a level of confidence that the organisation has not fully earned.

Leadership can see the document, the completion records, and the audit result. It has far less visibility into the small decisions employees make when the official process slows them down, creates extra work, or conflicts with an urgent business need. A team may use an unapproved tool, a manager may accept an informal exception, or an employee may skip a step that seems unnecessary in the moment. None of these actions may appear serious on their own, but together they can create a growing gap between the control environment described in policy and the one that actually exists.

The difficulty is that formal evidence usually records whether a process was designed, approved, or reviewed. It rarely shows how consistently that process is followed under pressure. As a result, an organisation may report strong compliance while the day-to-day reality depends on workarounds, local habits, and decisions that never reach the formal governance process.

Good Intentions Can Create Bad Security 

The Employee Followed Security – Just Not Yours 

A 2025 study examined what the researchers call shadow security practices – unofficial security-related workarounds created by employees who still believe they are protecting the organisation.

An employee may save important files on a personal device because the approved backup system is slow. The intention is protective, but the result is still outside the organisation’s control and may violate data-handling rules.

Shadow security is difficult to manage because the employee may still be trying to protect the organisation. They are balancing a business task with a security requirement, but doing so through a method the organisation cannot see or govern. 

Too Much Security Can Drive Work Underground 

The same study surveyed 433 office workers and found that information security overload increased employees’ intention to use unofficial security practices. When people felt that security duties added pressure, delayed their work, or made primary tasks harder, they were more likely to create their own solution.

This does not mean controls should disappear whenever they create friction. Some friction is necessary because the risk justifies it.

The problem begins when the organisation adds controls without understanding their combined effect. One approval, one authentication step, and one reporting requirement may each seem reasonable. Employees, however, experience the full process. When those requirements accumulate, the approved path may become harder to follow than the workaround.

Another Training Session Will Not Fix the Process 

Security Communication or Security Noise?

The shadow security study found that employees were less likely to create workarounds when they understood how security measures worked, why management required them, and what outcomes the measures were meant to achieve.

However, the study also found that excessive communication can increase overload. More emails, more warnings, and more training do not automatically create better behaviour. They can create confusion, fatigue, and pressure.

The goal should therefore not be maximum communication. It should be useful communication that explains the risk, the reason for the rule, and the practical way to follow it.

Culture Decides Which Rules Survive 

The 2025 systematic review found that policy compliance is influenced by employee attitudes, perceived effectiveness of security measures, management support, awareness, and organisational culture.

Employees notice whether leaders follow the same rules they promote. They notice whether managers reward speed while security demands caution, and whether reporting a problem leads to support or blame.

A policy may say that security is everyone’s responsibility, but the organisation teaches a different lesson when deadlines always win or exceptions are quietly ignored.

Training cannot fix that on its own. If the approved process is too slow, another awareness session will not make it faster. If employees are rewarded for speed and punished for delay, a reminder about compliance will not change the incentive.

Workarounds Are Also Evidence

A workaround should not be accepted simply because the employee had good intentions. Unapproved practices can still create serious risk.

But they should be studied.

A workaround shows where the official process and actual work have separated. It may reveal a missing tool, unclear ownership, a slow approval chain, or a policy that was written without enough operational input.

The organisation should examine both the employee’s decision and the conditions that made the approved process difficult to follow.

Approved, Published, Forgotten  

A policy becomes useful when the organisation can see how it is being applied.

That requires clear ownership, defined controls, evidence, exceptions, and regular review. It also requires visibility into where practice is moving away from policy.

For organisations using CISOteria, this means connecting policies to the controls, owners, evidence, risks, and compliance requirements they are meant to govern. The value is not simply in storing the policy. It is in showing whether the policy is active, who is responsible for it, what proves that it is being followed, and where gaps remain.

CISOteria does not enforce employee compliance. It gives the organisation visibility into whether policy and practice remain aligned.

Conclusion:

The Rules That Survive Pressure Are the Rules You Actually Have 

Every organisation has two versions of its security policy. One is written, approved, and presented during audits. The other is shaped by daily decisions, management behaviour, informal exceptions, and the pressure employees face when they try to get work done.

Good governance begins with recognising the gap between the two. The organisation needs to understand where practice has moved away from policy, why that happened, and whether the right response is stronger enforcement, clearer communication, a better process, or a revised policy.

Because the written policy shows what the organisation intends to do. Daily behaviour shows what it has actually made possible.

For Further Reading

This blog post is based on insights and analysis from:

Geopolitical Cyber Risk: The Hidden Threat Your Risk Register Is Missing

Posted on by CISOteria

The Internet Doesn’t Care About Your Threat Model, But Geopolitics Just Rewrote It Anyway 

Geopolitical cyber risk can start changing your exposure long before anyone updates the risk register.

A treaty gets signed between two countries. Nobody in your security team reads about it. Nobody adds it to the risk register. Yet within months, the networks carrying data between those countries begin forming more direct connections.

No firewall changed. No vulnerability disappeared. The structure underneath the internet simply adjusted to a new expectation of risk. 

Now change the conditions. Sanctions. A diplomatic crisis. A border skirmish. Network operators begin reconsidering who they depend on, which traffic they accept, and how much instability they are willing to carry. They do not always wait for a government order. Sometimes companies move first because they can already see the risk approaching. 

This is not theory. Researchers analyzed routing relationships across more than 70,000 internet networks, 173 countries, and 96 months. They found that a treaty was associated with a 58.5% increase in direct interconnection agreements between networks across the countries involved. 

That is not a rounding error. That is the internet reorganizing around power politics without a single CISO in the room. 

Here’s the uncomfortable part: your risk register probably doesn’t have a line item for “geopolitical relationship between Country A and Country B.” 

But perhaps it should. 

Because that relationship may already be shaping which networks carry your data, which suppliers remain dependable, which regions are becoming harder to support, and how quickly the business could recover if one of those dependencies disappeared. 

The Threat Model Is Missing Something

The World Economic Forum Just Confirmed What CISOs Suspected

The Global Cybersecurity Outlook 2026 surveyed more than 800 security leaders across 92 countries. It found that 64% of organizations now factor geopolitically motivated cyberattacks, including espionage and critical infrastructure disruption, into their overall risk strategy. 

That’s not a niche concern anymore. That’s a majority. 

And it’s not paranoia. Politically motivated cyber activity rarely stays contained within governments. It spills into telecommunications providers, cloud platforms, suppliers, transportation systems, financial infrastructure, and businesses that were never the primary target. 

Those organizations do not need to be part of the conflict. Their position inside the digital ecosystem is enough. 

A company may be targeted because of the customers it serves, the technology it operates, the research it holds, the infrastructure it supports, or the access it can provide to someone more strategically valuable. 

Sometimes you are the target. Sometimes you are the route. 

Confidence Is Falling Exactly When It Should Be Rising

The same WEF report found that 31% of respondents lacked confidence in their country’s ability to respond to a major cyber incident affecting critical infrastructure. Last year, that number was 26%. 

Confidence is going down while geopolitical instability is going up. That gap is where surprises live. 

And the gap isn’t evenly spread. Confidence in critical infrastructure protection sits at 84% in the Middle East and North Africa. In Latin America and the Caribbean, it’s 13%. If your organization operates across regions, your actual exposure varies wildly depending on which government, which infrastructure, and which alliance sits behind each office you have. 

Sanctions Leave a Blind Spot 

The Internet Gets an Exception 

Here’s a detail that is easy to miss when assessing geopolitical cyber risk: internet interconnection is routinely exempted from sanctions regimes.

The US Treasury has explicitly authorized peering with sanctioned telecom providers in Cuba, Iran, and Sudan since 2009. The EU clarified in 2022 that sanctions on Russia do not apply to the telecommunications infrastructure keeping communications running.

Why does this matter for you? Because it means the usual tools, tariffs, sanctions, and contract enforcement, do not fully reach the layer where your data actually moves. Almost 99.5% of interconnection agreements between networks are handshake deals with no formal contract at all. There is no clear legal backstop. The protection the business is used to relying on elsewhere may not exist here. 

The Real Risk Isn’t the Sanction, It’s the Retaliation

When China placed tariffs on Australia after a diplomatic dispute in 2020, the story didn’t end with trade numbers. Cyberattacks against Australian targets spiked immediately after, and by 2024, twenty members of an Australian parliamentary group focused on China had been directly targeted.

This is the pattern security leaders need to internalize: geopolitical tension doesn’t stay in the news cycle. It shows up as attack traffic, weeks or months later, often aimed at organizations that had nothing to do with the original dispute. 

Shadow AI Opens Another Front 

Urgency Moves Faster Than Governance

Geopolitical pressure changes how people work. A regional team needs a translation immediately. Procurement wants a supplier document summarized. Security needs to review unfamiliar material. Operations is trying to keep moving while normal support channels are unstable. 

So someone opens an AI tool nobody approved. 

The obvious risk is data leakage. The less obvious one is that the organization has just created another external dependency without checking where the service processes data, which infrastructure supports it, which jurisdictions affect it, or whether access could disappear when conditions change. 

One urgent task becomes a repeated shortcut. The shortcut becomes a workflow. Then leadership discovers that sensitive work depends on a tool with no contract, no accountable owner, no continuity plan, and no clear record of where the information went. 

Shadow AI belongs in the geopolitical cyber risk conversation because instability does not only change external threats. It also creates internal pressure to adopt services faster than the organization can assess them. 

That is how a tool nobody approved becomes part of a risk nobody mapped. 

So What Should CISOs Do? 

Nobody Owns the Whole Picture 

Geopolitical risk sits in a strange no-man’s-land inside most companies. Legal watches sanctions. Finance watches currency and commercial exposure. Procurement watches suppliers. Operations watches service delivery. Threat intelligence teams watch nation-state activity. 

Yet nobody may own the question that connects all of them: What happens to the business if political conditions change the security, availability, or trustworthiness of a dependency we rely on?

The WEF data suggests that large organizations are beginning to close this gap. Among organizations with more than 100,000 employees, 70% increased their focus on nation-state threat intelligence, compared with 30% of smaller organizations. Large organizations were also more likely to deepen engagement with government agencies and information-sharing groups, at 49% compared with 26%. 

Translation: the biggest players are already treating geopolitics as a core input to security decisions. Many others are still treating it as background noise. 

Turning Uncertainty Into a Decision 

The organizations doing this well are not guessing. They are mapping exposure the same way they would map any other risk: which vendors operate in which countries, which conflicts or political relationships affect them, and which of those conditions could change fast enough to matter. 

CISOs do not need to predict every geopolitical development. They need a repeatable way to decide whether it changes the organization’s risk. Ask three questions before the risk register falls behind: 

  • What changed?
    Did targeting increase, sanctions affect a provider, or a region become less stable? 
  • What does it touch?
    Which services, vendors, data flows, users, and recovery processes depend on it?
  • What decision changes?
    Does the organization need tighter monitoring, faster remediation, stronger access controls, an alternative provider, tested recovery, or board escalation? 

That is the practical translation CISOs need to make. A vague warning gives leadership something to worry about. A clear exposure gives leadership something to decide. 

Resilient Companies See More 

Highly resilient organizations do not rely on controls alone. They involve security earlier, map more of the ecosystem around them, and test what happens when a dependency fails. Among highly resilient organizations, 70% involve security in procurement, 59% assess supplier security maturity, 48% map their ecosystem in detail, and 44% run incident or recovery exercises with partners. 

Same threats. Same world. Completely different visibility.

That visibility does not remove geopolitical cyber risk. It gives the business enough time to act before a supplier, region, network, or hidden AI dependency makes the decision for it. 

Conclusion: The Risk Register Is Already Late

Global conflict, nation-state activity, sanctions, and regional instability will keep changing the conditions around your organization, often before any system fails and before any alert gives the security team a reason to look. 

The CISO cannot control those conditions. The job is to recognize when they have changed the organization’s exposure, identify which suppliers, regions, data flows, and unapproved tools now carry more risk, and turn that change into a decision leadership can defend. 

Could the organization show the board, today, which dependencies would become critical if geopolitical conditions shifted tomorrow? 

Geopolitical cyber risk is not simply another category to add to the register. It changes the likelihood, impact, urgency, and ownership of risks already there.

The risk register may already be late. The decision does not have to be.

For Further Reading

This blog post is based on insights and analysis from: