[OR] [AIAB] [E3] [CBS] [1] [ST] Perform Scenario Testing

CBS-1 Insurance Policy Application and Issuance

Introduction

Scenario Testing enables AIA Bhd to determine whether CBS-1 Insurance Policy Application and Issuance can continue to be delivered within its defined Impact Tolerance when exposed to Severe but Plausible Scenarios.

The testing programme should assess the complete customer journey—from initial product enquiry and application registration through underwriting, premium confirmation, policy issuance and post-issuance reconciliation—rather than examining individual systems, departments or recovery plans in isolation.

The 20 Sub-CBS processes provide the detailed basis for selecting testing objectives, participants, injects, interdependencies, and measurable resilience outcomes.

Severe but Plausible Scenarios establish the disruptive conditions to which the service will be exposed, while the Impact Tolerance establishes the boundary against which performance and harm are assessed.

Cyber and ICT Risks must be incorporated into the test design because technology, data, connectivity, identity management, digital channels, and third-party services are integral to the delivery of CBS-1

Scenario Testing should therefore examine how people, processes, technology, information, facilities, third parties, and external entities collectively respond during a disruption.

The recommendations below are illustrative implementation proposals. Test scope, Impact Tolerance measures, success criteria, and escalation thresholds should be validated by the relevant business owners, technology owners, risk functions, compliance functions, and senior management of AIA Bhd.

Table 1: Recommended Scenario Tests

Sub-CBS Code	Name of Sub-CBS	Severe but Plausible Scenario	Recommended Scenario Test	Testing Method	Scenario Testing Objective	Key Scenario Injects / Disruption Conditions	Interconnections and Interdependencies Tested
CBS-1.1	Customer Enquiry and Product Selection	Simultaneous failure of digital enquiry channels, telecommunications, and contact-centre access during a surge in customer demand	Conduct an integrated customer-access disruption exercise covering digital, intermediary, and assisted-service channels	Simulation exercise and network resilience test	Determine whether customers can continue obtaining accurate product information and assistance through alternative channels	Website and mobile enquiry functions unavailable; inbound calls degraded; customer demand increases; incorrect product information appears on one channel; social-media complaints escalate	Customer channels, contact centre, intermediaries, product management, telecommunications, digital services, customer communications and incident management
CBS-1.2	Application Initiation and Registration	A failed technology deployment makes application initiation and registration unavailable across major channels, and rollback is unsuccessful	Test controlled recovery and alternative registration arrangements under peak application volumes	Technical recovery test and integrated business-and-technology simulation	Validate that applications can continue to be accepted, uniquely recorded, and prioritised without loss or duplication	Deployment failure; rollback unsuccessful; queues increase; manual registration activated; duplicate application records appear; recovery estimate exceeds initial forecast	Digital application channels, workflow platform, registration database, customer service, technology change management, business continuity and underwriting intake
CBS-1.3	Customer Identity Verification and Due Diligence	A cyber incident compromises the availability and integrity of automated identity-verification services	Exercise the suspension of automated verification and activation of approved alternative identity and due diligence procedures	Cyber incident simulation and third-party disruption exercise	Assess whether identity checks can continue securely without exposing AIA Bhd to unacceptable fraud, compliance, or customer risks	Identity service unavailable; integrity warning issued; fraudulent applications introduced; third party cannot confirm restoration time; application backlog grows	Identity-verification provider, compliance, financial crime controls, customer records, application processing, cybersecurity, legal and third-party management
CBS-1.4	Application Data Capture and Document Management	Ransomware encrypts application documents and disrupts access to supporting evidence	Test cyber containment, document recovery, and continued processing using trusted information sources	Cyber incident simulation, technical recovery test, and data-integrity test	Validate that application information can be protected, recovered, and reconstructed within the required service boundary	Document repository encrypted; recent backups suspected of compromise; some files altered; remote access disabled; underwriting requests urgent documents	Document management, application workflow, cybersecurity, data backup, underwriting, medical evidence, legal, privacy and technology recovery
CBS-1.5	Application Completeness and Eligibility Validation	Corrupted validation rules incorrectly approve incomplete applications and reject eligible applications	Conduct a rules-integrity and business-reconciliation test involving a large affected application population	Data integrity and reconciliation test	Determine whether rule corruption can be detected, contained, and corrected before widespread customer harm occurs	Defective rule introduced; monitoring fails; complaint identifies incorrect result; affected population expands; rollback creates inconsistent decisions	Product rules, application data, quality assurance, underwriting, technology change management, customer complaints and compliance
CBS-1.6	Initial Risk Classification and Underwriting Triage	Automated risk-classification capacity becomes exhausted during an unexpected surge in applications	Stress the triage process and test manual and risk-based prioritisation arrangements	Capacity and stress test with operational simulation	Assess whether minimum underwriting throughput and appropriate risk routing can be sustained during severe degradation	Application volumes exceed forecast; classification latency rises; applications misrouted; manual capacity reduced; high-risk cases enter standard queues	Application workflow, automated risk classification, underwriting teams, workforce management, infrastructure capacity and operational monitoring
CBS-1.7	Medical Evidence and Examination Coordination	A regional emergency substantially reduces the availability of medical examination providers, while associated digital interfaces are disrupted	Exercise alternative medical-evidence arrangements and prioritisation of affected applications	Third-party disruption exercise and tabletop simulation	Determine whether applications requiring medical evidence can continue to progress through approved alternative arrangements	Multiple medical providers unavailable; appointments cancelled; evidence portal fails; customers cannot travel; urgent applications require decisions	Medical providers, underwriting, customer communications, digital interfaces, procurement, third-party risk management and clinical advisers
CBS-1.8	Financial and Specialist Underwriting Assessment	Widespread specialist staff absence coincides with the failure of secure remote access	Test minimum specialist underwriting capacity using cross-trained personnel, alternate locations, and delegated decision arrangements	Simulation exercise and business continuity test	Validate that complex applications can be assessed safely when specialist personnel and normal working arrangements are unavailable	Specialist absence exceeds 50%; remote access is unstable; complex-case volumes increase; delegated authority limits are reached; fatigue develops	Specialist underwriters, human resources, secure access, alternate facilities, workforce planning, medical evidence and senior underwriting authority
CBS-1.9	External Risk Referral and Reinsurance Review	A cyber incident at a critical external risk or reinsurance counterparty prevents secure referrals and responses	Test alternative referral routes, counterparty escalation, and controlled treatment of applications awaiting external review	Third-party disruption exercise and cyber simulation	Assess whether externally referred applications can be managed without uncontrolled risk acceptance or excessive delay	Counterparty systems isolated; secure connection disabled; confidential data potentially exposed; response times unknown; high-value applications accumulate	Reinsurance counterparties, external specialists, underwriting, cybersecurity, legal, privacy, secure communications and third-party management
CBS-1.10	Underwriting Decision and Approval	Privileged credentials are compromised, and unauthorised underwriting approvals may have been issued	Conduct an integrated cyber, access-governance, and business-decision integrity exercise	Cyber incident simulation and data-integrity test	Validate rapid containment of compromised access while preserving controlled approval capability	Abnormal privileged activity detected; approvals questioned; account suspension affects legitimate users; audit trails incomplete; urgent decisions pending	Identity and access management, underwriting authority, cybersecurity, audit logs, compliance, internal audit and policy configuration
CBS-1.11	Decision Communication and Customer Acceptance	Communication gateways fail, preventing underwriting decisions and revised terms from reaching customers	Test alternative communication and secure customer-acceptance procedures	Walk-through test followed by communication simulation	Determine whether customers can receive decisions and provide valid acceptance through alternative channels	Email and messaging gateway unavailable; call capacity constrained; customer contact details incomplete; disputed acceptance received; backlog increases	Customer communication, contact centre, intermediaries, legal, application workflow, identity verification and customer records
CBS-1.12	Initial Premium and Payment Confirmation	Payment records become unsynchronised with application records, resulting in missing, duplicate, and incorrectly allocated payments	Conduct an end-to-end payment integrity and reconciliation exercise	Data integrity and reconciliation test	Validate that successful payments can be accurately identified, matched, and confirmed before policy activation	Payment interface fails; duplicate records appear; bank confirmation is delayed; customers provide receipts; reconciliation volume exceeds normal capacity	Payment services, banking interfaces, finance, application records, policy configuration, customer service and exception management
CBS-1.13	Pre-Issuance Policy Configuration	A failed configuration change introduces incorrect coverage, premium, or policy conditions across pending applications	Test detection, containment, rollback, and reconstruction of affected policy configurations	Technical recovery test and data-integrity simulation	Determine whether incorrect configurations can be prevented from reaching policy issuance, and whether affected records can be corrected	Configuration defect introduced; sample control initially misses error; affected population expands; rollback fails for some records; issuance deadline approaches	Product configuration, underwriting decisions, premium records, change management, quality assurance, policy generation and compliance
CBS-1.14	Policy Document Generation and Quality Validation	Policy documents are generated with missing, inaccurate, or inconsistent contractual information	Conduct a bulk document-integrity, containment, and regeneration test	Data integrity and reconciliation test	Validate the detection of inaccurate documents and controlled regeneration without issuing incorrect contractual records	Defective template deployed; document samples differ from source records; some documents delivered; regeneration capacity constrained; customer enquiries rise	Document-generation capability, policy data, quality assurance, legal, customer delivery, application records and document management
CBS-1.15	Policy Issuance, Activation and Delivery	Primary and recovery issuance environments fail simultaneously because of a common technology dependency	Conduct a full end-to-end failover and alternate issuance simulation	Disaster recovery test, failover test, and integrated business-and-technology simulation	Demonstrate that policy issuance, activation, and delivery can resume within Impact Tolerance despite common-mode failure	Primary environment unavailable; recovery environment fails; shared identity service lost; manual issuance activated; delivery channels degraded	Issuance infrastructure, recovery environment, identity services, policy records, customer delivery, business continuity, crisis management and technology vendors
CBS-1.16	Post-Issuance Handover and Reconciliation	API failure prevents issued policy records from transferring correctly to downstream administration and servicing processes	Test store-and-forward, controlled replay, and downstream reconciliation arrangements	API resilience test and data-reconciliation test	Determine whether issued policies can be accurately handed over after prolonged interface disruption	API unavailable; messages queue; some records duplicated; downstream servicing receives incomplete data; recovery replay begins out of sequence	Policy administration, customer servicing, finance, APIs, integration services, policy issuance and data reconciliation
CBS-1.17	Application and Issuance Exception Management	Multiple upstream disruptions create exception volumes beyond available manual processing capacity	Conduct a surge-capacity and prioritisation simulation integrated with upstream scenario tests	Capacity and stress test with operational simulation	Validate that critical exceptions can be identified, prioritised, and resolved without losing application integrity	Exception volumes increase tenfold; specialist staff unavailable; duplicate cases appear; priority criteria conflict; customer complaints escalate	All upstream Sub-CBS processes, specialist teams, workflow queues, customer service, risk, compliance and workforce management
CBS-1.18	Application Status Monitoring and Service Control	Monitoring and alerting controls fail during progressive service degradation	Conduct a monitoring-blindness and delayed-escalation exercise	Simulation exercise and cyber-monitoring test	Assess whether independent service indicators enable timely detection and escalation before Impact Tolerance is threatened	Dashboard shows normal status; queues grow; customer complaints provide first warning; technical alerts are suppressed; management information conflicts	Service monitoring, incident management, customer complaints, application workflow, cybersecurity, technology operations and senior management
CBS-1.19	Disruption Response and Alternate Processing	A major cyber incident requires primary processing to be isolated, but alternate arrangements cannot sustain expected transaction volumes	Conduct an integrated cyber, business continuity, and crisis management exercise	End-to-end Critical Business Service test and crisis management exercise	Validate that alternate processing can sustain prioritised service delivery during prolonged cyber containment	Core processing isolated; alternate capacity reaches limit; remote access restricted; customer demand rises; media enquiries begin; recovery timeline extends	Cyber response, business continuity, crisis management, customer channels, underwriting, payment processing, technology recovery and communications
CBS-1.20	Service Recovery, Reconciliation, and Restoration	Recovery produces conflicting application, underwriting, payment, and policy records across multiple data sources	Conduct a full-service restoration, data integrity, and reconciliation exercise	End-to-end CBS scenario test and data-reconciliation test	Demonstrate that CBS-1 can be restored accurately, safely, and within Impact Tolerance without uncontrolled data loss or duplication	Multiple recovery points identified; records conflict; automated reconciliation fails; unresolved exceptions remain; pressure increases to resume service	All Sub-CBS processes, data recovery, finance, underwriting, policy administration, technology recovery, customer service, risk and senior management

Table 2: Impact Tolerance, Evidence and Proactive Risk Management

Sub-CBS Code	Name of Sub-CBS	Cyber and ICT Risk Linkage	Impact Tolerance Boundary Tested	Expected Resilience Outcome	Evidence to be Collected	Proactive Risk Management Action	Evidence of Proactive Risk Management
CBS-1.1	Customer Enquiry and Product Selection	Digital-channel, network, telecommunications, and availability risks act as primary triggers and disruption amplifiers	Maximum tolerable loss or severe degradation of major customer enquiry channels; customer population affected; duration before material harm develops	Approved alternative channels remain available and provide accurate, consistent information	Channel-availability records, traffic volumes, call statistics, customer complaints, escalation records, and communication logs	Diversify customer-access channels and establish channel redirection and demand-management thresholds	Network resilience reports, channel failover tests, updated procedures and remediation closure records
CBS-1.2	Application Initiation and Registration	Failed deployment, database availability, and rollback failure affect application acceptance and record integrity	Maximum period during which applications cannot be accepted or uniquely registered; number of lost or duplicated applications	Applications continue to be captured through controlled alternatives without loss, duplication, or unauthorised processing	Recovery measurements, application counts, duplicate records, queue volumes, decision logs, and reconciliation results	Strengthen deployment controls, automated rollback and alternative registration capacity	Change-control reviews, rollback test results, recovery test reports and approved remediation records
CBS-1.3	Customer Identity Verification and Due Diligence	Cyber compromise or third-party ICT failure affects identity, data integrity, confidentiality, and availability	Maximum acceptable duration of verification disruption and level of exposure to fraud or incomplete due diligence	Secure alternative verification supports prioritised applications without weakening mandatory controls	Cyber logs, verification outcomes, fraud indicators, backlog data, third-party communications, and compliance decisions	Establish alternative verification arrangements and independent integrity-validation procedures	Cyber-assessment reports, third-party assurance, tested procedures and governance approval
CBS-1.4	Application Data Capture and Document Management	Ransomware, storage compromise, and backup corruption threaten the availability and integrity of customer documents	Maximum tolerable loss of document availability; acceptable data-loss boundary; affected application volume	Trusted documents are recovered, and priority applications continue through controlled workarounds	Cybersecurity logs, restoration time, backup validation, document-reconciliation results, and application backlog	Maintain segmented immutable recovery copies and tested document reconstruction procedures	Recovery test results, backup integrity reports, ransomware exercise reports and closed remediation actions
CBS-1.5	Application Completeness and Eligibility Validation	Data or software corruption produces inaccurate validation decisions	Maximum number and duration of incorrectly processed applications before severe customer, legal, or regulatory harm arises	Rule corruption is detected quickly, affected records are isolated, and decisions are corrected	Rule versions, transaction samples, detection time, affected population, correction results, and complaint data	Implement automated rule-integrity monitoring and controlled validation-rule rollback	Control-testing reports, change approvals, quality assurance reports and management review minutes
CBS-1.6	Initial Risk Classification and Underwriting Triage	Capacity exhaustion and severe application latency disrupt routing and prioritisation	Maximum sustainable degradation in processing capacity, queue size, and decision latency	Priority and higher-risk applications remain appropriately routed while minimum throughput is maintained	Capacity metrics, processing latency, queue age, routing accuracy, and staffing utilisation	Establish demand thresholds, elastic capacity, and tested manual triage procedures	Capacity test results, approved operating thresholds, workforce plans and exercise reports
CBS-1.7	Medical Evidence and Examination Coordination	Third-party ICT outage and connectivity failure amplify the loss of medical service availability	Maximum acceptable delay for obtaining required evidence and proportion of affected applicants	Alternative evidence and providers support risk-based continuation without unsafe underwriting	Provider availability, appointment delays, evidence turnaround time, customer impact, and underwriting decisions	Diversify medical-provider capacity and establish approved alternative-evidence criteria	Third-party assurance reports, continuity clauses, provider exercise records and updated underwriting guidance
CBS-1.8	Financial and Specialist Underwriting Assessment	Secure-access, authentication, and remote-working failures amplify the loss of specialist personnel	Minimum specialist decision capacity and maximum tolerable backlog age for complex applications	Cross-trained resources and delegated authority maintain a safe minimum underwriting capacity	Staffing levels, decision volumes, backlog age, access records, errors, and escalation decisions	Build cross-trained specialist pools and resilient remote-access arrangements	Skills matrix, competency records, access tests, BCP exercises and delegated-authority approvals
CBS-1.9	External Risk Referral and Reinsurance Review	Third-party cyber disruption affects secure connectivity, data confidentiality, and referral availability	Maximum duration and volume of external referrals awaiting decision before service harm becomes intolerable	Alternative referral and escalation arrangements manage priority applications within approved risk limits	Third-party communications, referral backlog, decision times, security assessment, and exception approvals	Establish alternative counterparties or referral pathways and document risk-acceptance limits	Third-party risk assessments, contractual continuity provisions, cyber assurance and exercise reports
CBS-1.10	Underwriting Decision and Approval	Privileged-access compromise affects approval integrity and non-repudiation	Maximum duration of approval suspension and number of decisions requiring revalidation	Compromised access is contained, while controlled approval capability continues	Access logs, approval records, containment time, affected decisions, and revalidation results	Strengthen privileged-access management, behavioural monitoring and emergency approval procedures	Access reviews, penetration tests, incident simulations, audit reports and remediation closure
CBS-1.11	Decision Communication and Customer Acceptance	Communication-gateway and network failures affect message delivery and secure digital acceptance	Maximum delay in communicating decisions and obtaining customer acceptance	Decisions and acceptance requests continue through secure, approved alternative channels	Delivery records, customer-response times, authentication evidence, dispute records, and backlog levels	Maintain alternative communication and acceptance channels with identity controls	Communication tests, approved legal procedures, exercise records and channel assurance reports
CBS-1.12	Initial Premium and Payment Confirmation	Interface, synchronisation, or database failure compromises payment-record integrity	Maximum value and volume of unresolved payments; maximum confirmation delay; zero tolerance for uncontrolled financial loss	Payments are independently verified and accurately matched before policy activation	Transaction records, reconciliation differences, duplicate entries, resolution times, and customer evidence	Implement independent payment reconciliation and controlled exception queues	Reconciliation test reports, financial control reviews, interface monitoring and audit evidence
CBS-1.13	Pre-Issuance Policy Configuration	Failed changes or data corruption affect coverage, premium, and policy conditions	Maximum number of incorrectly configured policies and period before detection	Incorrect configurations are contained before issuance, and affected applications are reconstructed accurately	Configuration logs, sample-testing results, affected records, rollback outcomes, and correction time	Introduce automated configuration validation and controlled version rollback	Change testing, control attestations, quality reports, architecture review and remediation closure
CBS-1.14	Policy Document Generation and Quality Validation	Template, software, or data-integrity failures produce inaccurate contractual documents	Maximum affected policy volume and duration before the correct documents can be delivered	Defective documents are detected, contained, and regenerated without uncontrolled issuance	Document samples, validation failures, affected population, regeneration time, and customer notifications	Strengthen document-template integrity controls and scalable regeneration capability	Quality-control results, deployment records, integrity tests and after-action reviews
CBS-1.15	Policy Issuance, Activation and Delivery	Infrastructure outage, common-mode dependency and recovery-environment failure prevent issuance	Maximum tolerable period without policy activation and delivery; affected customer volume; data-integrity boundary	Issuance resumes through an isolated recovery or a controlled alternate process within Impact Tolerance	Failover times, activation records, policy counts, delivery evidence, customer impact, and decision logs	Remove common-mode dependencies and strengthen isolated recovery capability	Architecture resilience reviews, DR tests, failover reports, investment approvals and remediation closure
CBS-1.16	Post-Issuance Handover and Reconciliation	API outage and message duplication affect downstream data integrity and service availability	Maximum queue size and delay for downstream handover; zero tolerance for unreconciled policy loss	Records are retained, replayed in sequence, and reconciled before normal servicing resumes	API logs, message queues, duplicate records, reconciliation results, and downstream confirmation	Implement resilient message storage, controlled replay and automated reconciliation	API tests, architecture reviews, reconciliation reports and recovery procedures
CBS-1.17	Application and Issuance Exception Management	Upstream ICT failures generate exception volumes beyond manual capacity	Maximum exception backlog, age, and proportion of unresolved priority cases	Exceptions are prioritised, controlled, and resolved without loss of application integrity	Exception volumes, case ageing, resolution accuracy, staffing utilisation, and customer impact	Establish scalable exception capacity and risk-based prioritisation thresholds	Capacity assessments, workforce plans, tested procedures and management approvals
CBS-1.18	Application Status Monitoring and Service Control	Failure or compromise of monitoring tools delays detection and incident escalation	Maximum time between material service degradation and management detection; proximity to Impact Tolerance	Independent business and customer indicators identify degradation before severe harm arises	Monitoring records, complaint trends, detection time, escalation logs and dashboard discrepancies	Implement end-to-end CBS indicators independent of individual system monitoring	Monitoring-control tests, approved indicators, governance reports and incident review findings
CBS-1.19	Disruption Response and Alternate Processing	Cyber containment, remote-access failure, and insufficient alternate capacity combine to prolong disruption	Maximum sustainable alternate-processing duration and minimum service volume required to remain within tolerance	Prioritised application processing continues while cyber containment and recovery are performed	Transaction throughput, alternate-capacity usage, recovery forecasts, crisis decisions, and customer impacts	Integrate cyber response, BCM, crisis management, and business workaround testing	Integrated exercise reports, incident playbooks, remediation plans, senior management minutes and closure evidence
CBS-1.20	Service Recovery, Reconciliation, and Restoration	Conflicting recovery points, database corruption, and failed automated reconciliation delay restoration	Maximum restoration duration; acceptable data-loss boundary; zero tolerance for unidentified missing or duplicate policies	End-to-end service is restored from a trusted state, and all material discrepancies are resolved or controlled	Recovery times, record counts, reconciliation differences, unresolved exceptions, approvals, and customer-impact assessments	Establish trusted recovery points, restoration gates, and end-to-end reconciliation criteria	DR reports, data-integrity tests, approved recovery playbooks, Internal Audit reviews and remediation closure

Integrated End-to-End Scenario Testing Programme

The 20 Sub-CBS tests should not be treated as 20 unrelated exercises.

The testing programme should combine related Sub-CBS processes into a smaller number of coordinated tests that examine how disruption propagates across CBS-1.

The Integrated End-to-End Scenario Testing specifically requires the programme to avoid recommending isolated tabletop exercises that fail to challenge service interconnections.

Integrated Test 1: Loss of Customer Access and Application Intake

This test should combine:

CBS-1.1 Customer Enquiry and Product Selection
CBS-1.2 Application Initiation and Registration
CBS-1.3 Customer Identity Verification and Due Diligence
CBS-1.4 Application Data Capture and Document Management
CBS-1.18 Application Status Monitoring and Service Control
CBS-1.19 Disruption Response and Alternate Processing

The scenario should assume that a cyberattack and telecommunications disruption make major digital application channels unavailable.

Automated identity verification and document access are also impaired. Customer demand increases as applicants seek alternative channels.

The test should assess whether AIA Bhd can detect the disruption, communicate accurately, activate alternative intake methods, protect customer information, prevent duplicate applications and maintain a minimum level of service within Impact Tolerance.

Integrated Test 2: Underwriting Capacity and Third-Party Disruption

This test should combine:

CBS-1.5 Application Completeness and Eligibility Validation
CBS-1.6 Initial Risk Classification and Underwriting Triage
CBS-1.7 Medical Evidence and Examination Coordination
CBS-1.8 Financial and Specialist Underwriting Assessment
CBS-1.9 External Risk Referral and Reinsurance Review
CBS-1.10 Underwriting Decision and Approval
CBS-1.17 Application and Issuance Exception Management

The scenario should involve corrupted validation rules, loss of a major medical service provider, disruption to external risk referrals, and simultaneous loss of specialist underwriters.

The combined event should create severe backlogs, unreliable automated decisions and high exception volumes.

The test should evaluate prioritisation, delegated authority, third-party escalation, manual processing capacity, risk acceptance, workforce resilience and the ability to prevent unsafe or unauthorised underwriting decisions.

Integrated Test 3: Payment, Configuration and Policy Issuance Failure

This test should combine:

CBS-1.11 Decision Communication and Customer Acceptance
CBS-1.12 Initial Premium and Payment Confirmation
CBS-1.13 Pre-Issuance Policy Configuration
CBS-1.14 Policy Document Generation and Quality Validation
CBS-1.15 Policy Issuance, Activation and Delivery

The scenario should assume that payment information becomes unsynchronised while a defective configuration release produces inaccurate policy information.

The primary issuance platform then fails, and the recovery environment cannot be activated because of a common technology dependency.

The test should assess whether AIA Bhd can prevent incorrect policies from being issued, identify valid payments, communicate with affected customers, activate controlled alternate processing and recover issuance within Impact Tolerance.

Integrated Test 4: Downstream Handover and Service Restoration

This test should combine:

CBS-1.16 Post-Issuance Handover and Reconciliation
CBS-1.17 Application and Issuance Exception Management
CBS-1.18 Application Status Monitoring and Service Control
CBS-1.19 Disruption Response and Alternate Processing
CBS-1.20 Service Recovery, Reconciliation and Restoration

The scenario should begin after a prolonged outage. Multiple data sources contain conflicting records, downstream APIs remain unstable, and exception queues exceed available capacity.

The test should determine whether AIA Bhd can establish a trusted recovery point, reconcile records, prioritise customer cases, restore downstream handover and demonstrate that the complete Critical Business Service—not merely the technology platform—has returned to an acceptable operating state.

Scenario Test Design and Governance

Each integrated test should be supported by an approved Scenario Test design profile containing:

The Critical Business Service and Sub-CBS processes in scope;
The Severe but Plausible Scenario
The Impact Tolerance is being tested;
starting assumptions and preconditions;
The scenario timeline;
planned and contingency injects;
participants, observers, controllers, and facilitators;
escalation triggers and decision points;
technology, cyber, operational, and third-party dependencies;
success and failure criteria;
evidence-collection requirements;
safety and control arrangements;
after-action review requirements; and
Responsibility for remediation.

The test should be designed to challenge assumptions rather than demonstrate that existing controls operate successfully.

Test controllers should be permitted to introduce additional injections where participants resolve the initial disruption too easily or where an untested concentration point becomes apparent.

The uploaded requirements specifically provide that Scenario Testing should be sufficiently challenging to expose weaknesses and should not be designed solely to confirm existing controls.

Participants and Responsibilities

Senior Management

Senior management should confirm the test scope, approve material assumptions, participate in critical decision-making and determine whether service degradation remains acceptable.

Management should also review Impact Tolerance assessments, approve remediation priorities and resolve resource or investment constraints.

Critical Business Service Owner

The CBS owner should ensure that the test evaluates end-to-end delivery of the Insurance Policy Application and Issuance.

The owner should coordinate Sub-CBS owners, assess customer and service harm and confirm whether the service remained within Impact Tolerance.

Business and Operational Teams

Customer service, application processing, underwriting, policy administration, finance, exception management and operational control teams should execute the relevant response procedures and workarounds.

Their participation should test actual capacity, authority, skills, and coordination rather than theoretical knowledge of plans.

Technology and ICT Risk Teams

Technology teams should test monitoring, containment, failover, recovery, data restoration, interface recovery and performance management. ICT Risk professionals should challenge recovery assumptions, concentration risks and the adequacy of technology resilience controls.

Cybersecurity Teams

Cybersecurity participants should test detection, investigation, containment, escalation and recovery coordination.

Cyber events should be integrated into the broader service scenario and not conducted as separate technical exercises.

Business Continuity and Crisis Management Teams

Business Continuity professionals should coordinate alternate processing, resource relocation and continuity procedures.

Crisis Management teams should evaluate strategic decision-making, escalation, stakeholder communication, and management of prolonged disruption.

Risk, Compliance, Legal and Internal Audit

Risk and Compliance should assess whether decisions remain within approved risk parameters and regulatory obligations. Legal should advise on contractual, privacy and customer issues.

Internal Audit or an independent observer may assess the adequacy and reliability of test design, execution and evidence.

Third Parties

Critical third parties should participate where their services materially support identity verification, medical evidence, payment processing, telecommunications, external risk referrals, reinsurance, cloud services or other important dependencies.

Where direct participation is unavailable, the test should simulate third-party decisions, response limitations and communication delays.

Measuring Performance Against Impact Tolerance

The Impact Tolerance for CBS-1 should not be evaluated solely as a recovery time. The test should examine multiple dimensions of service harm, including:

the duration of disruption;
the number and proportion of affected applicants;
the number of applications that cannot progress;
the age and size of processing backlogs;
the minimum sustainable application and issuance capacity;
the number of lost, duplicated or corrupted records;
payment and financial integrity;
the accuracy of underwriting and policy decisions;
the availability of customer communication channels;
the ability to prioritise vulnerable or urgent customers;
the extent of regulatory, legal or contractual exposure; and
the point at which customer or organisational harm becomes intolerable.

Illustrative service indicators could include:

Impact Tolerance Dimension	Illustrative Measure
Disruption duration	Time from loss of normal service until the minimum acceptable end-to-end delivery is restored
Customer impact	Number and proportion of customers unable to apply, accept terms, pay, or receive policies
Processing capacity	Minimum percentage of normal application and issuance throughput sustained
Backlog	Maximum application volume and ageing that can be managed without severe harm
Data integrity	Number of missing, duplicated, corrupted or unreconciled application and policy records
Payment integrity	Value and volume of payments that cannot be accurately confirmed
Decision integrity	Number of underwriting or approval decisions requiring revalidation
Communication	Maximum delay in informing affected customers and relevant stakeholders
Third-party dependency	Duration for which a critical external service can remain unavailable
Recovery integrity	Time required to establish a trusted recovery state and complete material reconciliation

These measures are illustrative and should be validated against the formally approved Impact Tolerance for CBS-1.

Integration of Cyber and ICT Risks

Cyber and ICT Risks should be embedded within every relevant test as triggers, contributing events or disruption amplifiers.

The testing programme should assess more than technical recovery.

It should demonstrate how cyber and ICT disruptions affect service delivery and how operational teams continue to serve customers while technical containment and recovery are underway.

Relevant capabilities to test include:

cybersecurity monitoring and detection;
identification of compromised systems or data;
incident classification and escalation;
privileged-access containment;
isolation of affected technology;
preservation of trusted data;
activation of recovery environments;
restoration from validated recovery points;
network and API resilience;
recovery from failed technology changes;
management of degraded system performance;
manual and alternative processing;
coordination between cyber, technology, business continuity and crisis teams; and
communication with customers, management, regulators and third parties.

The prompt expressly requires Cyber and ICT Risks to be incorporated into the end-to-end Scenario Testing programme rather than treated as a separate technical testing stream.

Evidence Collection

Evidence should be captured throughout preparation, execution, observation and remediation. Appropriate evidence includes:

approved Scenario Test plans;
test design profiles;
documented objectives and scope;
participant, observer and controller records;
scenario timelines and inject logs;
system-monitoring records;
cybersecurity alerts and event logs;
incident-escalation records;
crisis-management decision logs;
recovery-time measurements;
transaction and service-volume reports;
application backlog and ageing reports;
data-integrity and reconciliation results;
failover and recovery test results;
third-party participation records;
customer-impact assessments;
Impact Tolerance assessment results;
observer reports;
after-action review reports;
lessons identified registers;
remediation plans;
management and Board reporting;
independent assurance findings; and
remediation closure evidence.

These forms of evidence correspond with the documentation requirements contained in the uploaded Scenario Testing prompt.

Evidence should demonstrate not only that a test occurred, but also:

what was tested;
which assumptions were challenged;
how the service performed;
whether Impact Tolerance was threatened or breached;
which weaknesses were identified;
what management decisions were made;
which remedial actions were approved;
who is accountable for implementation; and
whether the remediation was subsequently validated.

Lessons Identified and Remediation

AIA Bhd should distinguish among observations, identified lessons, and completed improvements.

An observation is something noted during the test, such as delayed escalation or insufficient alternate-processing capacity.

A lesson identified explains why the observation matters and what it reveals about the resilience of CBS-1.

A remediation action is the approved measure required to address the vulnerability.

A lesson learnt should be recognised only after the remediation has been implemented, tested and shown to be effective.

Each remediation action should include:

the relevant test finding;
the affected Sub-CBS and dependency;
the risk or service harm addressed;
the proposed corrective action;
accountable owner;
target completion date;
required budget or resources;
interim risk treatment;
implementation evidence;
validation method;
residual risk; and
closure approval.

Material weaknesses should be escalated to the appropriate management committee or Board Risk Committee, particularly where the test indicates that CBS-1 may breach its Impact Tolerance.

Regulatory Considerations for Scenario Testing by a Malaysian Financial Services Institution

The prompt requires consideration of the 2025 BNM Discussion Paper on Operational Resilience, including expectations concerning Critical Business Services, Impact Tolerance, Severe but Plausible Scenarios, interdependencies, cyber resilience, third parties, recovery, governance, lessons identified and continuous improvement.

The referenced regulatory file was not included with the uploaded materials, and an authoritative copy could not be verified from the available public search results. Consequently, this section does not attribute the recommendations below directly to BNM.

They are presented as implementation recommendations derived from good practice in Operational Resilience and the regulatory themes specified in the user-provided prompt.

Critical Business Service Focus

A Malaysian FSI should design tests around disruption to an identified Critical Business Service rather than around the recovery of an individual application or department.

For AIA Bhd, the relevant question is whether Insurance Policy Application and Issuance remains deliverable within its Impact Tolerance.

Severe but Plausible Scenarios

Test scenarios should be severe enough to challenge normal response and recovery capability while remaining credible within the operating environment.

Scenarios may combine cyber incidents, technology failures, people disruption, third-party outages and data-integrity failures.

Impact Tolerance

Each test should assess performance against a formally defined Impact Tolerance.

The assessment should cover the duration of disruption and the level of customer, financial, operational, legal, regulatory, and data-integrity harm.

Interconnections and Interdependencies

The test should challenge mapped dependencies across people, processes, technology, information, facilities, third parties and external entities.

It should identify concentration risks, single points of dependency and common-mode failures.

Cyber and Technology Resilience

Cyber and ICT events should be incorporated into the service disruption pathway.

Scenario Testing should evaluate detection, containment, operational workarounds, failover, data restoration, reconciliation and end-to-end service recovery.

Third-Party Participation

Where critical service delivery depends on external organisations, the test should assess the availability, response capability and recovery commitments of those parties.

Contractual continuity provisions should not be accepted as evidence of resilience without appropriate assurance or testing.

Governance and Oversight

Senior management should approve the Scenario Testing framework, confirm the Critical Business Services and Impact Tolerances being tested, review material findings and ensure that remediation is completed.

Material vulnerabilities should be reported to the appropriate Board or Board Risk Committee.

Lessons and Continuous Improvement

Scenario Testing findings should be incorporated into risk assessments, business continuity arrangements, technology-resilience programmes, third-party management, crisis management procedures, training and investment planning.

Repeat testing should verify whether remediation has improved service resilience.

Illustrative Annual Scenario Testing Programme

Testing Period	Recommended Test	Main Sub-CBS Coverage	Primary Purpose
Quarter 1	Customer access and application-intake disruption	CBS-1.1 to CBS-1.4, CBS-1.18 and CBS-1.19	Test customer access, cyber response, alternative intake and service monitoring
Quarter 2	Underwriting and third-party capacity disruption	CBS-1.5 to CBS-1.10 and CBS-1.17	Test decision integrity, specialist capacity, medical providers and external referrals
Quarter 3	Payment, configuration and policy-issuance failure	CBS-1.11 to CBS-1.15	Test payment integrity, configuration controls, document generation, failover and policy delivery
Quarter 4	End-to-end recovery and reconciliation	CBS-1.16 to CBS-1.20, with upstream representation	Test downstream handover, restoration, data integrity, exceptions and complete service recovery
Following cycle	Targeted remediation validation	Sub-CBS processes with material findings	Confirm that corrective actions have been implemented and are effective

Higher-risk scenarios or unresolved vulnerabilities should be tested more frequently.

Material technology changes, new third-party dependencies, major incidents, significant product changes or changes to the Impact Tolerance should also trigger a review of the testing programme.

Success Criteria

A Scenario Test should not automatically be classified as successful merely because participants completed the exercise or the technology was restored. Success should be assessed against measurable criteria such as:

disruption was detected within the required period;
appropriate escalation occurred;
decision-making authority was clear;
customers received timely and accurate communication;
priority applications continued to be processed;
alternative arrangements operated at the required capacity;
data remained protected and reconcilable;
underwriting and approval integrity was maintained;
payments were accurately matched;
policy documents and records remained correct;
downstream handover was controlled;
service was restored within Impact Tolerance;
material exceptions were identified and managed;
third-party responses met required expectations; and
remediation actions were assigned and approved.

A test that identifies significant weaknesses may still be valuable and properly executed.

The purpose of Scenario Testing is to reveal vulnerabilities before a real disruption causes intolerable harm, not merely to produce a favourable result.

Banner [Summing] [OR] [E3] Perform Scenario Testing

Scenario Testing is essential for validating whether the CBS-1 Insurance Policy Application and Issuance can remain within its defined Impact Tolerance during severe disruption.

Sub-CBS-level analysis enables AIA Bhd to identify specific vulnerabilities, while integrated testing demonstrates how disruption can propagate across the complete customer journey.

Severe but Plausible Scenarios provide the conditions under which resilience is challenged, and Impact Tolerance supplies the boundary against which performance and harm are assessed.

Embedding Cyber and ICT Risks within business, operational, third-party, and recovery scenarios strengthens the programme's realism and value.

Evidence collected during the tests should demonstrate preparedness, management oversight, and proactive risk management.

Test findings should then be translated into identified lessons, accountable remediation actions, resilience investments, and repeat testing, so that Scenario Testing becomes a continuing driver of Operational Resilience improvement rather than a standalone compliance exercise.

eBook 3: Starting Your OR Implementation
CBS-1 Insurance Policy Application and Issuance
CBS-1 DP	CBS-1 MII	CBS-1 ITo	CBS-1 SbPS	CBS-1 ST

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 and OR-5000 Operational Resilience Expert Implementer courses.



	If you have any questions, click to contact us.

Strengthening Operational Resilience at AIA Bhd: An Enterprise Implementation Guide

[OR] [AIAB] [E3] [CBS] [1] [ST] Perform Scenario Testing

Operational Resilience Planner-Specialist-Expert

CBS-1 Insurance Policy Application and Issuance

Introduction

Integrated End-to-End Scenario Testing Programme

Integrated Test 1: Loss of Customer Access and Application Intake

Integrated Test 2: Underwriting Capacity and Third-Party Disruption

Integrated Test 3: Payment, Configuration and Policy Issuance Failure

Integrated Test 4: Downstream Handover and Service Restoration

Scenario Test Design and Governance

Participants and Responsibilities

Senior Management

Critical Business Service Owner

Business and Operational Teams

Technology and ICT Risk Teams

Cybersecurity Teams

Business Continuity and Crisis Management Teams

Risk, Compliance, Legal and Internal Audit

Third Parties

Measuring Performance Against Impact Tolerance

Integration of Cyber and ICT Risks

Evidence Collection

Lessons Identified and Remediation

Regulatory Considerations for Scenario Testing by a Malaysian Financial Services Institution

Critical Business Service Focus

Severe but Plausible Scenarios

Impact Tolerance

Interconnections and Interdependencies

Cyber and Technology Resilience

Third-Party Participation

Governance and Oversight

Lessons and Continuous Improvement

Illustrative Annual Scenario Testing Programme

Success Criteria

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

Your Comments Here:

Strengthening Operational Resilience at AIA Bhd: An Enterprise Implementation Guide

[OR] [AIAB] [E3] [CBS] [1] [ST] Perform Scenario Testing

hbspt.cta._relativeUrls=true;hbspt.cta.load(3893111, '3c32e9b3-ea88-44c3-9182-fa3e6a9aadee', {"useNewLoader":"true","region":"na1"});

Operational Resilience Planner-Specialist-Expert

hbspt.cta._relativeUrls=true;hbspt.cta.load(3893111, '31f277f7-f31c-49c3-93b9-e0700461f6fd', {"useNewLoader":"true","region":"na1"});

hbspt.cta._relativeUrls=true;hbspt.cta.load(3893111, '3c32e9b3-ea88-44c3-9182-fa3e6a9aadee', {"useNewLoader":"true","region":"na1"}); CBS-1 Insurance Policy Application and Issuance

Introduction

Integrated End-to-End Scenario Testing Programme

Integrated Test 1: Loss of Customer Access and Application Intake

Integrated Test 2: Underwriting Capacity and Third-Party Disruption

Integrated Test 3: Payment, Configuration and Policy Issuance Failure

Integrated Test 4: Downstream Handover and Service Restoration

Scenario Test Design and Governance

Participants and Responsibilities

Senior Management

Critical Business Service Owner

Business and Operational Teams

Technology and ICT Risk Teams

Cybersecurity Teams

Business Continuity and Crisis Management Teams

Risk, Compliance, Legal and Internal Audit

Third Parties

Measuring Performance Against Impact Tolerance

Integration of Cyber and ICT Risks

Evidence Collection

Lessons Identified and Remediation

Regulatory Considerations for Scenario Testing by a Malaysian Financial Services Institution

Critical Business Service Focus

Severe but Plausible Scenarios

Impact Tolerance

Interconnections and Interdependencies

Cyber and Technology Resilience

Third-Party Participation

Governance and Oversight

Lessons and Continuous Improvement

Illustrative Annual Scenario Testing Programme

Success Criteria

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

Your Comments Here:

CBS-1 Insurance Policy Application and Issuance