This separation is understandable historically. Operational resilience, as a distinct regulatory obligation, is relatively new in most jurisdictions. It developed from business continuity disciplines that sat outside traditional risk management structures. And the FCA and PRA's policy statement set specific resilience governance requirements that created natural pressure to build resilience as a standalone programme.
But the case for connecting ERM and operational resilience, rather than maintaining them as parallel disciplines, is considerably stronger than the case for keeping them apart. This article sets out where the overlap is deepest, what is lost when the two programmes operate in silos, and what genuine connection looks like in practice.
The Underlying Overlap: Both Disciplines Ask the Same Questions
Shared Analytical Territory
Both ERM and operational resilience require the organisation to understand its dependencies. ERM asks what could prevent the organisation from achieving its objectives, which requires understanding what the organisation depends on to function. Operational resilience asks whether critical services can keep running under disruption, which requires exactly the same dependency understanding, focused specifically on the people, technology, data, facilities, and third parties that support each important business service.
Both disciplines require scenario analysis. ERM uses scenario analysis to stress-test the risk register against severe but plausible events, particularly for low-frequency, high-severity risks where historical data provides limited basis for assessment. Operational resilience uses severe scenarios to identify the conditions under which impact tolerances would be breached. The analytical methodology is the same. The scenarios are often the same. The outputs, risk ratings in ERM and resilience assessments in the resilience programme, are different but should be consistent.
Both require board-level governance. The FCA's PS21/3 places explicit accountability on the board for approving important business services and impact tolerances. The COSO ERM Framework places the board at the centre of enterprise risk governance. These are not competing governance demands. They are the same governance demand expressed in different regulatory contexts.
The Technology and Third-Party Dimension
Technology risk and third-party risk are where the overlap between ERM and operational resilience is most immediate and most practically consequential. The risk register holds assessments of how likely a critical system failure or a key supplier failure is. The resilience programme holds dependency maps showing which important business services depend on those same systems and suppliers, and testing results showing what actually happens if they fail.
When these are managed separately, the risk function assesses the likelihood of a technology failure without knowing what the resilience programme's testing revealed about the consequences. The resilience team maps dependencies without the benefit of the risk function's assessment of which dependencies carry the highest failure probability. Both functions are working with half the picture they need.
What Gets Lost When They Stay Separate
Inconsistent Risk Ratings and Resilience Assessments
The most immediate problem when ERM and resilience operate independently is that they can, and often do, assess the same underlying vulnerability differently. A technology dependency rated as low residual risk in the risk register may be the dependency that the resilience testing programme has shown cannot be recovered within the relevant impact tolerance. When the board sees these two assessments side by side, in separate reports, the inconsistency is visible. When they are presented in separate reports that the board does not naturally compare, the inconsistency is invisible.
Inconsistent assessments of the same underlying risk do not represent a difference of analytical opinion. They represent a failure of governance to ensure that the organisation's view of its risk position is coherent.
Testing Results That Do Not Feed Back Into Risk Assessments
Operational resilience testing is one of the most valuable sources of evidence about the organisation's actual risk position. When scenario testing reveals that a critical service cannot remain within its impact tolerance because a dependency fails in a way the continuity plan does not account for, that is a finding with direct implications for the risk register. The control assessed as adequate is not adequate. The residual risk is higher than currently rated.
When resilience testing results do not flow back into risk assessments, the risk register continues to reflect assumptions that the testing has shown to be false. The board receives risk reporting that does not reflect what the organisation actually knows about its own vulnerabilities.
Duplicated Third-Party Governance
Third-party risk management typically sits with the risk function. Third-party dependency mapping for resilience purposes sits with the resilience team. Without connection between the two, both functions conduct partial assessments of the same supplier relationships: the risk function assessing financial stability, security posture, and contractual terms, while the resilience team assesses which services depend on the supplier and what the impact of loss would be.
Neither assessment is complete on its own. A supplier with excellent security posture but no viable exit path may be low credit risk but high resilience risk. A supplier with a sub-optimal security assessment but multiple viable alternatives may be a manageable resilience risk. The complete picture requires both perspectives, and when they are held in different systems by different teams, the complete picture exists only in the minds of individuals who happen to know both, not in the governance documentation the board relies upon.
What Connecting ERM and Resilience Actually Looks Like
Shared Risk Data Informing Resilience Priorities
The most immediate practical connection is using the risk register to inform which dependencies and scenarios the resilience programme prioritises. If the risk register identifies technology concentration in a specific cloud provider as a high residual risk, the resilience testing programme should prioritise scenarios involving that provider's failure. If the risk register identifies a specific third-party dependency as a significant operational risk, the resilience mapping exercise should examine that dependency with particular care.
This sounds obvious when stated explicitly. In many organisations it does not happen, because the resilience programme plans its testing calendar without reference to the current risk register.
Testing Results Updating the Risk Register
When resilience scenario testing reveals that the organisation cannot meet an impact tolerance because a specific dependency fails, that finding should trigger an update to the risk register: the control assessed as managing the relevant risk is not operating as assumed, and the residual risk rating should be reviewed in light of what testing has revealed.
This requires a defined process, not an informal expectation. Someone needs to be responsible for reviewing testing results against the risk register, identifying where the two are inconsistent, and ensuring the risk assessment is updated to reflect what the evidence shows.
A Single Third-Party View
Third-party governance that combines risk assessment and resilience dependency mapping produces a more complete and more accurate picture than either can provide alone. For each significant third-party relationship, this means understanding both the risk profile of the provider and the resilience implications of the services it delivers, held in a single view that the board can see.
Under DORA, financial entities are required to maintain a Register of Information covering all ICT third-party arrangements, to assess concentration risk, and to maintain exit strategies. These obligations connect risk and resilience governance structurally. An organisation building its DORA compliance framework has a natural opportunity to create the single third-party view that genuinely integrated governance requires.
Connected Board Reporting
Board reporting that references findings from both the risk programme and the resilience programme, rather than presenting them as entirely separate updates, produces a more coherent governance picture and surfaces connections that separate reporting obscures. A board that sees the risk register rating for a technology dependency alongside the resilience testing result for the same dependency is better informed about the actual position than a board that sees each in a different paper presented in a different quarter.
References and Further Reading
