Impact Tolerance therefore differs from a Recovery Time Objective, Recovery Point Objective, Maximum Tolerable Period of Disruption, or contractual Service Level Agreement.
These supporting measures help individual processes and systems contribute to service recovery, but they do not independently define how much customer harm, processing delay, data loss, or service degradation AIA Bhd can tolerate.
Impact Tolerance should instead specify outcome-based boundaries concerning how much disruption can occur, how many customers can be affected, how severely the service may deteriorate, and for how long.
The assessment must consider all 20 Sub-CBS processes, as an application can fail to reach issuance even when most components remain available.
A breakdown in identity verification, underwriting approval, medical evidence collection, payment confirmation, policy configuration, or downstream handover may prevent completion of the end-to-end service.
Harm may progress from temporary inconvenience to significant harm and, under severe conditions, intolerable harm requiring immediate management intervention.
Cyber and ICT risks are integrated throughout this assessment.
Cyberattacks, ransomware, unauthorised access, data corruption, application failures, cloud disruptions, failed technology changes, API failures, network outages, and technology concentration can affect several Sub-CBS processes simultaneously.
These risks are therefore assessed according to their effect on the customer-facing Critical Business Service and their potential contribution to an Impact Tolerance breach.
Table 1: Sub-CBS Disruption and Harm Assessment
|
Sub-CBS Code |
Name of Sub-CBS |
Potential Disruption |
Potential Harm |
Level of Harm |
Key Harm Indicators |
|
CBS-1.1 |
Customer Enquiry and Product Selection |
Customer-facing product channels, contact-centre services or intermediary access become unavailable, or inaccurate product information is displayed. |
Prospective customers cannot obtain reliable information, compare available products or commence an appropriate insurance application. Prolonged disruption may disadvantage customers seeking time-sensitive protection. |
Medium — initially an inconvenience, but prolonged or widespread disruption may cause customers to lose access to suitable insurance opportunities. |
Channel outage duration; percentage of channels unavailable; abandoned enquiry rate; affected customer volume; inaccurate quotation or product information incidents; complaints. |
|
CBS-1.2 |
Application Initiation and Registration |
The Insurance Application Platform cannot create or register new applications, or application records are duplicated or lost. |
Customers may submit applications without receiving an acknowledgement or a traceable application reference. Downstream identity, underwriting and issuance processes cannot commence. |
High — disruption directly prevents entry into the end-to-end service and can rapidly create an unrecorded or unmanaged backlog. |
Number of unregistered applications; registration failure rate; duplicate records; outage duration; backlog volume; percentage of intake channels affected. |
|
CBS-1.3 |
Customer Identity Verification and Due Diligence |
Identity-verification or screening services become unavailable, return unreliable results or expose personal data. |
Applications cannot progress safely. Customers may face delays, while ineffective verification could create fraud, financial crime, privacy and regulatory exposure. |
High — prolonged disruption blocks legitimate applications and may create significant compliance consequences. |
Verification failure rate; manual review backlog; number of unresolved screening alerts; number of affected customers; data exposure incidents; duration of the verification outage. |
|
CBS-1.4 |
Application Data Capture and Document Management |
Application information or supporting documents cannot be captured, retrieved or matched to the correct customer record. |
Underwriters may receive incomplete or inaccurate information. Customers may be repeatedly asked to resubmit sensitive documents, and processing may stop across multiple stages. |
High — data unavailability or loss can undermine the reliability of the complete application and issuance process. |
Missing document rate; retrieval failure rate; duplicate or misfiled documents; number of affected applications; data-integrity exceptions; backlog age. |
|
CBS-1.5 |
Application Completeness and Eligibility Validation |
Eligibility rules are unavailable, incorrectly configured or cannot be applied consistently. |
Eligible customers may be incorrectly delayed or rejected, while ineligible or incomplete applications may progress and require later remediation. |
Medium to High — short disruption creates delay; incorrect decisions across a large application population may create significant customer harm and conduct harm. |
Validation failure rate; incorrect rejection or acceptance rate; outstanding requirement backlog; rule-processing errors; customer complaints; affected product lines. |
|
CBS-1.6 |
Initial Risk Classification and Underwriting Triage |
The automated underwriting engine or triage workflow becomes unavailable, degraded or applies incorrect rules. |
Applications may be routed incorrectly or transferred to manual underwriting, potentially overwhelming available capacity and delaying decisions. |
High — broad disruption may affect a significant proportion of new applications and cause rapid backlog accumulation. |
Percentage of applications requiring manual handling; automated decision failure rate; triage backlog; processing time; referral error rate; capacity utilisation. |
|
CBS-1.7 |
Medical Evidence and Examination Coordination |
Medical appointment scheduling, provider communication or secure evidence exchange is disrupted. |
Customers who require a medical assessment cannot meet the underwriting requirements. Delays may affect customers seeking significant or medically underwritten coverage. |
Medium to High — the effect may be limited to referred applications, but prolonged disruption can create significant delay for vulnerable or high-risk customers. |
Outstanding medical evidence volume; average appointment delays; provider availability; unreceived reports; affected geographic areas; sensitive data incidents. |
|
CBS-1.8 |
Financial and Specialist Underwriting Assessment |
Senior underwriters, medical officers or specialist assessment capability becomes unavailable, or specialist case systems fail. |
Complex and high-value applications cannot receive appropriate assessment. Decisions may be delayed or made without sufficient expertise. |
High — specialist capacity constraints can affect significant customer cases and create risks to decision quality, fairness, and financial risk. |
Specialist case backlog; number of unavailable authorised specialists; referral ageing; decision reversal rate; high-value applications delayed. |
|
CBS-1.9 |
External Risk Referral and Reinsurance Review |
Reinsurance counterparties, external referral channels or secure data exchange become unavailable. |
Applications requiring external risk capacity cannot receive final approval or may be offered reduced coverage. |
Medium to High — limited to referred risks, but may significantly affect high-value or complex applications and AIA Bhd’s risk capacity. |
Outstanding external referrals; reinsurance response delay; affected coverage value; referral-channel outage duration; reduced or withdrawn capacity. |
|
CBS-1.10 |
Underwriting Decision and Approval |
Approval workflows, authorised decision-makers or underwriting systems become unavailable. |
Applications remain undecided despite completed assessments. Customers cannot proceed to acceptance, payment and issuance. |
Very High — this is a critical decision gate, and prolonged unavailability stops the majority of applications from reaching issuance. |
Decision backlog; average decision delay; percentage of approvals unavailable; high-value cases pending; approval override volume; aged applications. |
|
CBS-1.11 |
Decision Communication and Customer Acceptance |
Decision notices cannot be generated or delivered, or customer acceptance cannot be recorded. |
Customers may be unaware of acceptance, revised terms or conditions and cannot validly confirm whether they wish to proceed. |
High — disruption prevents otherwise approved applications from progressing and may create disputes over terms or communications. |
Undelivered decision notices; unrecorded acceptances; communication failure rate; expired offers; customer complaints; pending acceptance volume. |
|
CBS-1.12 |
Initial Premium and Payment Confirmation |
Payment-processing interfaces, banking connections or reconciliation capability become unavailable or inaccurate. |
Customers may be charged without a policy being issued, or approved policies may remain unissued because payment cannot be confirmed. |
Very High — financial harm and uncertainty over policy activation can arise quickly, particularly where customers believe coverage has commenced. |
Unmatched payment value and volume; customers debited without issuance; payment confirmation delay; reconciliation breaks; refund volume; failed transactions. |
|
CBS-1.13 |
Pre-Issuance Policy Configuration |
The Policy Administration System or product configuration engine is unavailable, corrupted or incorrectly configured. |
Approved applications cannot be converted into accurate policy records. Incorrect coverage, premium, beneficiary or exclusion data may be created. |
Very High — the authoritative insurance contract may be delayed or created incorrectly, with downstream servicing and claims consequences. |
Configuration failure rate; affected policy count; incorrect terms or premiums; system outage duration; data-integrity exceptions; manual setup backlog. |
|
CBS-1.14 |
Policy Document Generation and Quality Validation |
Policy documents cannot be generated, templates are corrupted, or quality controls fail. |
Customers may receive no contractual documentation or receive documents containing inaccurate terms, exclusions or policy details. |
Very High — widespread document errors can create contractual uncertainty, customer harm and extensive remediation. |
Failed document generation; incorrect document rate; policies withheld; affected product lines; document regeneration volume; quality exceptions. |
|
CBS-1.15 |
Policy Issuance, Activation and Delivery |
Policy activation or delivery channels become unavailable, or the issued policy status does not reach customer channels. |
Customers may not know whether coverage is active or may lack evidence of insurance. Policies may be unavailable for servicing or later claims processing. |
Very High — this is the primary customer outcome of CBS-1, and prolonged disruption represents direct failure of the Critical Business Service. |
Policies awaiting issuance; activation failures; customers without confirmation; delivery failure rate; issuance delay; inaccessible policy documents. |
|
CBS-1.16 |
Post-Issuance Handover and Reconciliation |
Issued policy data fails to transfer to servicing, finance, digital access or reporting platforms. |
Policies may exist in the core system but remain unavailable for customer access, premium allocation, servicing or regulatory reporting. |
Very High — hidden data breaks may create significant downstream customer and regulatory harm despite apparent completion of issuance. |
Interface failures; unreconciled policies; missing customer portal records; premium allocation errors; reporting exceptions; downstream record mismatch. |
|
CBS-1.17 |
Application and Issuance Exception Management |
Exception queues become inaccessible, cases lack ownership or remediation capability is overwhelmed. |
Failed or incomplete applications may remain unresolved for prolonged periods without effective customer communication or escalation. |
High — unresolved exceptions can create concentrated harm among affected customers and conceal systemic process failures. |
Exception backlog; ageing beyond threshold; unresolved high-risk cases; repeat exceptions; customer complaints; cases without assigned ownership. |
|
CBS-1.18 |
Application Status Monitoring and Service Control |
Monitoring dashboards, management information or alerting feeds become incomplete, delayed or inaccurate. |
Management may not detect increasing backlog, system degradation or approaching harm thresholds and may fail to activate response arrangements promptly. |
High — lack of visibility can allow an otherwise manageable disruption to develop into an Impact Tolerance breach. |
Missing data feeds; delayed reports; unmonitored applications; undetected SLA or tolerance breaches; alert failures; discrepancy between actual and reported backlog. |
|
CBS-1.19 |
Disruption Response and Alternate Processing |
Incident coordination, emergency communications, alternate workflows or manual processing arrangements fail. |
AIA Bhd may be unable to maintain priority application processing or contain customer harm during a major disruption. |
Very High — failure of contingency arrangements materially increases the probability that CBS-1 will exceed its Impact Tolerance. |
Time to activate response; percentage of priority cases processed; manual capacity; unavailable response personnel; communication delays; backlog growth during disruption. |
|
CBS-1.20 |
Service Recovery, Reconciliation and Restoration |
Systems recover without complete data, manual transactions are not reconciled or recovery capacity is insufficient to clear backlog. |
Customers may experience an extended delay after technical restoration, and duplicate, missing, or incorrect policies may be created. |
Very High — incomplete restoration may prolong or worsen harm and prevent the service from being declared fully recovered. |
Recovery duration; backlog clearance time; unreconciled transactions; missing or duplicate records; data-integrity failures; residual customer impact. |
Table 2: Cyber and ICT Risk Integration and Proactive Risk Management
|
Sub-CBS Code |
Cyber and ICT Risk Linkage |
Contribution to Impact Tolerance Breach |
Proactive Risk Management Action |
Evidence of Proactive Risk Management |
|
CBS-1.1 |
Distributed denial-of-service attack, web or mobile outage, content management compromise, unauthorised product information changes, and third-party channel disruption. |
Loss of all major enquiry channels could prevent customers from starting the service. Incorrect product content could create customer harm even while channels remain available. |
Maintain diverse intake channels; implement web application protection, content approval controls, continuous availability monitoring, and tested contact centre fallback arrangements. |
Channel failover test reports; web monitoring records; content approval logs; penetration testing results; contact-centre continuity exercise records. |
|
CBS-1.2 |
Application failure, database outage, failed deployment, API disruption, ransomware and cloud infrastructure failure. |
Central registration failure may prevent all channels from creating valid application records, causing rapid accumulation of untracked demand. |
Implement resilient application architecture, database replication, tested rollback procedures, secure offline registration and capacity monitoring. |
Disaster recovery test reports; database failover evidence; change rollback test results; capacity reports; manual registration exercise records. |
|
CBS-1.3 |
Identity service outage, compromised screening API, data leakage, unauthorised access and third-party ICT disruption. |
Applicants cannot complete due diligence, or unreliable results may allow fraudulent applications to progress. A prolonged outage can halt a large portion of new business. |
Use resilient verification arrangements, secure API controls, data encryption, alternative manual verification and enhanced monitoring of screening results. |
Third-party assurance reports; API security test results; access-control reviews; manual fallback tests; due diligence exception reports. |
|
CBS-1.4 |
Document repository failure, ransomware, data corruption, misconfigured access permissions and storage outage. |
Inaccessible or corrupted application documents can stop underwriting and require customers to resubmit sensitive information. |
Maintain immutable or protected backups, document integrity checks, role-based access, malware scanning, recovery testing, and secure alternate capture arrangements. |
Backup restoration results; vulnerability assessment results; access recertification records; malware monitoring reports; evidence from document recovery exercises. |
|
CBS-1.5 |
Rules-engine failure, unauthorised rule change, version-control error and failed technology deployment. |
Incorrect eligibility outcomes may affect large numbers of applications before detection and create widespread customer or conduct harm. |
Introduce controlled rule governance, dual approval, automated regression testing, exception monitoring and rapid rollback capability. |
Rule-change approval records; regression testing results; production reconciliation reports; change-management records; post-implementation review findings. |
|
CBS-1.6 |
Automated underwriting engine outage, model or rules corruption, performance degradation and technology concentration. |
Loss of automation can shift excessive volumes to manual staff, causing backlog growth and delayed underwriting decisions. |
Establish manual prioritisation, tested alternate decision capability, capacity thresholds, rules validation and resilient hosting. |
Capacity stress-test reports; underwriting fallback-exercise records; failover-testing records; model or rule-validation records; management-tolerance reports. |
|
CBS-1.7 |
Medical portal outage, insecure file transfer, provider-system disruption, ransomware and exposure of health information. |
Required evidence may become unavailable or unsafe to process, delaying medically underwritten applications and increasing privacy risk. |
Maintain secure alternative evidence channels, provider continuity requirements, encryption, data loss prevention, and backup provider arrangements. |
Third-party continuity attestations; secure transfer test results; privacy-control testing; provider performance reports; alternate-channel exercise evidence. |
|
CBS-1.8 |
Specialist workflow outage, loss of secure remote access, privileged account compromise and unavailable document systems. |
Scarce specialist staff may be unable to review cases, leaving high-value and complex applications unresolved. |
Provide resilient, secure access; cross-train authorised personnel; maintain controlled offline assessment procedures; and protect privileged accounts. |
Privileged-access reviews; remote-access resilience tests; succession or cross-training records; offline procedure tests; specialist capacity reports. |
|
CBS-1.9 |
Reinsurance portal failure, third-party cyber incident, network disruption and secure communication failure. |
External approval and risk capacity may be unavailable, delaying or preventing the issuance of selected high-value policies. |
Establish contractual resilience requirements, alternative secure communication channels, counterparty diversification and escalation protocols. |
Third-party assurance reports; contractual review records; alternate communication tests; concentration risk assessments; counterparty incident exercises. |
|
CBS-1.10 |
Approval workflow failure, unauthorised approval, privileged access compromise, audit-log failure and application outage. |
Applications may not receive valid approval or may be approved without proper authority, creating both delays and control failures. |
Maintain alternate approval procedures, strong authentication, segregation of duties, approval-limit monitoring and tamper-resistant audit records. |
Access-control testing; approval workflow failover results; segregation-of-duties reviews; audit-log monitoring; exception-approval reports. |
|
CBS-1.11 |
Customer portal or communication outage, notification API failure, phishing, message interception and loss of acceptance records. |
Customers may not receive or securely accept policy terms. Failure to record acceptance could invalidate progression to issuance. |
Use multiple secure communication channels, authentication controls, delivery tracking, anti-phishing controls and recoverable acceptance records. |
Communication failover tests; delivery reports; phishing simulation results; acceptance-record reconciliation; portal security assessments. |
|
CBS-1.12 |
Payment gateway failure, banking API outage, transaction duplication, data corruption, cyber fraud and reconciliation system failure. |
Customers may be charged incorrectly, or payment may remain unconfirmed, directly preventing issuance and potentially creating financial harm. |
Implement dual reconciliation, transaction monitoring, secure payment APIs, fraud controls, alternate banking arrangements and tested manual confirmation. |
Reconciliation control results; payment failover tests; fraud monitoring records; banking provider assurance; manual confirmation exercise reports. |
|
CBS-1.13 |
Policy Administration System outage, configuration corruption, failed product deployment, database failure and privileged access misuse. |
Approved applications cannot be configured, or incorrect contractual data may be generated across many policies. |
Maintain resilient policy administration, controlled product releases, configuration validation, database recovery and privileged-access monitoring. |
Disaster recovery results; product regression tests; configuration reconciliation reports; privileged-access reviews; change assurance records. |
|
CBS-1.14 |
Document engine failure, template corruption, malware, unauthorised template modification and storage outage. |
Incorrect documents could be generated at scale, or policy issuance may cease entirely. |
Apply template version control, dual approval, document comparison checks, protected repositories and alternate document generation. |
Template approval logs; document quality sampling; repository recovery tests; malware scan records; alternate generation test results. |
|
CBS-1.15 |
Policy activation failure, customer portal outage, notification service disruption, cloud outage and interface failure. |
Customers may not receive confirmation of active coverage or may be unable to access issued policies, directly contributing to intolerable service harm. |
Implement resilient activation services, multi-channel delivery, confirmation reconciliation and recovery prioritisation for policy issuance. |
Activation failover reports; delivery reconciliation records; portal availability reports; recovery test results; customer notification testing. |
|
CBS-1.16 |
API failure, data mapping error, enterprise data-platform outage, message queue failure and data corruption. |
Issued policies may not reach servicing, payment, customer or reporting systems, creating hidden and widespread downstream harm. |
Use interface monitoring, automated reconciliation, message replay, data integrity checks, and clearly owned cross-system incident procedures. |
Interface monitoring records; reconciliation reports; message replay tests; data-quality dashboards; cross-system scenario test results. |
|
CBS-1.17 |
Workflow outage, ticket loss, unauthorised case closure, data fragmentation and incident-management platform failure. |
Exceptions may remain invisible or unresolved until customer harm becomes significant or widespread. |
Maintain resilient exception registers, ageing alerts, manual fallback records, role-based access and management escalation thresholds. |
Exception ageing reports; access reviews; manual fallback tests; control testing; management committee minutes reviewing aged cases. |
|
CBS-1.18 |
Monitoring system outage, inaccurate data feeds, alert suppression, dashboard manipulation, and time synchronisation failure. |
Management may not recognise that service harm is approaching the approved tolerance, thereby delaying escalation. |
Use independent monitoring sources, data-quality controls, alert testing, threshold governance and manual management reporting capability. |
Alert test records; dashboard reconciliation; data-quality reports; threshold approval minutes; monitoring platform resilience tests. |
|
CBS-1.19 |
Emergency communication outage, remote access unavailable, cyber incident affecting recovery tools, failed alternate workflow, and infrastructure outage. |
Inability to invoke workarounds or coordinate resources may allow a disruption to exceed tolerable duration and scope. |
Test alternate processing under realistic capacity constraints, maintain independent communication channels, and secure emergency access and pre-authorised response procedures. |
Scenario testing results; incident response exercises; emergency communication tests; alternate-site reports; action and remediation trackers. |
|
CBS-1.20 |
Backup corruption, recovery environment failure, incomplete database restoration, ransomware persistence, and reconciliation tool outage. |
Technical restoration may fail or produce unreliable records, extending disruption beyond the proposed tolerance and creating additional customer harm. |
Maintain segregated backups, perform full restoration tests, validate data integrity, rehearse backlog recovery, and independently approve service restoration. |
Backup restoration evidence; disaster recovery test reports; data-integrity validation; backlog recovery exercises; independent review findings. |
For implementation and planning purposes, AIA Bhd should consider the following indicative Impact Tolerance:
AIA Bhd should not allow a severe disruption to CBS-1 Insurance Policy Application and Issuance to prevent the receipt, assessment, approval or issuance of insurance applications for more than 24 consecutive hours where priority or time-sensitive applications are affected, or more than two business days for the wider application population.
The tolerance should be supplemented by the following outcome-based boundaries.
The 24-hour and two-business-day measures are not intended to replace individual system RTOs. System and process recovery objectives should be shorter where necessary to ensure that the end-to-end Critical Business Service remains within the approved Impact Tolerance.
AIA Bhd should avoid circumstances in which:
During disruption:
AIA Bhd should apply a near-zero tolerance for:
Where data integrity cannot be confirmed, AIA Bhd should suspend affected automated processing and use controlled validation or reconciliation before issuing policies.
Harm should be regarded as severe or intolerable where disruption results in one or more of the following:
CBS-1 does not generally require continuous real-time completion in the same manner as emergency payment or medical admission services.
However, the service remains important because it determines whether customers obtain timely insurance protection and whether approved applications are converted into legally and operationally reliable policies.
A short delay in non-urgent product enquiry or routine processing may initially create inconvenience rather than intolerable harm.
The level of harm increases when customers cannot submit or track applications, approved cases cannot be issued, premiums cannot be reconciled, or customers remain uncertain about whether coverage has commenced.
Harm may also increase rapidly where the disruption affects vulnerable customers, medical coverage, significant insured amounts or time-sensitive protection requirements.
The proposed tolerance therefore combines duration, affected-customer scope, minimum service capability, data integrity and downstream impact.
This is more suitable than using a single universal recovery time because different Sub-CBS processes have distinct disruption characteristics.
A short failure of the document-generation process, for example, may be manageable where accurate policy records remain available, whereas even a brief data-corruption event may require immediate suspension because incorrect policies could be issued.
The following Sub-CBS should receive the highest resilience priority:
The proposed Impact Tolerance is an illustrative implementation recommendation. It should be reviewed and validated by AIA Bhd’s:
Validation should consider actual daily application volumes, product types, vulnerable customer populations, underwriting turnaround times, manual processing capacity, technology architecture, data recovery capability, third-party commitments, and applicable regulatory requirements.
The Impact Tolerance for CBS-1 Insurance Policy Application and Issuance provides AIA Bhd with a clear boundary beyond which disruption would produce unacceptable customer, operational, financial, legal or regulatory harm.
It shifts resilience planning away from isolated recovery targets and towards the outcome that must continue to be delivered to customers.
Assessment of all 20 Sub-CBS processes shows where disruptions may enter the service, how they may propagate, and which processes are most critical to maintaining application and issuance capability.
This end-to-end analysis enables AIA Bhd to validate whether individual RTOs, RPOs, staffing arrangements, third-party commitments and recovery strategies collectively support the proposed service tolerance.
Integrating Cyber and ICT risks strengthens the assessment because many severe disruptions are likely to affect several processes and systems simultaneously.
Ransomware, application failure, data corruption, access-control compromise, API disruption, cloud outage and failed technology change can prevent service delivery even where individual business teams remain operational.
Evidence such as control test results, cybersecurity monitoring records, failover reports, disaster recovery exercises, third-party assurance, management committee minutes, and remediation tracking demonstrates that risk management actions have been implemented rather than merely documented.
These records should form part of AIA Bhd’s Operational Resilience evidence pack.
The approved Impact Tolerance should guide severe-but-plausible scenario testing, technology and process remediation, investment prioritisation, third-party oversight, and continuous improvement.
It should be reviewed following material incidents, significant system or product changes, outsourcing changes, scenario tests and changes in the regulatory or operating environment.
| 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 course and the OR-5000 Operational Resilience Expert Implementer course.
|
If you have any questions, click to contact us. |
||
|
|