[OR] [P2] [S2] [MII] Fields for Mapping Interconnections and Interdependencies

Fields for Mapping of the Interconnections and Interdependencies

During the Implement Phase of the Operational Resilience (OR) Planning Methodology, the Mapping Interconnections and Interdependencies stage aims to establish a comprehensive understanding of the operational ecosystem supporting a Critical Business Service (CBS).

The purpose is to identify not only which resources the CBS depends on (interdependencies) but also how those resources interact and exchange services, information, and operational support (interconnections).

Interdependencies mapping identifies the people, processes, technology, facilities, information, and third parties necessary to deliver a service.

Interconnections mapping identifies the interaction pathways, communication channels, integration mechanisms, and relationships that link these interdependencies

Together, both activities enable organisations to understand service delivery architecture, identify concentration risk and single points of failure, and support impact tolerance analysis and scenario testing.

Definition

The operational resilience mapping process involves identifying interdependencies and interconnections between people, processes, information, technology, facilities, and third-party service providers required to deliver each critical business service.

Think of mapping as the process by which an organisation develops a holistic view of the systems and processes that support its business services, including those it does not control directly.

The following recommended field structures can be used to develop a comprehensive operational resilience mapping register.

Table 1: Mapping Interconnections Fields

Field	Description
CBS Code	Unique identifier of the Critical Business Service
CBS Name	Name of the Critical Business Service
Sub-CBS Code	Unique identifier of the Sub-Critical Business Service
Sub-CBS Name	Name of the Sub-CBS
Interconnection ID	Unique reference number
Source Component Type	Process, People, Technology, Data, Facility, Third Party
Source Component Name	Name of originating component
Target Component Type	Process, People, Technology, Data, Facility, Third Party
Target Component Name	Name of receiving component
Type of Interconnection	Data Flow, API Integration, System Interface, Workflow Handoff, Communication Link, Network Connectivity
Description of Interconnection	Detailed explanation of how the connection operates
Information Exchanged	Data, transactions, communications, instructions, documents, etc.
Connectivity Method	API, File Transfer, Manual Process, Email, Portal, Network Connection
Frequency of Interaction	Real-Time, Hourly, Daily, Weekly, On Demand
Direction of Flow	One-Way, Two-Way, Multi-Directional
Upstream Component	Component providing input
Downstream Component	Component receiving output
Supporting Technology	Systems supporting the connection
Third Party Involved	External provider supporting the connection
Security Classification	Public, Internal, Confidential, Restricted
Failure Impact	Impact if the connection fails
Recovery Method	Alternate connection or workaround
Recovery Time Objective (RTO)	Required recovery timeframe
Mapping Owner	Person responsible for maintaining the record
Last Review Date	Date of latest validation

Table 2: Mapping Interdependencies Fields

To identify and document the reliance relationships that support the delivery of Critical Business Services.

Field	Description
CBS Code	Unique identifier of the Critical Business Service
CBS Name	Name of Critical Business Service
Sub-CBS Code	Unique identifier of Sub-CBS
Sub-CBS Name	Name of Sub-CBS
Dependency ID	Unique dependency reference
Dependency Type	People, Process, Technology, Data, Facility, Third Party
Dependency Category	Internal or External
Dependent Component	Component requiring support
Supporting Component	Component providing support
Description of Dependency	Detailed explanation of dependency
Dependency Relationship	Sequential, Shared, Direct, Indirect, Critical, Supporting
Dependency Strength	High, Medium, Low
Criticality Rating	Critical, High, Medium, Low
Single Point of Failure (SPOF)	Yes / No
Concentration Risk	Yes / No
Number of CBS Supported	Number of CBS relying on this dependency
Geographic Dependency	Location supporting service
Third-Party Dependency	Name of vendor, if applicable
Fourth-Party Dependency	Known subcontractor, if applicable
Impact if Dependency Fails	Operational impact assessment
Maximum Tolerable Downtime (MTD)	Time service can tolerate dependency failure
Impact Tolerance Linkage	Link to approved impact tolerance
Alternate Dependency Available	Yes / No
Alternate Resource Description	Description of backup arrangement
Recovery Priority	Priority 1, 2, 3, etc.
Risk Rating	Inherent risk level
Existing Controls	Current resilience controls
Recommended Mitigation	Proposed improvement actions
Dependency Owner	Responsible business owner
Last Validation Date	Date dependency was reviewed

Recommended Dependency Classification Structure

The following dependency layers should be used consistently throughout the mapping exercise:

Dependency Layer	Examples
People	Operations Staff, SMEs, Management, Crisis Team
Process	Workflow, Approval Process, Reconciliation Process
Technology	Applications, Infrastructure, Networks, Cloud Services
Information/Data	Customer Data, Transaction Data, Reports
Facilities	Offices, Branches, Data Centres, Recovery Sites
Third Parties	Vendors, Outsourcing Partners, Payment Networks
Fourth Parties	Cloud Subcontractors, External Infrastructure Providers

Purpose of Interdependencies Mapping

Comprehensive dependency fields enable organisations to:

Identify critical supporting resources across the service ecosystem
Understand concentration risk and shared dependencies
Detect hidden upstream and downstream exposure
Identify single points of failure
Support impact tolerance calibration
Strengthen third-party and fourth-party resilience oversight
Enable severe but plausible scenario design and testing
Support recovery planning and resilience improvements
Demonstrate regulatory compliance and audit readiness

Relationship Between the Two Tables

Interconnections Table	Interdependencies Table
Shows HOW components interact	Shows WHY components rely on each other
Focuses on connectivity	Focuses on reliance
Maps, flows, and interfaces	Maps operational dependencies
Supports architecture analysis	Supports resilience analysis
Identifies communication paths	Identifies failure impact paths
Supports process and system mapping	Supports impact tolerance and scenario testing

Together, these two tables provide the core data structure required for Operational Resilience Plan Phase – Stage 2 (P2-S2) Mapping Interconnections and Interdependencies, and create the foundation for subsequent stages:

P2-S3: Impact Tolerance Setting
P2-S4: Severe but Plausible Scenario (SbPS) Testing
P2-S5: Lessons Learned and Continuous Improvement.

Learn more about Blended Learning OR-300 [BL-OR-3] and OR-5000 [BL-OR-5]

To learn more about the course and schedule, click the buttons below for the OR-3 Blended Learning OR-300 Operational Resilience Implementer course and the OR-5 Blended Learning OR-5000 Operational Resilience Expert Implementer course.