In the first article in this series, I argued that cyber risk suffers a translation problem: the language of operational risk frameworks, designed for a different class of loss event, does not map cleanly onto the adversarial, interconnected, and difficult-to-measure nature of cyber exposure. The result is a governance gap – not from negligence, but from structural incompatibility.
This piece is about a related but distinct problem. Not how cyber risk is described, but how it accumulates – quietly, incrementally, through decisions made entirely outside the cyber risk function, by people with entirely legitimate objectives, who had no idea they were loading exposure into someone else’s register.
The mechanism
Every risk domain in a financial institution operates with its own appetite, its own escalation thresholds, and its own decision-making logic. Operational risk managers optimise for stability and continuity. Conduct risk owners prioritise customer outcomes. Compliance teams respond to regulatory obligation. People functions balance employee experience against control requirements. These are not competing priorities – they are complementary ones, and the governance architecture is designed to manage them in parallel.
The problem arises at the boundaries. When a decision made entirely within one domain – rational, well-governed, and consistent with that domain’s appetite – transfers risk exposure into another domain without any formal record of that transfer, the receiving domain has inherited a risk it never accepted. The decision-maker has moved on, their objective met. The cyber exposure propagates in their wake, in a domain they were never looking at.
I have observed this pattern across global institutions, but it is not a failure of intent. The governance architecture was not designed to make these transfers visible – and in most institutions, the discipline to compensate for that gap has not been applied.
Where it happens
The following examples are drawn from experience. Each involves a decision that was reasonable on its own terms. Each transferred cyber exposure in a way the governance framework was not designed to detect.
- Change freeze versus security patch urgency (OpRisk to Cyber). A change freeze is imposed around a major business event – a core system migration, a regulatory deadline, a year-end close. A critical security patch cannot be deployed for the duration. The change management team made a legitimate operational resilience decision. The cyber team inherited an unmitigated vulnerability and had no mechanism to formally escalate the trade-off. The freeze was a business decision, not a risk decision, so it generated no risk acceptance record.
- Patching SLA extension (OpRisk to Cyber). Infrastructure teams extend patching windows to reduce system instability and protect service availability. This is a reasonable operational risk call – a preference for continuity over the short-term disruption of forced updates. But the unpatched vulnerability window widens with each extension, and the cyber exposure increases in ways that the operational risk framework does not register. The two appetites are not reconciled. They run in parallel, and the gap between them grows.
- Authentication simplification (Conduct Risk to Cyber). A product or customer experience team simplifies authentication steps in a digital channel to reduce friction, improve conversion, and raise customer satisfaction scores. These are legitimate conduct and customer outcomes objectives. The simplified flow reduces security assurance. Account takeover and fraud exposure increases. The product team hit their targets. Nobody in the cyber function formally accepted the residual.
- Compliance-driven data retention (Compliance Risk to Cyber). A compliance team mandates extended data retention to satisfy regulatory audit requirements. The expanded data estate – more data, held for longer, across more environments – increases the value and sensitivity of what an attacker could reach. The compliance decision was correctly made against its own regulatory obligation. The cyber exposure it created landed in a different register, unrecorded.
- Training hour reduction (People Risk to Cyber). An HR or L&D function reduces mandatory security awareness training as part of a broader initiative to address training fatigue and improve employee experience scores. The people risk rationale is sound. The reduction in trained awareness quietly erodes a cyber control that no technical measure can fully substitute. A people risk decision transferred exposure into the human layer of the cyber risk architecture.
- Accelerated vendor onboarding (Third Party Risk to Cyber). Commercial or procurement pressure shortens a vendor onboarding timeline. Third-party risk due diligence is compressed to meet a business deadline. Residual exposure from an under-assessed vendor lands in the cyber risk register without anyone in the commercial chain having formally accepted it. The business got its vendor. The cyber function got its problem.
Why the framework doesn’t catch it
Each of these decisions was made by people acting within their authority, optimising against their own risk appetite, and meeting their own governance obligations. None of them was wrong in isolation. The governance failure is not in any individual decision – it is in the absence of a mechanism to identify, record, and formally accept the cross-domain consequence.
Risk appetite frameworks are largely built to manage risk within domains, not between them. The cyber risk register captures what the cyber function knows about. It does not have a feed from change management, procurement, HR, or product development that would allow it to detect when an external decision has altered its exposure. The transfer is invisible to the architecture that is supposed to govern it.
This matters for two reasons. First, the cyber function ends up carrying risk it cannot explain, because it did not originate it and was not party to the decision that created it. Second, the institution cannot make coherent risk trade-offs if the trade-offs are happening implicitly, in one domain, with consequences accumulating in the wake of decisions made somewhere else entirely.
What proportionate good practice looks like
The solution is not a parallel governance layer or a new committee. It is a more deliberate approach to decisions that cross domain boundaries.
Institutions that manage this well tend to share a few common characteristics. Risk appetite statements for different domains are reviewed for coherence – not just individually, but against each other, so that a decision consistent with one appetite cannot silently violate another. Material decisions that touch domain boundaries – change management, vendor onboarding, product design, data architecture – include a cross-domain risk check as a standard step, not an exception. And where a trade-off between domains is genuinely necessary, it is recorded as a conscious risk acceptance decision, owned by someone with the authority to make it.
None of this is technically complex. The architecture does not need to be rebuilt. It needs to be used more deliberately. The question is whether the institution has designed its risk management process to make cross-domain transfers visible, or whether it has left them to accumulate quietly until they surface somewhere inconvenient.
In most institutions I have observed, it is the latter.
About the Author
This is the second of Jim Roberts’ three‑blog series. With decades of senior experience – including former Global Head of Technology & Cyber Risk at Prudential PLC and Managing Director at Standard Chartered Bank – Jim has seen first‑hand how well‑intentioned governance structures can mask deeper organisational weaknesses. Now, as Founder of Whitecliff Advisory, he works with boards and executive teams to uncover these hidden dynamics and strengthen real‑world cyber resilience.
Connect with Jim on LinkedIn > Jim Roberts | LinkedIn
