[OR] [P2] [S2] Fields for Mapping Interconnections and interdependencies

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	Example
Connectivity ID	Unique identifier for the connectivity relationship	CONN-CBS2-001
CBS Code	Critical Business Service identifier	CBS-2
CBS Name	Critical Business Service name	Market Data Distribution Services
Sub-CBS Code	Detailed process identifier	2.9
Sub-CBS Name	Detailed process name	Data Feed Publication and Distribution
Source Component	Originating system, process, team, or entity	Market Data Aggregation Engine
Destination Component	Receiving system, process, team, or entity	API Gateway
Source Dependency Type	Type of source component	Technology
Destination Dependency Type	Type of destination component	Technology
Connectivity Category	Classification of connectivity	Internal / External / Cloud / Third Party
Connectivity Type	Nature of interaction	People / Process / Technology / Data
Connectivity Description	Description of interaction	Aggregated market data sent to the API gateway
Business Purpose	Purpose of the connectivity	Real-time customer data delivery
Interaction Method	Mechanism of interaction	API / MQ / FIX / SFTP / Manual
Interface Name	Specific interface or service name	Market Feed API
Interface Protocol	Communication protocol	HTTPS, FIX, TCP/IP
Data Flow Direction	Direction of interaction	One-way / Bidirectional
Information/Data Exchanged	Information transmitted	Tick data, trade prices
Data Classification	Sensitivity of information	Public / Internal / Restricted
Connectivity Frequency	Frequency of interaction	Real-time
Volume/Capacity	Estimated throughput	5 million events/sec
Latency Requirement	Performance requirement	<5 milliseconds
Availability Requirement	Service availability target	99.999%
Geographic Connectivity	Locations connected	London DC to Manila Office
Network Type	Underlying transport mechanism	MPLS, SD-WAN
Security Controls	Security protecting connectivity	Encryption, MFA, DDoS controls
Monitoring Mechanism	Monitoring tool	Dynatrace, Splunk
Alert Threshold	Escalation criteria	Latency >20ms
Resilience Control	Existing resilience measures	Active-active routing
Redundancy Arrangement	Backup connectivity arrangement	Secondary telecom path
Single Point of Failure Indicator	Indicates SPOF risk	Yes / No
Manual Workaround	Alternative operating process	Manual feed upload
Upstream Connectivity	Prior interaction source	Feed validation platform
Downstream Connectivity	Subsequent interaction destination	Client delivery platform
Owner	Connectivity owner	Infrastructure Operations Team
Support Team	Supporting team	Network Operations Centre
Last Review Date	Last assessment date	15 May 2026
Scenario Test Reference	Linked test scenario	SuPS-CBS2-004
Remarks	Additional notes	Telecom dependency concentration under review

Table 2: Mapping Interdependency Fields

Field	Description	Example
Dependency ID	Unique identifier	DEP-CBS2-001
CBS Code	Critical Business Service identifier	CBS-2
CBS Name	Critical Business Service name	Market Data Distribution Services
Sub-CBS Code	Detailed process identifier	2.10
Sub-CBS Name	Detailed process name	Low-Latency Data Delivery and Network Routing
Dependency Name	Name of dependency	Telecommunications Provider
Dependency Description	Description of dependency role	Provides connectivity supporting market data delivery
Dependency Type	Primary dependency category	People / Process / Technology / Third Party
Dependency Sub-Type	Detailed classification	Network Service Provider
Dependency Classification	Internal or external classification	Internal / External
Dependency Criticality	Importance level	Critical / High / Medium
Business Owner	Business function owner	Market Data Operations
Technical Owner	Technology owner	Infrastructure Services
Supporting Team	Operational support owner	Network Support Team
Dependency Purpose	Purpose of dependency	Supports real-time transmission
Operational Function Supported	Activity supported	Customer data delivery
Related Processes	Processes depending on the component	Feed publication and distribution
Application/System Name	Supporting system name	Distribution Platform
Infrastructure Component	Supporting infrastructure	Router cluster
Data Dependency	Data used or generated	Real-time market updates
Geographic Location	Operating or hosting site	London Primary DC
Jurisdiction	Country/legal jurisdiction	Philippines
Third-Party Provider	External supplier	Telecom carrier
Fourth-Party Dependency	Subcontracted provider	Backbone network provider
Cloud Provider	Hosting platform	AWS
Shared Dependency Indicator	Shared across services	Yes / No
Concentration Risk Indicator	Dependency concentration risk	High
Single Point of Failure Indicator	SPOF existence	Yes / No
Existing Redundancy	Existing resilience arrangement	Dual network links
Alternate Dependency Available	An alternate provider exists	Secondary carrier
Recovery Time Objective (RTO)	Required restoration time	15 minutes
Recovery Point Objective (RPO)	Acceptable data loss	Near zero
Maximum Tolerable Downtime	Maximum outage period	30 minutes
Availability Requirement	Required uptime	99.999%
Dependency Failure Impact	Impact if unavailable	Data delivery interruption
Customer Impact	Impact on customer services	Delayed pricing information
Financial Impact	Potential financial effect	Revenue loss
Regulatory Impact	Compliance implication	Reporting disruption
Reputational Impact	Reputation consequence	Reduced market confidence
Cyber Risk Exposure	Associated cyber threat	DDoS risk
Existing Security Controls	Current protective controls	WAF, SIEM, IAM
Monitoring Mechanism	Monitoring capability	Splunk, NOC Dashboard
Health Indicators	Metrics monitored	Throughput, latency
Testing Frequency	Test interval	Quarterly
Scenario Test Reference	Linked resilience scenario	SuPS-CBS2-007
Current Status	Current dependency status	Green / Amber / Red
Last Review Date	Date reviewed	15 May 2026
Remarks	Additional comments	Dependency under resilience improvement review

Suggested Interconnections Classification Dimensions

In addition to category definitions, organisations may further classify connectivity using the following attributes:

Classification Dimension	Examples
Direction	One-way, Bidirectional
Nature	Manual, Automated
Frequency	Real-time, Near Real-time, Daily, Weekly
Environment	Production, Development, DR
Ownership	Internal, Shared Service, Third Party
Criticality	Critical, High, Medium, Low
Security Level	Public, Internal, Confidential, Restricted
Resilience Level	Fully Redundant, Partial Redundancy, Single Path

Purpose of Interconnections Categorisation

A structured connectivity taxonomy enables organisations to:

Understand end-to-end service interaction pathways
Identify disruption propagation paths
Detect hidden interdependencies
Identify concentration risks and single points of failure
Support impact tolerance and recovery analysis
Facilitate severe but plausible scenario development
Support cyber resilience and third-party risk assessments
Improve operational resilience reporting and audit readiness

These categories support regulatory expectations that organisations maintain a comprehensive understanding of how critical services operate and how disruptions can cascade through interconnected systems and operational ecosystems.

Suggested Interdependencies Categories

For consistency, organisations should standardise dependency classifications:

Interdependency Category	Examples
People	Operations teams, SMEs, administrators, support staff
Process	Manual workflows, approvals, and escalation procedures
Technology	Applications, databases, middleware, APIs
Data	Market data, customer records, reference data
Facilities	Data centres, offices, recovery sites
Third Party	Telecom providers, cloud services, market vendors
Fourth Party	Subcontracted providers supporting third parties
Cyber and Security Services	SOC, IAM, SIEM, DDoS services

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

Alignment with Operational Resilience Requirements

This dependency structure aligns with guidance across operational resilience frameworks, including BSP Circular No. 1203, MAS operational resilience expectations, and international resilience standards.

Dependency mapping demonstrates that organisations understand not only their critical business services but also the ecosystem of resources required to sustain those services under disruptive conditions. It creates the operational baseline required for impact analysis, resilience assessment, and continuous improvement activities across the operational resilience lifecycle.

Key Distinction Between the Two Registers

Interconnections Mapping	Interdependencies Mapping
Focuses on how components interact	Focuses on what components support the service
Captures interaction pathways and interfaces	Captures supporting resources and ownership
Identifies communication flow and service exchanges	Identifies supporting assets and dependencies
Supports flow analysis and disruption propagation mapping	Supports criticality and concentration risk analysis
Identifies interface-level failure points	Identifies resource-level failure points

Together, these two mapping structures provide the operational foundation for impact tolerance setting, severe-but-plausible scenario development, resilience remediation planning, and regulatory evidence for operational resilience programmes.

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.