[OR] [P2] [S2] [MII] [C5] Step 2 – Identify Data Sources

[P2] [S2] Chapter 5

Step 2 – Identify Data Sources

Introduction

After defining the scope of mapping and identifying Critical Business Services (CBS), the next essential step is to identify and gather the data required for mapping interconnections and interdependencies.

The quality of mapping outputs is directly dependent on the quality of input data. Incomplete, outdated, or inaccurate data will result in:

• Misidentified dependencies
• Gaps in mapping
• Weak scenario testing and recovery planning

This step ensures that organisations collect reliable, comprehensive, and relevant data from both internal and external sources before proceeding with detailed mapping.

Purpose of the Chapter

The purpose of this chapter is to:

• Identify key internal and external data sources required for mapping
• Provide guidance on collecting and validating data
• Ensure that mapping is based on accurate and complete information
• Establish data quality principles for effective mapping

Importance of Data in Interconnection Mapping

Data as the Foundation of Mapping

Mapping interconnections and interdependencies requires a deep understanding of:

• Processes
• Systems
• Data flows
• Third-party relationships

This understanding can only be achieved through high-quality data inputs.

Risks of Poor Data Quality

If data is:

• Incomplete: Critical dependencies may be missed
• Inaccurate: Mapping may misrepresent actual operations
• Outdated: Mapping becomes irrelevant and misleading

These risks can lead to:

• Ineffective resilience strategies
• Incorrect impact tolerance definitions
• Unrealistic scenario testing

Internal Data Sources

Internal sources provide the primary foundation for understanding how CBS are delivered within the organisation.

Process Documentation

Description

Process documentation includes:

• Standard operating procedures (SOPs)
• Workflow diagrams
• Process manuals

Value for Mapping

• Defines how activities are performed
• Identifies process steps and sequences
• Highlights dependencies between processes

Limitations

• May be outdated or incomplete
• May not capture informal or manual workarounds

Best Practice

• Validate documentation through stakeholder engagement
• Supplement with real-world process walkthroughs

IT Architecture Diagrams

Description

IT architecture diagrams provide visual representations of:

• Systems and applications
• Infrastructure components
• Integration points

Value for Mapping

• Identifies system dependencies
• Highlights connectivity between applications
• Supports understanding of technology architecture

Limitations

• May not reflect current system configurations
• May lack detail on data flows or third-party integrations

Best Practice

• Cross-check with system owners and IT teams
• Align with Configuration Management Databases (CMDB) where available

Risk Registers

Description

Risk registers document:

• Identified risks
• Impact assessments
• Existing controls

Value for Mapping

• Highlights known vulnerabilities
• Identifies critical risk areas
• Provides insight into high-impact dependencies

Limitations

• May focus on individual risks rather than interdependencies
• May not capture emerging or evolving risks

Best Practice

• Integrate risk insights with mapping outputs
• Use risk data to prioritise critical dependencies

External Data Sources

External sources provide visibility into dependencies beyond the organisation, particularly third-party and regulatory requirements.

Vendor Service Level Agreements (SLAs)

Description

SLAs define:

• Performance expectations
• Availability requirements
• Service commitments

Value for Mapping

• Identifies critical third-party dependencies
• Provides insight into service reliability and recovery capabilities
• Defines contractual obligations

Limitations

• May not reflect actual service performance
• Limited visibility into fourth-party dependencies

Best Practice

• Validate SLA performance through monitoring and reporting
• Integrate SLA data with third-party risk management

Regulatory Requirements

Description

Regulatory requirements define expectations for:

• Operational resilience
• Business continuity
• Risk management

Examples include guidance from:

• Monetary Authority of Singapore
• Bangko Sentral ng Pilipinas
• Bank Negara Malaysia

Value for Mapping

• Establishes scope and depth of mapping required
• Defines expectations for:
• CBS identification
• Dependency mapping
• Scenario testing

Limitations

• May require interpretation and contextualisation
• Vary across jurisdictions

Best Practice

• Align mapping approach with applicable regulations
• Ensure mapping outputs can support regulatory reporting and audits

Data Collection Approach

Structured Data Gathering

Organisations should adopt a structured approach:

1. Identify required data sources
2. Assign data owners
3. Collect and consolidate data
4. Validate data accuracy

Stakeholder Engagement

Data collection should involve:

• Business units
• Technology teams
• Risk and compliance functions
• Vendor management teams

This ensures:

• Completeness of data
• Alignment across functions
• Validation of accuracy

Data Consolidation

Collected data should be:

• Standardised using templates
• Integrated into a central repository
• Prepared for mapping activities

Principle: Data Must Be Complete, Accurate, and Current

A fundamental principle for effective mapping is:

Ensure data is complete, accurate, and current before mapping.

Completeness

• All relevant components and dependencies are captured
• No critical gaps exist

Accuracy

• Data reflects actual operational practices
• Verified against authoritative sources

Currency

• Data is up-to-date
• Reflects recent changes in systems, processes, and vendors

Consequences of Non-Compliance

Failure to meet this principle results in:

• Inaccurate mapping
• Misleading insights
• Increased operational risk

Identifying and gathering the right data sources is a critical step in interconnection mapping, providing the foundation for accurate and meaningful outputs.

By leveraging:

• Internal sources such as process documentation, IT architecture diagrams, and risk registers
• External sources such as vendor SLAs and regulatory requirements

organisations can build a comprehensive dataset that supports effective mapping.

Adhering to the principle of ensuring data is complete, accurate, and current ensures that mapping outputs are reliable and actionable.

In the next chapter, we will explore Step 3: Develop Mapping Framework, where collected data is structured into a coherent model to support interconnection and interdependency analysis.