[OR] [AIAB] [E3] [CBS] [1] [SbPS] Identify Severe but Plausible Scenarios

Written by Dr Goh Moh Heng | Jul 21, 2026 6:51:01 AM

CBS-1 Insurance Policy Application and Issuance

Introduction

Identifying Severe but Plausible Scenarios is a core component of Operational Resilience because it enables AIA Bhd to evaluate whether the CBS-1 Insurance Policy Application and Issuance can continue to be delivered under credible yet highly disruptive conditions.

The assessment should focus on disruption to the end-to-end Critical Business Service rather than isolated system failures or conventional risk events.

The 20 Sub-CBS processes provide a detailed, process-level basis for identifying where disruption may originate, propagate through operational and technological dependencies, and ultimately threaten the Impact Tolerance of the service.

Cyber and ICT Risks must therefore be embedded in scenario design as potential triggers, contributing factors, and amplifiers of disruption.

The scenarios below are designed to challenge existing controls, recovery arrangements, interconnections, and interdependencies, and to provide a structured basis for testing whether AIA Bhd could maintain the Critical Business Service within its defined Impact Tolerance.

This approach reflects the scenario characteristics and testing objectives specified in the implementation prompt.

Table 1: Recommended Severe but Plausible Scenarios

Sub-CBS Code	Name of Sub-CBS	Recommended Severe but Plausible Scenario	Scenario Description	Primary Disruption Trigger	Impact on Sub-CBS	Impact on Critical Business Service
CBS-1.1	Customer Enquiry and Product Selection	Multi-channel customer service disruption	A major telecommunications failure coincides with severe degradation of digital enquiry channels, preventing customers and intermediaries from obtaining product information or initiating assisted enquiries for an extended period.	Telecommunications and digital channel outage	Enquiries accumulate, and customers cannot complete product selection.	Application volumes fall sharply and a growing backlog develops at the entry point of the service.
CBS-1.2	Application Initiation and Registration	Application platform unavailable during peak demand	A failed technology deployment results in prolonged unavailability of application initiation and registration across major channels. Rollback is unsuccessful, and recovery is delayed.	Failed technology change	New applications cannot be registered, and application identifiers are not generated.	End-to-end policy issuance stops for new applicants and disruption duration may approach or exceed Impact Tolerance.
CBS-1.3	Customer Identity Verification and Due Diligence	Identity verification service compromise	A cyber incident affects identity verification capabilities and raises concerns regarding the integrity of verification results. Automated processing is suspended while records are validated.	Cyberattack or third-party compromise	Customer identity and due diligence checks cannot be reliably completed.	Applications cannot safely progress, creating a significant underwriting and issuance backlog.
CBS-1.4	Application Data Capture and Document Management	Ransomware encrypts application documents	Ransomware affects document repositories and connected workflow services. Application documents become inaccessible, and the integrity of recently captured data is uncertain.	Ransomware	Staff cannot retrieve supporting documents or confirm application data.	Applications across multiple processing stages are suspended, potentially causing widespread delays in issuance.
CBS-1.5	Application Completeness and Eligibility Validation	Corrupted validation rules approve and reject applications incorrectly	A defective software release corrupts eligibility and completeness rules. Monitoring does not detect the issue immediately, and incorrect decisions accumulate.	Data or rules integrity failure	Validation results become unreliable, and affected applications require reassessment.	Policy issuance may continue to use incorrect data, causing customer harm and necessitating large-scale remediation.
CBS-1.6	Initial Risk Classification and Underwriting Triage	Automated triage capacity exhaustion	A surge in application volumes coincides with severe performance degradation of automated risk classification capabilities. Applications are repeatedly queued or incorrectly routed.	Capacity exhaustion	Initial risk classification is delayed, and underwriting queues become distorted.	Bottlenecks propagate into specialist underwriting and approval, delaying policy issuance.
CBS-1.7	Medical Evidence and Examination Coordination	Critical medical service network disruption	A regional health emergency and third-party service disruption significantly reduce access to medical examinations and evidence processing.	Third-party and regional disruption	Required medical evidence cannot be obtained within normal timeframes.	A material proportion of applications remains incomplete and cannot proceed to underwriting.
CBS-1.8	Financial and Specialist Underwriting Assessment	Simultaneous loss of specialist underwriters	A severe infectious disease event or regional emergency results in widespread absence of specialist staff while remote access is degraded.	Loss of critical personnel and ICT access	Complex underwriting assessments cannot be completed at the required capacity.	High-risk and specialist applications accumulate, creating prolonged service degradation.
CBS-1.9	External Risk Referral and Reinsurance Review	Reinsurance connectivity and counterparty disruption	A cyber incident at a critical external risk or reinsurance service provider prevents referrals and responses while secure connectivity is suspended.	Critical third-party cyber disruption	External risk referrals cannot be completed or validated.	Applications requiring external review remain suspended and issuance capacity is materially reduced.
CBS-1.10	Underwriting Decision and Approval	Privileged access compromise affects approval integrity	Compromised privileged credentials are used to manipulate underwriting approval permissions. Approval processing is suspended while access and decisions are investigated.	Privileged access compromise	Underwriting approvals cannot be trusted, and recent decisions require validation.	Policy issuance is halted or restricted to prevent unauthorised decisions from progressing.
CBS-1.11	Decision Communication and Customer Acceptance	Customer communication failure across digital channels	A major communication gateway and network disruption prevent decisions, revised terms and acceptance requests from reaching customers.	Network and communication service failure	Customers cannot receive or respond to underwriting decisions.	Approved applications remain incomplete and cannot progress to premium confirmation or issuance.
CBS-1.12	Initial Premium and Payment Confirmation	Payment confirmation data integrity failure	Payment transaction records and policy application references become unsynchronised following a processing failure. Some successful payments appear unpaid, and duplicate confirmations occur.	Data synchronisation failure	Premium status cannot be reliably confirmed.	Policies may be delayed, incorrectly activated or require extensive financial reconciliation.
CBS-1.13	Pre-Issuance Policy Configuration	Policy configuration rules corrupted	A configuration change introduces incorrect product parameters, coverage conditions or policy attributes across a large batch of pending applications.	Failed technology change	Pre-issuance policy configurations become unreliable.	Issuance must be suspended to prevent incorrect policies from being generated.
CBS-1.14	Policy Document Generation and Quality Validation	Document generation engine produces inaccurate policy documents	A software defect causes policy schedules and contractual documents to contain missing or inconsistent information. Detection occurs after a significant volume has been generated.	Software and data integrity failure	Policy documents fail quality validation, and affected documents require regeneration.	Policy issuance slows significantly and previously generated documents may require recall and remediation.
CBS-1.15	Policy Issuance, Activation and Delivery	Primary and recovery issuance capabilities fail simultaneously	A major infrastructure outage affects primary policy issuance capabilities, and an undetected configuration dependency prevents successful recovery in the alternate environment.	Simultaneous primary and recovery failure	Policies cannot be activated or delivered.	The final delivery point of the Critical Business Service becomes unavailable, and Impact Tolerance may be breached.
CBS-1.16	Post-Issuance Handover and Reconciliation	Downstream policy administration integration failure	API and connectivity failures prevent issued policy records from transferring accurately to downstream administration and servicing processes.	API and connectivity failure	Issued policies cannot be reconciled with downstream records.	Customers may receive policies that cannot be reliably serviced, creating cascading disruption to other Critical Business Services.
CBS-1.17	Application and Issuance Exception Management	Exception volumes overwhelm manual processing capacity	Multiple upstream failures generate exceptional volumes of rejected, duplicated and incomplete applications while specialist exception staff are unavailable.	Cascading operational and people disruption	Exception queues exceed manual processing capacity.	Unresolved exceptions delay numerous applications and prolong overall service recovery.
CBS-1.18	Application Status Monitoring and Service Control	Monitoring and detection controls fail during service degradation	Cyber compromise or monitoring configuration failure creates blind spots in application processing dashboards and alerts. Management remains unaware of growing queues and processing failures.	Monitoring control failure	Service degradation is not detected or escalated promptly.	Delayed intervention allows disruption to propagate across the end-to-end Critical Business Service.
CBS-1.19	Disruption Response and Alternate Processing	Alternate processing arrangements fail under real demand	A major cyber incident requires primary application processing to be isolated. Alternate manual and recovery arrangements cannot handle the volume, and remote access becomes unstable.	Major cyber incident and recovery capacity failure	Alternate processing rapidly reaches capacity and workarounds become unsustainable.	Service degradation continues beyond planned recovery assumptions and may breach Impact Tolerance.
CBS-1.20	Service Recovery, Reconciliation and Restoration	Recovery creates large-scale data inconsistency	Following a prolonged outage, multiple recovery sources contain conflicting application, underwriting, payment and issuance records. Automated reconciliation fails.	Data integrity failure during recovery	Recovery cannot be completed until records are validated and reconciled.	Restoration is delayed and incorrect recovery could cause customer harm, duplicate policies or lost applications.

Table 2: Resilience, Cyber and ICT Risk, and Proactive Risk Management Assessment

Sub-CBS Code	Name of Sub-CBS	Interconnections and Interdependencies Challenged	Cyber and ICT Risk Linkage	Potential Impact Tolerance Breach	Proactive Risk Management Action	Evidence of Proactive Risk Management	Scenario Testing Objective
CBS-1.1	Customer Enquiry and Product Selection	Customer channels, intermediaries, telecommunications, digital services, customer service teams	ICT channel and network failure amplifies the loss of customer access.	Medium to High if prolonged across major channels	Establish channel diversification, traffic redirection and prioritised alternate enquiry arrangements.	Network resilience tests; channel failover reports; BCP exercise results	Validate continued customer access and controlled demand management.
CBS-1.2	Application Initiation and Registration	Digital channels, registration workflow, identity services, application databases	Failed change disables a critical processing capability, and unsuccessful rollback prolongs disruption.	High	Strengthen deployment controls, rollback capability and isolated recovery testing.	Change risk assessment; rollback test; DR test; remediation register	Demonstrate restoration of application initiation before Impact Tolerance is breached.
CBS-1.3	Customer Identity Verification and Due Diligence	Identity services, compliance, customer records, third parties	Cyber compromise undermines the integrity and availability of verification data.	High	Implement alternative verification procedures and independent integrity validation.	Cyber threat assessment; third-party assurance; incident simulation report	Test safe continuation of verification without accepting uncontrolled identity risk.
CBS-1.4	Application Data Capture and Document Management	Document repositories, workflow, storage, cybersecurity, underwriting	Ransomware removes availability and creates uncertainty regarding data integrity.	High	Maintain segmented immutable recovery copies and tested document restoration procedures.	Ransomware exercise; recovery test; vulnerability assessment	Validate restoration of documents and identification of the last trusted data state.
CBS-1.5	Application Completeness and Eligibility Validation	Application data, validation rules, product rules, quality controls	Software or data corruption generates incorrect processing outcomes.	High	Implement rule integrity monitoring, reconciliation and controlled rule rollback.	Data integrity testing; change approval; validation control reports	Determine how quickly incorrect decisions are detected, contained and corrected.
CBS-1.6	Initial Risk Classification and Underwriting Triage	Workflow queues, automated classification, and underwriting capacity	ICT capacity degradation creates processing congestion and routing errors.	Medium to High	Define capacity thresholds and dynamic manual triage arrangements.	Capacity test results; performance reports; BCP procedures	Test sustained processing during severe capacity degradation.
CBS-1.7	Medical Evidence and Examination Coordination	Medical providers, applicants, underwriting, communications	Third-party systems and connectivity failures may prolong evidence collection.	Medium to High	Diversify evidence sources and establish risk-based alternate evidence procedures.	Third-party assurance; continuity plans; exercise reports	Test continuation where a significant proportion of medical service capacity is unavailable.
CBS-1.8	Financial and Specialist Underwriting Assessment	Specialist staff, underwriting tools, remote access, medical evidence	Remote-access or authentication failure amplifies the loss of specialist personnel.	High	Establish cross-trained specialist pools and resilient, secure remote access.	Skills matrix; access resilience tests; BCP exercise	Validate minimum specialist underwriting capacity under combined people and ICT disruption.
CBS-1.9	External Risk Referral and Reinsurance Review	Reinsurers, external risk specialists, secure connectivity, and underwriting	A third-party cyber incident disables referral capabilities and raises data confidentiality concerns.	High	Define alternate referral pathways, counterparty escalation and manual risk acceptance controls.	Third-party risk assessment; assurance reports; cyber exercise	Test continuity of high-risk application decisions during prolonged external provider disruption.
CBS-1.10	Underwriting Decision and Approval	Identity and access management, approval authority, audit trails, underwriting	Privileged access compromise threatens decision integrity.	High	Strengthen privileged access monitoring, segregation and emergency approval controls.	PAM review; penetration test; access audit; cyber incident simulation	Test containment of compromised approvals while preserving controlled decision capacity.
CBS-1.11	Decision Communication and Customer Acceptance	Customer channels, communication gateways, application workflow	Network or gateway failure prevents communication and digital acceptance.	Medium to High	Establish alternate approved communication and acceptance methods.	Network test; communication exercise; continuity procedures	Validate timely communication and secure acceptance through alternate channels.
CBS-1.12	Initial Premium and Payment Confirmation	Payment services, banking interfaces, finance, application records	Interface or synchronisation failure creates payment data integrity issues.	High	Implement independent transaction reconciliation and controlled exception processing.	Reconciliation testing; data integrity reports; incident playbook	Determine whether valid payments can be identified and safely linked to applications.
CBS-1.13	Pre-Issuance Policy Configuration	Product rules, underwriting decisions, policy configuration, change management	Defective configuration propagates incorrect policy attributes.	High	Introduce automated configuration integrity checks and rapid version rollback.	Change testing, architecture review, and quality control results	Test detection and containment before incorrect configurations reach issuance.
CBS-1.14	Policy Document Generation and Quality Validation	Policy data, document generation, quality assurance, customer delivery	Software defects or corrupted templates create inaccurate contractual documents.	High	Establish template integrity monitoring, sample validation and bulk regeneration capability.	Data integrity tests; quality reports; deployment records	Validate detection, containment and regeneration of affected documents.
CBS-1.15	Policy Issuance, Activation and Delivery	Issuance infrastructure, recovery environment, customer delivery, policy records	Technology concentration and shared dependencies may cause simultaneous primary and recovery failure.	Very High	Identify common-mode dependencies and test isolated recovery capability.	Architecture resilience review; failover report; DR test	Demonstrate that issuance can resume within Impact Tolerance despite common-mode failure.
CBS-1.16	Post-Issuance Handover and Reconciliation	Policy administration, APIs, customer servicing, finance, downstream CBS	API failure or data corruption creates inconsistent records across interconnected services.	High	Implement store-and-forward capability, interface reconciliation and controlled replay.	API resilience tests; reconciliation reports; architecture review	Test accurate downstream handover following prolonged interface disruption.
CBS-1.17	Application and Issuance Exception Management	All upstream Sub-CBS, specialist teams, and workflow queues	Technology failures may create exceptional volumes exceeding manual capacity.	High	Establish exception surge thresholds, prioritisation and scalable response capacity.	Capacity assessment; BCP exercise; staffing plan	Test management of exceptional volumes without losing critical application records.
CBS-1.18	Application Status Monitoring and Service Control	Monitoring tools, operational management, incident management, and all processing stages	Cyber compromise or configuration error creates monitoring blind spots.	High	Implement independent service indicators and end-to-end CBS monitoring.	Monitoring control tests; cyber assessment; incident reports	Test whether management detects service harm before Impact Tolerance is threatened.
CBS-1.19	Disruption Response and Alternate Processing	Cyber response, BCM, crisis management, technology recovery, business operations	Cyber containment may remove primary systems while alternate ICT capacity is inadequate.	Very High	Conduct integrated cyber, BCM, and crisis-scenario testing using realistic transaction volumes.	Cyber simulation; BCP exercise; crisis exercise; remediation register	Validate that alternate processing can sustain minimum service delivery during prolonged isolation.
CBS-1.20	Service Recovery, Reconciliation and Restoration	All Sub-CBS, data sources, finance, policy administration, and technology recovery	Recovery from inconsistent data states can prolong disruption and introduce secondary errors.	Very High	Establish trusted recovery points, end-to-end reconciliation criteria and controlled restoration gates.	DR test; data integrity testing; recovery playbook; Internal Audit findings	Validate accurate restoration of the complete application-to-issuance service without uncontrolled data loss.

The analysis above deliberately uses a balanced range of technology, cyber, third-party, people, data-integrity, communications, capacity, and cascading-disruption scenarios rather than repeating generic ICT outage scenarios, consistent with the prompt's scenario design requirements.

End-to-End Scenario Perspective

Although each scenario is associated with a specific Sub-CBS, AIA Bhd should not test the scenarios solely as individual process failures.

CBS-1 is delivered through a chain of interconnected activities, beginning with customer enquiry and application initiation, and progressing through identity verification, underwriting, payment confirmation, policy configuration, issuance, and final reconciliation.

A disruption originating in one Sub-CBS can create accumulated queues, inaccurate data or resource constraints that affect subsequent stages.

For example, a ransomware incident affecting CBS-1.4 Application Data Capture and Document Management could prevent underwriting teams from accessing supporting documents.

The resulting underwriting backlog could overwhelm CBS-1.17 Application and Issuance Exception Management. Once systems are restored, inconsistent application records could then challenge CBS-1.20 Service Recovery, Reconciliation and Restoration.

The resulting scenario is therefore not merely a document system outage; it is an end-to-end disruption that threatens the delivery of CBS-1.

Similarly, a privileged access compromise affecting CBS-1.10 Underwriting Decision and Approval could require AIA Bhd to suspend approvals, review historical decisions and restrict user access.

If the disruption coincides with a payment reconciliation failure under CBS-1.12, the organisation may face simultaneous uncertainty concerning both underwriting decisions and premium status.

Such combined scenarios provide a stronger test of resilience because they challenge the organisation's ability to manage uncertainty, prioritise service delivery and prevent customer harm under severe operational stress.

Integration of Cyber and ICT Risks

Cyber and ICT Risks should be embedded directly into the disruption pathway of each Severe but Plausible Scenario. The prompt expressly requires Cyber and ICT Risks to be treated as triggers, contributing factors or disruption amplifiers rather than as a separate standalone risk assessment.

For CBS-1, a cyber incident may directly initiate disruption, as in a ransomware attack affecting application documents or a privileged access compromise affecting underwriting approvals. In other scenarios, ICT Risk may amplify the impact of an operational event.

The loss of specialist underwriters, for example, becomes materially more severe if secure remote access is simultaneously unavailable. A third-party medical evidence disruption may be prolonged if interfaces and communication channels also fail.

AIA Bhd should therefore assess the combined effectiveness of preventive, detective, response, recovery and resilience measures. Preventive controls may reduce the likelihood of disruption, but Operational Resilience requires management to consider the possibility that these controls fail. Scenario testing should consequently assume that a severe event has occurred and evaluate whether the organisation can continue to deliver CBS-1 within its Impact Tolerance.

Particular attention should be given to common-mode technology dependencies.

Primary and recovery environments may appear technically separate but could still depend on common identity services, network components, configuration repositories, specialist personnel, or data sources.

The scenario for CBS-1.15 Policy Issuance, Activation, and Delivery is intended to test whether shared dependencies could cause primary and recovery arrangements to fail simultaneously.

Proactive Operational Resilience Risk Management

The scenarios should be used as a proactive risk management mechanism rather than only as exercise narratives.

For each scenario, AIA Bhd should identify the vulnerability being challenged, determine the potential service harm, evaluate whether existing arrangements are sufficient and define measurable resilience improvements.

The evidence expected by the implementation prompt includes risk assessments, cyber and ICT assessments, architecture reviews, failover and disaster recovery tests, cyber simulations, penetration and vulnerability assessments, capacity testing, data-integrity testing, third-party assurance, BCM and crisis exercises, remediation registers and senior management reporting.

Management should be able to demonstrate a clear evidence chain:

Scenario identified → vulnerability assessed → Impact Tolerance exposure evaluated → risk management action approved → control or resilience improvement implemented → effectiveness tested → residual vulnerability reported and monitored.

For example, identifying simultaneous primary and recovery failure as a Severe but Plausible Scenario is insufficient by itself.

AIA Bhd should be able to demonstrate that common-mode dependencies have been identified, architecture resilience has been reviewed, failover capability has been tested under realistic conditions, and remediation actions have been tracked to completion.

This evidence-based approach enables senior management, risk functions, Internal Audit and regulatory reviewers to assess not only whether scenarios have been documented, but whether the organisation has actively strengthened the resilience of CBS-1.

Regulatory Considerations for a Malaysian Financial Services Institution

The uploaded prompt specifically requires alignment with the 2025 BNM Discussion Paper on Operational Resilience and requires a clear distinction between explicit regulatory expectations and implementation recommendations inferred from Operational Resilience good practice.

Regulatory caveat: the referenced BNM Discussion Paper was not included with the uploaded prompt, and I could not locate a publicly retrievable copy during the preparation of this chapter.

Accordingly, the following section is framed as implementation guidance for a Malaysian FSI and is not presented as a direct quotation or definitive statement of BNM requirements. The prompt itself expressly prohibits inventing regulatory requirements or attributing examples to BNM without documentary support.

From an Operational Resilience implementation perspective, a Malaysian FSI should establish a scenario framework that links Critical Business Services, Impact Tolerance, mapped interconnections and interdependencies, and scenario testing.

For AIA Bhd, this means evaluating disruption based on the ability to continue Insurance Policy Application and Issuance, rather than limiting testing to individual applications, infrastructure components or departmental recovery plans.

The scenario framework should consider events that can cause severe service harm.

Appropriate implementation examples include prolonged disruption of digital application services; a major cyber incident affecting multiple application and customer channels; simultaneous failure of primary and recovery technology arrangements; disruption of critical medical, identity or external risk service providers; compromise of application, underwriting or payment data integrity; widespread telecommunications failure; loss of specialist underwriting personnel; and cascading disruption across insurance services.

These examples are implementation recommendations based on good practice in Operational Resilience and the operating characteristics of CBS-1.

They should not be represented as scenarios expressly prescribed by BNM unless confirmed against the final or applicable BNM regulatory document.

AIA Bhd could strengthen its Severe but Plausible Scenario framework by ensuring that scenarios:

begin with the Critical Business Service and its Impact Tolerance;
use mapped Sub-CBS processes to identify disruption points;
challenge important people, process, technology, information, facility and third-party dependencies;
integrate Cyber and ICT Risks into the disruption pathway;
include combined and cascading failures where credible;
assume that selected preventive or recovery controls fail;
test actual response, alternate processing and recovery capabilities;
measure service harm and degradation throughout the scenario;
document vulnerabilities and lessons identified; and
translate scenario findings into tracked remediation and resilience investment.

Governance should also ensure that scenario selection and testing outcomes are visible to appropriate senior management and risk oversight bodies.

Management reporting should explain which Critical Business Service was tested, the Impact Tolerance challenged, the disruption assumptions used, the weaknesses identified, whether the service remained within tolerance and what remediation is required.

Scenario testing should not conclude merely because technology has been restored.

For CBS-1, successful recovery should include the restoration of application processing, validation of underwriting decisions, confirmation of premium records, accurate policy issuance, downstream reconciliation and controlled resolution of accumulated exceptions.

This end-to-end perspective is particularly important because the prompt requires scenario analysis to test service delivery rather than isolated system recovery.

Severe but Plausible Scenarios are essential for understanding whether the CBS-1 Insurance Policy Application and Issuance can remain resilient when AIA Bhd experiences severe operational stress.

Analysing scenarios at the Sub-CBS level provides the detailed visibility needed to identify where disruption may originate and how it can propagate across the end-to-end service.

Integrating Cyber and ICT Risks into scenario design ensures that technology, data, connectivity, and cyber failures are assessed as part of the actual service disruption pathway rather than as separate risk exercises.

Specific proactive risk management actions, supported by identifiable and auditable evidence, enable AIA Bhd to demonstrate that vulnerabilities are being actively addressed.

These scenarios should form the foundation for Operational Resilience scenario testing, with test outcomes used to guide remediation, risk treatment, investment decisions and continuous improvement of CBS-1.

This directly reflects the chapter's intended conclusion and scenario-testing foundation.

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



	If you have any questions, click to contact us.

View full post