Most organisations that acknowledge the need for integration never actually achieve it, not because anyone disagrees with the principle but because the practical steps involved in connecting established functions with different histories, different tools, and different reporting lines are left unspecified. This article focuses on those practical steps.
Start With the Overlaps, Not a Reorganisation
Why Reorganisation Is Rarely the Right First Step
When risk and resilience teams are structurally separate, the tempting governance response is to consider whether they should be merged or restructured. In most cases, this is not the right starting point. Reorganisation is disruptive, takes attention away from the governance work itself, and typically creates a transition period during which both functions operate less effectively than before.
The more practical starting point is to identify where the two functions are already working on the same underlying material and to build connections there. The most consistent overlaps across organisations are technology and third-party risk, incident data and scenario analysis, and the evidence base for board reporting. Starting in these areas creates visible governance value faster than a structural reorganisation and demonstrates what integration can achieve before any organisational change is considered.
Technology and Third-Party Risk as the Primary Overlap
Technology risk and third-party risk are where the substantive overlap between risk management and resilience is greatest and most immediately actionable. The risk team holds likelihood assessments for technology failures and supplier failures. The resilience team holds dependency maps showing which important business services would be affected by those same failures, and testing results showing how the organisation actually performs when they occur.
These are two halves of the same picture. Risk likelihood without resilience impact assessment is incomplete. Resilience impact assessment without risk likelihood is also incomplete. When both are visible together, the organisation has a materially better understanding of its actual exposure than either function provides alone.
A practical first step: arrange a structured session between the risk and resilience functions to compare the risk register entries for technology and third-party risks with the resilience programme's dependency maps. Ask, for each significant dependency identified in the resilience mapping, where it appears in the risk register and what residual risk rating it carries. Ask, for each significant technology or third-party risk in the register, whether the resilience programme has tested the important business service implications of that risk materialising.
The gaps that exercise reveals are the starting point for the integration programme.
Build Shared Data Before a Shared System
The Common Taxonomy First
The most immediate barrier to connecting risk and resilience data is typically taxonomic: the two functions use different categories, different terminology, and different identifiers for what are in many cases the same underlying assets, dependencies, and risks. A technology system identified as "Core Banking Platform A" in the resilience dependency map and as "Transaction Processing System" in the risk register may be the same system. Without a common identifier, connecting the two records requires manual interpretation.
Agreeing a common naming convention for critical assets, systems, and third parties is unglamorous work, but it is foundational. It is also achievable without waiting for a shared technology platform: a reference table that maps the identifiers used by the risk function to those used by the resilience function allows data to be connected immediately, even across separate tools.
Incident Data as a Shared Resource
Operational incident data is a resource that both functions need and neither typically has complete access to on its own. The risk function uses incident data to validate self-assessed risk ratings and to identify systemic patterns. The resilience function uses incident data to inform the scenarios it tests, because real incidents reveal how disruptions actually unfold in this specific organisation's environment rather than how they are theoretically expected to.
Establishing a shared incident data resource, accessible to both functions, is one of the most immediately valuable data connections available. In most organisations this requires a governance decision about data access rather than a technology project: the incident data typically exists in one system or another, and the barrier is permission and process rather than technical capability.
Build the Governance Connections
Joint Risk and Resilience Reporting to the Board
The most visible governance connection is a combined risk and resilience report to the board, or at minimum a risk report that explicitly references resilience testing results where they are relevant to risk assessments. When the board sees a technology risk rated as medium residual risk in the same paper that notes the resilience testing programme found that a failure of the underlying system would breach the impact tolerance for two important business services, the inconsistency is visible and demands resolution.
A board that receives separate risk and resilience reports, presented in different formats and at different points in the governance calendar, is being asked to perform the integration task that the executive risk and resilience functions should have performed before the reports reached the board.
Coordinated Testing Calendars
Resilience scenario testing and risk assessment cycles are both resource-intensive and both depend on input from first-line business units that have limited governance bandwidth. When both programmes make independent demands on business units at the same time, the quality of both exercises suffers. When they are coordinated, both benefit.
Specifically: risk assessment cycles that take place in advance of resilience testing provide fresh risk intelligence that should inform the scenarios the testing programme uses. Resilience testing results that become available before the next risk assessment cycle provide evidence that should inform the residual risk ratings in the register. The two cycles should be planned to enable this sequencing rather than happening independently with no reference to each other.
Escalation Path Alignment
When a resilience testing exercise reveals that the organisation cannot meet an impact tolerance, the escalation path should reach the same governance body as a significant risk breach. When the risk register identifies a risk that is outside appetite and that directly affects the resilience of an important business service, the resilience team should be involved in the remediation response.
These connections need to be defined explicitly in governance documentation rather than assumed. Without explicit definition, each function will follow its own established escalation path, and the governance body at the end of each path may not be aware of the other function's parallel finding.
Specific Practices That Work
Joint Review of Significant New Risks
Before either function finalises documentation on a significant new risk or a new dependency identification, the other should have an opportunity to review it. A new technology deployment that creates a significant entry in the risk register should prompt the resilience team to assess the dependency implications for important business services before the risk assessment is completed. A new dependency identified through resilience mapping should prompt the risk team to review whether the risk register adequately captures the risk associated with that dependency.
This joint review does not require elaborate governance machinery. A defined notification step, the risk team notifying the resilience team of significant new risk register entries and vice versa, followed by a brief structured review, is sufficient for most organisations.
A Shared View of Critical Third Parties
DORA requires financial entities to maintain a Register of Information covering all ICT third-party arrangements. Building this register well requires input from both the risk and resilience functions. The risk function contributes the risk assessment for each provider. The resilience function contributes the dependency mapping showing which important business services each provider supports and what the resilience implications of its failure would be.
Using the DORA register as the shared third-party record, even for entities that would benefit from this view regardless of DORA obligations, creates a practical, governance-mandated vehicle for the third-party data integration that both functions need.
Post-Exercise Reviews
After each significant resilience testing exercise, a structured review should involve both the resilience team and the risk function. The review should ask: what did the exercise reveal about the adequacy of controls that the risk register assumed were in place? Are there risk register entries that should be updated based on what the exercise found? Are there risk register entries for risks the exercise did not test that should now be prioritised in the next testing cycle?
Documenting the outcomes of this review and the decisions made about risk register updates creates an evidence trail that demonstrates governance integration to regulators and internal auditors, and prevents the testing insights from being absorbed only by the resilience function and lost to the broader governance programme.
References and Further Reading
