[OR] [GCash] [E2] [P2] [C8] Five Stages of the "Implement" Phase

Introduction to GCash’s “Implement” Phase of the Operational Resilience Planning Methodology

Introduction

The Implement phase translates GCash’s Operational Resilience strategy into practical, service-level resilience capabilities.

While the earlier Plan phase establishes governance, maturity, priorities, and risk appetite, the Implement phase applies those foundations to the operations that matter most to customers and the organisation.

For GCash, this means identifying the operations that must remain resilient, understanding the people, processes, technology, information, and third parties that support them, defining how much disruption can be tolerated, testing those operations against Severe but Plausible Scenarios, and using the results to continuously strengthen resilience.

Because GCash operates within a highly digital and interconnected financial services environment, this phase should focus on end-to-end service delivery rather than on isolated systems, departments, or recovery plans.

Purpose of the Chapter

The purpose of this chapter is to introduce the reader to the Implement phase of GCash’s Operational Resilience Planning Methodology and explain how its five stages convert strategic resilience intent into operational capability.

The Implement phase is where GCash identifies the operations whose disruption could create material customer or organisational consequences, maps the resources and dependencies needed to deliver them, establishes measurable disruption thresholds, validates resilience through scenario testing and converts identified weaknesses into practical improvements.

This phase therefore provides the bridge between planning and demonstrated resilience capability.

By the end of this chapter, the reader should understand the purpose and sequence of the five Implement stages, and how the output from each stage serves as input to the next.

The reader should also recognise how these activities should be applied to GCash’s digital operating environment, where financial transactions depend on applications, telecommunications, cybersecurity, data, financial institutions, merchants and third-party service providers.

Together, the five stages enable GCash to move from understanding what should be resilient to demonstrating whether its Critical Operations can actually remain within acceptable disruption limits under severe operational stress.

Introduction to GCash’s Operational Resilience Planning Methodology

GCash’s Operational Resilience Planning Methodology can be organised around a lifecycle that progresses from strategic planning to operational implementation and ongoing sustainment.

The Implement phase answers five practical questions:

• What operations must remain resilient?
• What resources and dependencies support them?
• How much disruption can be tolerated?
• Can the operation remain resilient under severe conditions?
• What must be improved based on what we learn?

These questions correspond to five stages:

For alignment with BSP terminology, GCash should interpret Critical Business Services as the methodology equivalent of Critical Operations, and Impact Tolerance as the maximum tolerable level of disruption for those operations.

This allows the methodology to remain consistent while respecting the terminology used by the Bangko Sentral ng Pilipinas.

Phase 2: Implement

The objective of the Implement phase is to establish and validate the resilience of GCash’s most important end-to-end operations.

This phase should produce a practical understanding of:

• which operations are critical;
• how they are delivered;
• what resources they depend on;
• where vulnerabilities exist;
• how much disruption can be tolerated;
• how they perform under severe stress;
• what failures or weaknesses are identified; and
• what remediation is required.

The Implement phase therefore turns the Operational Resilience programme from a governance framework into an operating capability.

Stage 1: Identify Critical Business Services

[Implement Phase – Stage 1]

The first stage is to identify Critical Business Services.

For GCash, this means identifying the customer-facing or operational outcomes whose prolonged disruption could result in material harm to customers, the organisation or relevant participants in the financial ecosystem.

Under the methodology, a Critical Business Service should be defined at an outcome level rather than as an individual application, department or process.

For GCash, potential candidates might include:

• Digital Wallet Operations;
• Payment Transaction Processing;
• Funds Transfer Operations;
• Merchant Payment Services;
• Wallet Funding;
• Customer Account Access; and
• Transaction Settlement and Reconciliation.

These examples would require formal assessment before being designated as Critical Operations.

The identification process should consider:

• number of customers affected;
• financial impact;
• transaction volume and value;
• regulatory consequences;
• operational dependencies;
• customer harm;
• reputational impact; and
• broader financial-system consequences.

Example for GCash

Suppose GCash evaluates Digital Wallet Operations.

The assessment may determine that prolonged unavailability would prevent customers from:

• accessing wallet balances;
• making payments;
• receiving funds;
• transferring money; and
• paying merchants.

Because these outcomes are central to the customer experience, Digital Wallet Operations may be identified as a Critical Operation.

Key Output

The primary output should be a:

Critical Business Service / Critical Operation Register

This should include:

• service or operation name;
• description;
• business owner;
• rationale for criticality;
• customers and stakeholders affected; and
• approval status.

Stage 2: Map Interconnections and Interdependencies

[Implement Phase – Stage 2]

Once a Critical Operation has been identified, GCash should determine how to deliver it end-to-end.

The purpose of Map Interconnections and Interdependencies is to identify all important resources and dependencies required to deliver the Critical Operation.

These may include:

• people;
• business processes;
• applications;
• technology infrastructure;
• data;
• facilities;
• telecommunications;
• third-party providers;
• financial institutions;
• payment networks; and
• external infrastructure.

The mapping should not stop at organisational boundaries.

For GCash, a simplified Digital Wallet mapping may resemble:

Customer

↓

GCash Mobile Application

↓

Authentication

↓

Wallet Platform

↓

Transaction Engine

↓

Database / Ledger

↓

Bank / Payment Interface

↓

Merchant or Recipient

↓

Settlement and Reconciliation

↓

Customer Notification

The purpose of the mapping is to understand where disruption can enter and how it may propagate through the service.

Example for GCash

For Payment Transaction Processing, GCash may identify dependencies such as:

• transaction-processing application;
• authentication service;
• wallet ledger;
• merchant-acquiring interface;
• telecommunications network;
• fraud-detection controls;
• data infrastructure;
• customer notification service; and
• settlement or reconciliation processes.

If one of these dependencies has no practical alternative, it may represent a significant vulnerability to resilience.

Key Output

The key outputs should include:

• end-to-end process maps;
• resource inventories;
• third-party dependency maps;
• technology dependency maps;
• interconnection maps; and
• vulnerability observations.

Stage 3: Set Impact Tolerance

[Implement Phase – Stage 3]

Once the Critical Operation and its dependencies are understood, GCash should define the maximum level of disruption it can tolerate.

The purpose of Set Impact Tolerance is to establish the boundary beyond which disruption would create unacceptable consequences.

For GCash, useful measures may include:

• maximum duration of disruption;
• maximum customers affected;
• maximum transaction volume affected;
• maximum value of delayed transactions;
• maximum backlog;
• maximum service degradation; or
• maximum allowable data loss.

Impact Tolerance should be established from the perspective of customer and business harm rather than from existing recovery capability alone.

The question should not be:

“How quickly can the system recover?”

It should be:

“How long can this Critical Operation be disrupted before the consequences become unacceptable?”

Example for GCash

For Payment Transaction Processing, GCash might determine that the operation should not be unavailable for more than a defined period during peak customer activity.

It may also set complementary measures such as:

• maximum customers affected;
• maximum failed transactions; and
• maximum delayed transaction value.

These thresholds would then guide:

• technology recovery objectives;
• continuity strategies;
• scenario design;
• escalation; and
• resilience investment.

Key Output

The principal output should be an:

Impact Tolerance / Tolerance for Disruption Statement

for each Critical Operation.

Stage 4: Conduct Scenario Testing

[Implement Phase – Stage 4]

Once the Critical Operation, dependencies and Impact Tolerance are defined, GCash should validate its resilience.

The purpose of Conduct Scenario Testing is to expose the Critical Operation to Severe but Plausible Scenarios and assess whether it can remain within its Impact Tolerance.

Scenarios should be:

• relevant;
• realistic;
• sufficiently severe;
• challenging;
• end-to-end;
• measurable; and
• capable of exposing weaknesses.

Possible GCash scenarios could include:

• prolonged application outage;
• ransomware incident;
• telecommunications failure;
• cloud-service disruption;
• payment network outage;
• data corruption;
• simultaneous primary and recovery-environment failure;
• loss of critical staff; or
• cascading third-party failure.

Scenario testing should challenge:

People + Process + Technology + Data + Third Parties + External Dependencies

rather than testing one system in isolation.

Example for GCash

GCash may test Digital Wallet Operations using a Severe but Plausible Scenario involving:

• major cyberattack;
• mobile application degradation;
• partial loss of authentication capability;
• increased customer complaints;
• reduced transaction capacity; and
• failure of one external service provider.

The test would assess:

• whether customers retain access to essential wallet functionality;
• whether alternate processing works;
• whether customer communications are effective;
• whether escalation occurs appropriately;
• whether recovery remains within Impact Tolerance; and
• whether data integrity is preserved.

Key Output

The outputs should include:

• Scenario Test Plan;
• scenario design;
• test observations;
• Impact Tolerance assessment;
• identified vulnerabilities;
• lessons identified; and
• remediation actions.

Stage 5: Improve Lessons Learnt

[Implement Phase – Stage 5]

The final stage of the Implement phase is to Improve Lessons Learnt.

Operational Resilience testing has limited value if identified weaknesses are documented but not addressed.

The purpose of this stage is to convert findings from:

• scenario tests;
• actual incidents;
• near misses;
• cyber exercises;
• disaster recovery tests;
• supplier failures;
• customer complaints; and
• operational events

into measurable resilience improvement.

The process should follow a clear cycle:

Incident or Test

↓

Lesson Identified

↓

Root Cause

↓

Risk Assessment

↓

Remediation

↓

Owner and Deadline

↓

Validation

↓

Closure

↓

Framework Improvement

The goal should be to improve both the Critical Operation itself and the wider Operational Resilience programme.

Example for GCash

Suppose a scenario test reveals that GCash can restore its payment platform within the required time, but transaction reconciliation after failover takes significantly longer than expected.

The lesson identified may therefore be:

Technical recovery meets the target, but reconciliation delays could cause the Critical Operation to exceed its Impact Tolerance.

The improvement action may include:

• automated reconciliation;
• additional processing capacity;
• revised recovery procedures;
• additional staffing during major incidents; and
• retesting of the revised process.

This demonstrates why successful system recovery does not automatically mean that the Critical Operation is resilient.

Key Output

The outputs should include:

• Lessons Identified Register;
• remediation plan;
• action owners;
• target dates;
• evidence of completion; and
• updated resilience documentation.

How the Five Stages Work Together

The five Implement stages form a continuous sequence.

Stage 1

Identify Critical Business Services

Determines what must be resilient.

↓

Stage 2

Map Processes and Resources

Determines what the service depends upon.

↓

Stage 3

Set Impact Tolerance

Determines how much disruption can be accepted.

↓

Stage 4

Conduct Scenario Testing

Determines whether resilience actually works.

↓

Stage 5

Improve Lessons Learnt

Determines how resilience will be strengthened.

Together, these stages create a closed-loop resilience implementation process.

Example Implement Phase for GCash

Relationship Between the Plan and Implement Phases

The Implement phase should not operate independently from the Plan and Sustain phases.

The relationship can be represented as:

The Plan phase provides direction.  The Implement phase demonstrates capability.  Together they form the foundation of a mature Operational Resilience programme.

Integration with Business Continuity Management

The Implement phase should build upon GCash’s existing BCM capabilities.

For example:

The important difference is that Operational Resilience focuses on end-to-end Critical Operations and acceptable limits of disruption, rather than on individual business-unit recovery alone.

Integration with Technology and Cyber Resilience

For GCash, the Implement phase should be closely integrated with Technology and Cybersecurity.

Digital financial services may rely on:

• resilient architecture;
• cyber controls;
• transaction-processing capacity;
• data recovery;
• failover capability;
• authentication services;
• network connectivity; and
• monitoring.

Technology and cyber teams should therefore participate directly in:

• dependency mapping;
• Impact Tolerance assessment;
• scenario design;
• testing; and
• remediation.

Operational Resilience provides the business outcome against which those technical capabilities are assessed.

Integration with Third-Party Risk Management

Critical Operations may depend substantially on external service providers.

GCash should therefore ensure that the Implement phase considers:

• critical provider identification;
• concentration risk;
• subcontractor dependencies;
• provider recovery capability;
• alternative suppliers;
• exit strategies;
• contractual resilience requirements; and
• provider participation in testing.

A Critical Operation cannot be considered resilient if a critical external dependency fails to meet the required Impact Tolerance.

Key Deliverables from the Implement Phase

At completion of the Implement phase, GCash should have a structured set of resilience deliverables.

These should include:

• Critical Business Service / Critical Operation Register;
• Critical Operation ownership records;
• end-to-end process maps;
• dependency and interconnection maps;
• Impact Tolerance statements;
• Severe but Plausible Scenario catalogue;
• Scenario Testing programme;
• scenario test reports;
• lessons identified register;
• remediation action register;
• vulnerability register;
• updated continuity and recovery strategies; and
• evidence of completed improvement actions.

Together, these provide evidence that Operational Resilience has moved beyond planning into implementation.

Implementation Principles for GCash

Several principles should guide the Implement phase.

End-to-End Focus

Assess the complete Critical Operation rather than isolated processes.

Customer Outcome Focus

Measure resilience according to the effect of disruption on customers.

Dependency Awareness

Understand both internal and external dependencies.

Tolerance-Based Assessment

Evaluate performance against defined disruption thresholds.

Severe but Plausible Testing

Test conditions that genuinely challenge existing capabilities.

Cross-Functional Participation

Business, Technology, Cybersecurity, Risk, BCM, and third parties should participate.

Evidence-Based Improvement

Use measurable test evidence rather than assumptions.

Continuous Learning

Every disruption or exercise should strengthen future resilience.

The Implement phase is where GCash converts Operational Resilience planning into demonstrable capability.

Its five stages—Identify Critical Business Services, Map Processes and Resources, Set Impact Tolerance, Conduct Scenario Testing, and Improve Lessons Learnt—create a structured pathway from determining what matters most to validating whether those operations can continue through severe disruption.

Each stage builds on the previous one: Critical Operations establish the focus, mapping establishes the dependency picture, Impact Tolerance establishes the resilience boundary, scenario testing validates capability, and lessons identified drive improvement.

For GCash, this phase is particularly important because digital financial services depend on tightly interconnected technology, telecommunications, data, financial institutions and third-party providers.

Resilience therefore cannot be demonstrated through isolated disaster recovery or BCM exercises alone. It must be demonstrated at the end-to-end Critical Operation level and measured against the organisation’s accepted disruption boundaries.

When these five stages are implemented as a continuous cycle, GCash can progressively strengthen its ability to withstand disruptions, protect customers, address vulnerabilities, and improve resilience across its financial services ecosystem.

Blogs marked [x] are under construction

C1	C2	C8	C14

"Implement" Phase of the Operational Resilience Planning Methodology
C8 [x]	C9 [x]	C10 [x]	C11 [x]	C12 [x]	C13 [x]

Gain Competency: For organisations looking to accelerate their journey, BCM Institute’s training and certification programs, including the OR-5000 Operational Resilience Expert Implementer course, provide in-depth insights and practical toolkits for effectively embedding this model.

 

More Information About OR-5000 [OR-5] or OR-300 [OR-3]

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

	If you have any questions, click to contact us.