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 |
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.
This test should combine:
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.
This test should combine:
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.
This test should combine:
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.
This test should combine:
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.
Each integrated test should be supported by an approved Scenario Test design profile containing:
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.
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.
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.
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 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 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 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 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.
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.
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:
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.
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:
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 should be captured throughout preparation, execution, observation and remediation. Appropriate evidence includes:
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:
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:
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
|
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.
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:
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.
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 |
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. |
||
|
|