Simpaisa Group - Policy Suite¶

I'll draft all three policy documents now. These are substantial documents - I'll write each in full, production-ready form.

POLICY 1: OPERATIONAL RESILIENCE POLICY¶

SIMPAISA GROUP

OPERATIONAL RESILIENCE POLICY

Field	Detail
Document Reference	SGP-OPS-001
Version	1.0
Status	Active
Owner	Chief Digital Officer (CDO)
Approver	Board of Directors
Effective Date	1 April 2026
Next Review Date	1 April 2027
Classification	Internal

Document Control¶

Revision History¶

Version	Date	Author	Changes
0.1	January 2026	CDO Office	Initial draft
0.2	February 2026	CDO Office, Legal, Compliance	Internal review and revision
0.3	March 2026	CDO Office	Incorporation of regulatory feedback
1.0	April 2026	CDO	Board-approved final version

Distribution¶

This policy is distributed to all senior management, department heads, and key operational personnel. It is available on the internal policy management system and is accessible to all employees. Certain appendices containing infrastructure mapping details are classified as Restricted and distributed on a need-to-know basis.

Outsourcing and Third-Party Management Policy (SGP-OPS-002)
Data Governance Policy (SGP-CDO-001)
Information Security Policy
Business Continuity and Disaster Recovery Policy
Incident Management Policy
Change Management Policy

1. Purpose and Scope¶

1.1 Purpose¶

This Operational Resilience Policy ("Policy") establishes Simpaisa Group's ("Simpaisa" or "the Group") framework for identifying, assessing, and managing operational disruptions to ensure that the Group can continue to deliver its important business services to customers, merchants, and counterparties within defined impact tolerances, regardless of the nature or severity of a disruption.

Operational resilience is a strategic priority for Simpaisa. As a cross-border payments operator with licences and regulated activities across nine jurisdictions - Singapore, Pakistan, Bangladesh, Nepal, Iraq, the United Arab Emirates, the United Kingdom, and Canada - the Group must maintain the continuity of payment flows that underpin the financial lives of its customers, many of whom are migrant workers reliant on remittance services for family support.

This Policy satisfies requirements arising from:

The Dubai Financial Services Authority (DFSA) operational resilience expectations as part of the Group's Category 3D licence application and ongoing supervisory obligations in the DIFC;
The Monetary Authority of Singapore (MAS) Technology Risk Management Guidelines and Business Continuity Management Guidelines;
The State Bank of Pakistan (SBP) Business Continuity Planning requirements;
The Financial Conduct Authority (FCA) operational resilience framework (PS21/3) applicable to the Group's UK entity;
PCI DSS v4.0 requirements relating to availability and resilience of cardholder data environments;
ISO 27001:2022 controls relating to information security continuity (Annex A, Control 5.29 and 5.30).

1.2 Scope¶

This Policy applies to:

All legal entities within the Simpaisa Group, including the Singapore HoldCo (Simpaisa Holdings Pte Ltd) and all nine subsidiary entities;
All employees, contractors, and secondees performing functions on behalf of any Simpaisa entity;
All third-party service providers and outsourcing partners whose services support important business services, as identified in Section 4 of this Policy;
All technology infrastructure, data, and facilities used to deliver important business services;
All geographies in which the Group operates, with specific consideration for frontier-market risks in Pakistan, Bangladesh, Nepal, and Iraq.

2. Definitions¶

Term	Definition
Active-Active Architecture	A disaster recovery model in which two or more fully operational environments simultaneously handle live production traffic, enabling immediate failover without downtime or data loss.
Business Continuity	The capability of the Group to continue delivering products and services at acceptable predefined levels following a disruptive incident.
CAB	Change Advisory Board. Simpaisa does not operate a CAB; change governance is embedded within the SRE model.
Critical Third Party	A third-party service provider whose failure or disruption would cause Simpaisa to breach an impact tolerance for an important business service.
Disruption	Any event - planned or unplanned - that impairs the Group's ability to deliver an important business service.
DFSA	Dubai Financial Services Authority, the financial regulator of the Dubai International Financial Centre.
Impact Tolerance	The maximum level of disruption to an important business service that Simpaisa and its stakeholders (customers, regulators, counterparties) can tolerate, expressed as a maximum duration, volume of transactions affected, or data integrity threshold.
Important Business Service (IBS)	A service provided by Simpaisa to external parties (customers, merchants, correspondent banks) the disruption of which could cause harm to customers, market integrity, or financial stability.
Incident	An unplanned event that causes or has the potential to cause disruption to an important business service.
MTD	Maximum Tolerable Disruption - the outer boundary of the impact tolerance, beyond which disruption is considered unacceptable.
RTO	Recovery Time Objective - the targeted duration within which a system, application, or process must be restored following a disruption.
RPO	Recovery Point Objective - the maximum period for which data loss is acceptable following a disruption.
SRE	Site Reliability Engineering - the operational discipline adopted by Simpaisa for managing reliability, change, and incident response without a traditional CAB structure.
Scenario Testing	A structured exercise in which Simpaisa tests its ability to remain within impact tolerances under a specific disruptive scenario.
Third Line	Internal Audit function, providing independent assurance over the operational resilience framework.

3. Policy Statements¶

3.1 Commitment to Operational Resilience¶

3.1.1 The Board of Directors accepts ultimate responsibility for the Group's operational resilience and approves this Policy, the list of important business services, and the impact tolerances associated with each service.

3.1.2 Simpaisa's approach to operational resilience prioritises the continuity of services to customers over the protection of internal systems, consistent with the regulatory expectation that harms to end-users are the primary driver of resilience investment.

3.1.3 The Group shall maintain operational resilience capabilities across all nine jurisdictions, with specific enhancements for frontier-market operating environments characterised by elevated infrastructure risk.

3.1.4 Operational resilience shall be embedded in the design of all new products, services, and technology investments from inception, not retrofitted after deployment.

3.2 Important Business Services¶

3.2.1 The following are designated as Important Business Services of the Simpaisa Group:

IBS Reference	Important Business Service	Description
IBS-001	Cross-Border Payment Processing	Initiation, routing, and execution of inbound and outbound payment instructions across all corridors, including Pay-In and Pay-Out flows.
IBS-002	Settlement and Reconciliation	Final settlement of payment obligations between Simpaisa, correspondent banks, mobile wallet operators, and card schemes; automated and manual reconciliation of nostro positions.
IBS-003	Merchant and Partner Portal	The web and API-based portal through which merchants, aggregators, and white-label wallet partners initiate payments, access reporting, and manage their accounts.
IBS-004	Compliance Screening	Real-time and batch sanctions screening, AML transaction monitoring, and customer due diligence checks applied to all payment flows and onboarding events.
IBS-005	Crypto Off-Ramp Processing	Conversion of cryptocurrency assets to fiat currency and disbursement to beneficiary accounts, including integration with Binance and licensed exchange counterparties.
IBS-006	Customer Remittance Initiation	The customer-facing channels (mobile application, web application, agent network) through which individual remittance senders initiate transfer instructions.

3.2.2 The Chief Digital Officer shall review and update the list of important business services annually, or following any material change to the Group's products, operating model, or regulatory obligations. Any changes shall be presented to the Board for approval.

3.2.3 Internal systems and processes that do not directly deliver services to external parties - such as HR systems, internal email, and financial reporting - are not classified as important business services for the purposes of this Policy, though they are subject to separate business continuity planning.

3.3 Impact Tolerances¶

3.3.1 The Board has approved the following impact tolerances for each Important Business Service:

IBS Reference	Service	Maximum Tolerable Disruption (MTD)	RTO	RPO	Trigger for Escalation to Board
IBS-001	Cross-Border Payment Processing	4 hours total unavailability in any 24-hour period	2 hours	Zero (active-active)	Disruption exceeding 2 hours or volume loss exceeding 30%
IBS-002	Settlement and Reconciliation	6 hours in any 24-hour period; no settlement cycle missed	4 hours	15 minutes	Missed settlement cycle or breach of correspondent SLA
IBS-003	Merchant and Partner Portal	8 hours in any 24-hour period	4 hours	1 hour	Disruption exceeding 4 hours or loss of API connectivity for >10 merchants simultaneously
IBS-004	Compliance Screening	1 hour; payment flows must be suspended if screening is unavailable beyond 1 hour	30 minutes	Zero	Any unscreened payment processed; screening unavailable for >30 minutes
IBS-005	Crypto Off-Ramp Processing	12 hours	6 hours	1 hour	Disruption exceeding 4 hours; custody risk identified
IBS-006	Customer Remittance Initiation	4 hours	2 hours	30 minutes	Disruption exceeding 2 hours in any primary corridor

3.3.2 Impact tolerances represent the outer boundary of acceptable disruption. The Group shall plan, invest, and test to ensure that actual RTOs and RPOs sit comfortably within impact tolerance thresholds, with sufficient safety margin.

3.3.3 Where Compliance Screening (IBS-004) is unavailable and cannot be restored within 30 minutes, payment processing shall be suspended across all corridors until screening is restored. The Group shall not process payments without sanctions screening under any circumstances, including during declared incidents. The MLRO shall be notified immediately upon any screening outage.

3.3.4 Impact tolerances shall be reviewed annually, following significant disruptions, and in response to changes in regulatory expectations or the Group's risk appetite.

3.4 Active-Active Architecture Requirement¶

3.4.1 All technology components supporting IBS-001 (Cross-Border Payment Processing) and IBS-004 (Compliance Screening) shall be deployed in an active-active configuration, with no single region or availability zone constituting a single point of failure.

3.4.2 Active-active deployment shall be implemented on Amazon Web Services across a minimum of two AWS regions, supplemented by Cloudflare's global network for edge routing, DNS resilience, DDoS mitigation, and - where in-country data residency requirements permit - regional traffic management.

3.4.3 In jurisdictions where in-country data residency is mandated (Pakistan, Bangladesh, Nepal, Iraq), the active-active architecture shall incorporate in-country compute and storage nodes to ensure that locally originated and locally settled transactions are processed and stored within national borders, consistent with Section 3.5 below.

3.4.4 The Chief Digital Officer shall maintain and annually certify an Infrastructure Resilience Map (Appendix A) documenting the active-active topology for each Important Business Service.

3.4.5 No Important Business Service shall be operated on a single-region or single-availability-zone basis. Any deviation from this requirement shall constitute an exception requiring Board-level approval under Section 9 of this Policy.

3.5 Data Residency and Regulatory Requirements¶

3.5.1 The Group's operational resilience architecture shall comply with all applicable data residency requirements. In-country data storage and processing requirements apply in Pakistan (SBP directives), Bangladesh (Bangladesh Bank guidelines), Nepal (Privacy Act and NRB regulations), and Iraq (Central Bank of Iraq requirements). Cloudflare and AWS regional infrastructure shall be configured to enforce data residency boundaries.

3.5.2 Resilience testing shall not involve the transmission of production customer data across jurisdictional boundaries where data localisation requirements apply. Synthetic data shall be used for cross-border testing purposes.

3.6 SRE Model for Incident Response¶

3.6.1 Simpaisa operates a Site Reliability Engineering (SRE) model for all operational and resilience management functions. The Group does not operate a Change Advisory Board (CAB). Reliability, change control, and incident response are governed by engineering disciplines embedded within the SRE function.

3.6.2 The SRE model shall incorporate the following core disciplines:

Error Budget Management: Each Important Business Service has a defined service level objective (SLO). The error budget represents the permissible deviation from 100% availability. When an error budget is consumed, the relevant engineering team shall redirect capacity from feature delivery to reliability improvement until the budget is restored.
Blameless Post-Mortems: All service disruptions exceeding 15 minutes duration shall be followed by a blameless post-mortem within 72 hours of service restoration, producing documented learnings and time-bound remediation actions.
Toil Reduction: The SRE function shall track and systematically reduce operational toil (manual, repetitive, automatable work) that introduces human-error risk to resilience-critical processes.
Automated Runbooks: Recovery procedures for all foreseeable failure modes of Important Business Services shall be documented as automated or semi-automated runbooks, executable without CAB approval during incidents.

3.6.3 The Head of SRE (reporting to the CDO) shall maintain a register of all SLOs and error budgets for Important Business Services. This register shall be reviewed monthly by the Technology Leadership Team and quarterly by the CDO.

3.6.4 Automated alerting and paging shall be configured for all Important Business Services, with defined escalation paths that do not require human intervention to initiate. On-call rotations shall cover all time zones relevant to the Group's operating jurisdictions.

4. Mapping of Resources Supporting Important Business Services¶

4.1 Framework¶

4.1.1 For each Important Business Service, Simpaisa shall maintain a comprehensive map of the resources - people, technology, data, facilities, and third parties - whose unavailability would impair the delivery of that service or cause an impact tolerance to be breached.

4.1.2 Resource maps shall be maintained in Appendix A (Infrastructure Resilience Map) and Appendix B (Service Dependency Register), updated at minimum annually and following any material change to the operating environment.

4.2 People Dependencies¶

4.2.1 The Group shall identify, for each Important Business Service, the minimum staffing level required to maintain operations within impact tolerances. These minimum staffing levels shall account for planned absences, peak transaction periods, and unplanned absences due to illness, civil unrest, or travel restrictions.

4.2.2 No Important Business Service shall have a single-person dependency for any critical operational function. Where such dependencies exist, they shall be escalated as exceptions and remediation plans put in place within 90 days.

4.2.3 The Group shall maintain cross-training programmes ensuring that for each critical role, a minimum of two trained individuals are capable of performing the function across different geographic locations.

4.2.4 Key person risk shall be assessed annually for all senior technical and operational roles. The assessment shall consider the concentration of institutional knowledge, access credentials, and vendor relationships in individual persons.

4.3 Technology Dependencies¶

4.3.1 Technology dependencies for each Important Business Service shall include: cloud infrastructure components, application services, databases, message queues, API gateways, network infrastructure, monitoring and observability tooling, and developer access systems.

4.3.2 All technology dependencies shall be assessed for single points of failure. Identified single points of failure shall be remediated within timescales proportionate to their criticality, as defined in the remediation prioritisation framework in Appendix C.

4.4 Third-Party Dependencies¶

4.4.1 Third-party dependencies for each Important Business Service are summarised below. Full assessment details are maintained in the Third-Party Register (governed by the Outsourcing and Third-Party Management Policy, SGP-OPS-002).

Important Business Service	Critical Third-Party Dependencies
IBS-001: Cross-Border Payment Processing	AWS (compute, networking), Cloudflare (edge, routing), 1LINK (Pakistan IBFT), Easypaisa, JazzCash (Pakistan mobile wallets), bKash, Nagad (Bangladesh mobile wallets), Visa, Mastercard (card scheme routing)
IBS-002: Settlement and Reconciliation	Correspondent banking partners, SWIFT network, 1LINK, card schemes, mobile wallet operators
IBS-003: Merchant and Partner Portal	AWS (hosting), Cloudflare (WAF, CDN), identity provider
IBS-004: Compliance Screening	Eastnets (sanctions screening engine), SWIFT Sanctions data feeds, regulatory watchlist providers
IBS-005: Crypto Off-Ramp Processing	Binance (crypto exchange), licensed custody partners, blockchain network nodes
IBS-006: Customer Remittance Initiation	AWS, Cloudflare, mobile network operators (SMS OTP), app stores (Apple, Google)

4.5 Facilities Dependencies¶

4.5.1 Simpaisa is a cloud-first organisation. No Important Business Service is dependent on a single physical data centre operated by the Group. However, key office facilities supporting operational staff (dealing, compliance, customer service) shall be included in resilience planning.

4.5.2 Remote working capability shall be maintained for all roles supporting Important Business Services. The Group shall test remote-working resilience at least annually.

5. Roles and Responsibilities¶

Role	Responsibilities
Board of Directors	Approves this Policy, important business service list, and impact tolerances. Receives annual self-assessment report. Challenges management on adequacy of resilience investment.
Chief Digital Officer (CDO)	Policy Owner. Leads operational resilience programme. Maintains Infrastructure Resilience Map. Approves SRE framework. Reports to Board on resilience status. Chairs Operational Resilience Steering Group.
Chief Executive Officer (CEO)	Accountable for overall resilience posture. Escalation point for incidents breaching impact tolerances. External spokesperson during major incidents.
Chief Operating Officer (COO)	Accountable for operational processes and people resilience. Owns business continuity planning for non-technology functions.
Chief Risk Officer (CRO)	Integrates operational resilience into the Group's risk framework. Oversees scenario testing programme. Reports to Risk Committee.
Chief Compliance Officer (CCO) / MLRO	Ensures resilience of compliance screening services. Manages regulatory notification obligations during incidents.
Head of SRE	Manages SRE function. Maintains SLOs, error budgets, and incident response capability. Leads post-mortem process. On-call escalation point.
Country Managers (Pakistan, Bangladesh, Nepal, Iraq)	Manage frontier-market resilience risks. Report local infrastructure incidents. Maintain relationships with local regulators and utilities providers.
Internal Audit	Independent assurance over operational resilience framework, scenario testing, and control effectiveness. Reports to Audit Committee.
All Employees	Responsible for understanding their role in maintaining continuity of Important Business Services. Participate in training and testing exercises.

6. Procedures and Controls¶

6.1 Scenario Testing Programme¶

6.1.1 The Group shall conduct structured scenario testing of each Important Business Service at minimum annually, and additionally following any material change to the operating environment or following a real-world disruption.

6.1.2 Scenario tests shall be designed to challenge the Group's ability to remain within its impact tolerances and shall not be designed merely to confirm existing assumptions.

6.1.3 The following scenarios shall be tested at minimum:

Scenario A - Cloud Provider Outage Simulation of the complete loss of a primary AWS region, testing whether active-active failover routes traffic to the secondary region within the RTO for each Important Business Service, and whether data integrity is maintained within RPO thresholds. Test shall include verification that Cloudflare failover routing activates correctly and that monitoring and alerting remain operational during the failover event.

Scenario B - Key Operator Failure Simulation of the unexpected loss of a critical third-party operator - tested on a rotating basis across: Eastnets (sanctions screening), 1LINK (Pakistan IBFT), a primary mobile wallet operator (e.g. bKash or Easypaisa), and Binance (crypto off-ramp). Test shall assess: time to detect failure, activation of alternative routing or manual fallback procedures, customer communication, and regulatory notification.

Scenario C - Cyber Incident (Ransomware / Data Exfiltration) Tabletop or live simulation of a significant cyber attack affecting production systems. Shall include: incident detection and triage, invocation of incident response runbooks, isolation of affected systems while maintaining unaffected Important Business Services, engagement of external IR retainer, regulatory notification obligations, and customer and media communication. Test shall assess SRE response under the constraint of potentially compromised tooling.

Scenario D - Key Person Loss Simulation of the sudden, unplanned unavailability of a designated key person (CTO, Head of SRE, or a named critical engineer). Test shall verify that knowledge transfer, documented runbooks, and cross-training enable the Group to remain within impact tolerances without the unavailable individual.

Scenario E - Office or Facility Loss Simulation of the loss of a primary office location (e.g. Dubai, Singapore, or Karachi) requiring full transition to remote working for all personnel based at that location. Test shall verify remote access capacity, VPN and identity management resilience, and maintenance of security controls during remote operations.

Scenario F - Frontier Market Infrastructure Failure Pakistan, Bangladesh, Nepal, and Iraq-specific scenarios including: extended power outage (>8 hours), national telecoms failure affecting mobile network operators and internet service providers, civil unrest restricting staff movement, and suspension of a local regulatory permission. Tests shall be conducted in-country and shall assess the effectiveness of in-country redundancy, local fallback procedures, and communication with regulators.

6.1.4 Testing shall be conducted without disrupting live services wherever possible. Where a test would require disruption to live Important Business Services, it shall be conducted during a pre-agreed maintenance window with merchant notification, and shall require prior approval from the CDO and CEO.

6.1.5 Each scenario test shall produce a written test report within 10 business days of the test, documenting: test scope and methodology, results against impact tolerances, weaknesses identified, and time-bound remediation actions. Test reports shall be reviewed by the CRO and CDO, and summaries submitted to the Board annually.

6.2 Frontier Market Resilience Controls¶

6.2.1 Power Resilience (Pakistan, Bangladesh, Nepal, Iraq): In-country operations shall be supported by documented power continuity arrangements including uninterruptible power supply (UPS) for critical office equipment and, where applicable, generator arrangements for in-country data nodes. The Group shall maintain relationships with local co-location providers operating N+1 or better power configurations.

6.2.2 Telecoms Resilience: In-country connectivity for operational staff shall use a minimum of two independent internet service providers from different underlying infrastructure providers. Mobile data connectivity (SIM-based) shall be available as a tertiary fallback. Where a specific ISP has been identified as a single point of failure, remediation shall be prioritised in the annual resilience investment plan.

6.2.3 Civil Unrest and Staff Safety: Country Managers shall maintain and annually review a Staff Safety and Business Continuity Plan for each frontier-market jurisdiction. This plan shall include: evacuation procedures, communication trees, remote working activation, and pre-agreed authority for the Country Manager to suspend local operations and redirect transaction flows to alternative corridors.

6.2.4 Regulatory Permission Suspension: In jurisdictions where regulatory permission is subject to heightened political or macroeconomic risk, the Group shall maintain a documented contingency plan for the orderly suspension of customer-facing services, return of customer funds, and notification of the Singapore HoldCo and relevant regulators.

6.2.5 Mobile Wallet Operator Failure: Given the dependence of the Pakistan and Bangladesh corridors on Easypaisa, JazzCash, bKash, and Nagad, the Group shall maintain active integration with a minimum of two mobile wallet operators per corridor, enabling failover disbursement if a primary operator is unavailable. The SRE team shall test this failover routing quarterly.

6.3 Communication Protocols¶

6.3.1 Internal Communication: Upon detection of a potential impact tolerance breach, the on-call SRE engineer shall immediately notify the Head of SRE and initiate the relevant incident runbook. The Head of SRE shall notify the CDO within 30 minutes of a P1 incident declaration. The CDO shall notify the CEO, COO, and CCO. An internal incident bridge (video/voice call) shall be established within 45 minutes.

6.3.2 Regulatory Communication: The CCO shall be responsible for all regulatory notifications. Notification timelines shall comply with applicable jurisdictional requirements:

Jurisdiction	Regulator	Notification Trigger	Timeline
DIFC	DFSA	Material operational disruption, cyber incident	Within 24 hours of discovery; written follow-up within 72 hours
Singapore	MAS	Significant technology incident (per MAS TRM Guidelines)	Within 1 hour for major incidents; full report within 14 days
UK	FCA	Operational disruption affecting UK customers	Within 24 hours; Operational Resilience return as required
Pakistan	SBP	System outage affecting payment services	As per SBP directives; typically within 4 hours
Bangladesh	Bangladesh Bank	Payment system disruption	Within 24 hours

The CCO shall maintain a Regulatory Notification Log for all incidents requiring regulatory disclosure.

6.3.3 Merchant and Partner Communication: The COO shall coordinate merchant communications during incidents. For disruptions to IBS-001, IBS-002, or IBS-003 exceeding 30 minutes, an initial communication shall be issued to all affected merchants within 60 minutes of incident declaration, through the merchant communication platform and directly to account managers of top-20 merchants by volume. Updates shall be issued at minimum every 60 minutes until service is restored.

6.3.4 Media Communication: All external media enquiries relating to incidents shall be directed to the CEO or a designated spokesperson. No technical or operational staff shall communicate with media without CEO authorisation. The Group shall maintain pre-approved media statement templates for common incident scenarios (Appendix D).

6.3.5 Customer Communication: For disruptions to IBS-006 (Customer Remittance Initiation), in-app notifications shall be triggered automatically by the SRE monitoring system. The customer service team shall be briefed within 30 minutes of incident declaration and equipped with an approved customer communication script.

7. Monitoring and Reporting¶

7.1 Operational Metrics¶

7.1.1 The SRE function shall maintain real-time dashboards monitoring the availability, latency, error rates, and transaction throughput of each Important Business Service. Dashboard access shall be available to the Head of SRE, CDO, and CRO at minimum.

7.1.2 Automated alerting shall be configured to page on-call engineers when service metrics breach defined thresholds that indicate potential impact tolerance breach risk. Alert thresholds shall be reviewed quarterly.

7.1.3 Monthly SLO performance reports shall be produced by the Head of SRE and reviewed by the CDO. Any month in which an error budget is fully consumed shall trigger a reliability sprint for the relevant service.

7.2 Board and Committee Reporting¶

Report	Frequency	Audience	Content
Operational Resilience Dashboard	Monthly	Technology Leadership Team	SLO performance, error budgets, incident summary
Operational Resilience Report	Quarterly	Risk Committee	Impact tolerance breaches, scenario test results, third-party resilience events, remediation status
Annual Self-Assessment	Annually	Board of Directors	Assessment against each important business service and impact tolerance, scenario test outcomes, key vulnerabilities, investment plan
Incident Reports	As required	Board (for P1 events), Risk Committee	Post-mortem findings, root cause, customer impact, regulatory notifications made

7.3 Annual Self-Assessment¶

7.3.1 The CDO shall lead an annual self-assessment of the Group's operational resilience, to be completed by 31 March each year and presented to the Board at the first Board meeting of Q2.

7.3.2 The self-assessment shall evaluate: whether the Group has remained within its impact tolerances throughout the year; the results of all scenario tests; the effectiveness of resilience controls; any material changes to the resource map; progress against prior year remediation actions; and the Group's readiness to meet evolving regulatory expectations including DFSA operational resilience requirements.

7.3.3 Internal Audit shall provide independent assurance on the self-assessment, including a review of testing evidence and control documentation.

8. DFSA Expectations for Operational Resilience¶

8.1 As part of its Category 3D licence application in the DIFC, and as an ongoing obligation of DFSA-regulated status, Simpaisa shall meet the DFSA's expectations for operational resilience, which include:

Identification of important business services with board-level endorsement;
Setting of impact tolerances approved by the Board;
Mapping of resources supporting important business services;
Testing of resilience against a range of severe but plausible scenarios;
Maintaining the ability to remain within impact tolerances;
Reporting to the DFSA on operational resilience, including notification of material disruptions within prescribed timeframes.

8.2 The DFSA's Outsourcing Rules (COB Module and GEN Module) impose obligations on the Group in respect of outsourced functions that support important business services. These obligations are addressed in the Outsourcing and Third-Party Management Policy (SGP-OPS-002).

8.3 The CDO shall ensure that Simpaisa's operational resilience framework is reviewed against DFSA guidance and supervisory communications at minimum annually, and updated as necessary to reflect regulatory developments.

8.4 In the event of a material disruption to any Important Business Service, the CCO shall assess whether DFSA notification is required and, if so, shall submit an initial notification within 24 hours and a detailed written report within 72 hours.

9. Exceptions and Escalation¶

9.1 Any deviation from the requirements of this Policy - including any failure to meet the active-active architecture requirement, any single-person dependency in a critical function, or any Important Business Service operating without a tested recovery procedure - constitutes an exception requiring formal management.

9.2 Exceptions shall be documented using the Exception Request Form (Appendix E) and submitted to the CDO for review. The CDO may approve exceptions within the following parameters:

Low-risk exceptions (no impact on impact tolerances; remediation plan in place within 90 days): CDO approval sufficient;
Medium-risk exceptions (potential to extend time to recover beyond RTO; remediation plan within 60 days): CDO plus CRO approval required;
High-risk exceptions (risk of impact tolerance breach; remediation plan within 30 days): Board approval required.

9.3 All exceptions shall be logged in the Exceptions Register, reviewed monthly by the CDO, and reported quarterly to the Risk Committee.

9.4 Where a real-world disruption results in an impact tolerance being breached, the CDO shall notify the CEO and Board within 2 hours, the CCO shall assess regulatory notification obligations, and a P1 post-mortem shall be completed within 72 hours of service restoration.

SGP-OPS-002: Outsourcing and Third-Party Management Policy
SGP-CDO-001: Data Governance Policy
Information Security Policy
Incident Management Policy and Runbooks
Business Continuity and Disaster Recovery Policy
Change Management Policy (SRE Framework)
Acceptable Use Policy

Appendices¶

Appendix A: Infrastructure Resilience Map (RESTRICTED)¶

Template: For each Important Business Service, document the following fields. Full maps maintained in secure configuration management system.

Field	Content
IBS Reference	e.g. IBS-001
Primary Region	e.g. AWS ap-southeast-1 (Singapore)
Secondary Region	e.g. AWS me-central-1 (UAE)
In-Country Nodes	e.g. Pakistan: local AWS Outpost / co-location
Cloudflare Services	e.g. Load Balancing, Argo Smart Routing, WAF
Key Dependencies	List of upstream and downstream dependencies
Failover Mechanism	e.g. Automated DNS failover via Cloudflare; Active-Active database replication
Last Tested	Date and outcome

Appendix B: Service Dependency Register¶

Maintained in the Group's configuration management database (CMDB). Owner: Head of SRE. Review: Quarterly.

Appendix C: Remediation Prioritisation Framework¶

Priority	Criteria	Target Remediation Timescale
Critical	Single point of failure; breach of active-active requirement; impact tolerance at immediate risk	30 days
High	Identified weakness in scenario test; RTO materially exceeds target	60 days
Medium	Process gap; partial redundancy; key person dependency	90 days
Low	Documentation gap; toil reduction opportunity; enhancement	180 days

Appendix D: Media Statement Templates¶

Pre-approved template statements for the following scenarios: 1. Payment processing disruption - service degraded 2. Payment processing disruption - service restored 3. Cyber security incident - holding statement 4. Third-party provider failure affecting service 5. Regulatory notification issued

Templates maintained by the Communications function. Owner: CEO. Review: Annually.

Appendix E: Exception Request Form¶

Field	Detail
Exception Reference	Auto-assigned
Date of Request
Requestor
Policy Section Affected
Description of Deviation
Risk Assessment	Low / Medium / High
Proposed Compensating Controls
Remediation Plan and Target Date
Approver	CDO / CDO + CRO / Board
Approval Date
Next Review Date

Appendix F: Scenario Test Record Template¶

Field	Detail
Test Reference
Scenario	A / B / C / D / E / F
Test Date
Test Type	Tabletop / Partial Live / Full Live
Important Business Services in Scope
Test Facilitator
Participants
Objectives
Results - Impact Tolerance Outcome	Within / Breached
Weaknesses Identified
Remediation Actions	(Owner, due date, priority)
Report Approval	CDO / CRO
Submitted to Board	Yes / No / Date

POLICY 2: OUTSOURCING AND THIRD-PARTY MANAGEMENT POLICY¶

SIMPAISA GROUP

OUTSOURCING AND THIRD-PARTY MANAGEMENT POLICY

Field	Detail
Document Reference	SGP-OPS-002
Version	1.0
Status	Active
Owner	Chief Operating Officer (COO)
Approver	Board of Directors
Effective Date	1 April 2026
Next Review Date	1 April 2027
Classification	Internal

Document Control¶

Revision History¶

Version	Date	Author	Changes
0.1	January 2026	COO Office	Initial draft
0.2	February 2026	COO, CDO, Legal, Compliance	Internal review
0.3	March 2026	COO	Incorporation of DFSA outsourcing rule mapping
1.0	April 2026	COO	Board-approved final version

1. Purpose and Scope¶

1.1 Purpose¶

This Outsourcing and Third-Party Management Policy ("Policy") establishes the framework governing Simpaisa Group's ("Simpaisa" or "the Group") engagement with, oversight of, and exit from third-party relationships. It ensures that the Group maintains effective control over outsourced functions, manages concentration risk, fulfils its regulatory obligations in respect of outsourcing across all operating jurisdictions, and protects the continuity, security, and integrity of services delivered to customers and merchants.

The Group relies on a substantial ecosystem of third-party providers - cloud infrastructure, payment network operators, sanctions screening, cryptocurrency exchange services, and mobile wallet operators - each of which presents operational, financial, reputational, and regulatory risk if not appropriately governed.

This Policy satisfies requirements under:

DFSA Outsourcing Rules (GEN Module, Chapter 5 and COB Module) applicable to the Group's DIFC entity and Category 3D licence;
MAS Guidelines on Outsourcing (Singapore);
FCA Operational Resilience (PS21/3) and Outsourcing guidance (SS2/21) applicable to the UK entity;
State Bank of Pakistan (SBP) Outsourcing Regulations;
ISO 27001:2022 (Supplier Relationships, Annex A Controls 5.19–5.22);
PCI DSS v4.0 Requirements 12.8 (management of service providers).

1.2 Scope¶

This Policy applies to:

All Simpaisa Group entities;
All employees and functional heads responsible for engaging or managing third-party providers;
All existing and prospective third-party relationships, including outsourcing arrangements, cloud service providers, technology vendors, payment network operators, compliance service providers, and professional services firms;
Third parties who in turn engage sub-contractors in the delivery of services to Simpaisa (sub-outsourcing).

2. Definitions¶

Term	Definition
Outsourcing	An arrangement in which Simpaisa relies upon a third party to perform a process, service, or activity on an ongoing basis that would otherwise be performed by Simpaisa itself, and which forms part of or supports Simpaisa's regulated activities or important business services.
Material Outsourcing	Outsourcing of a function that, if disrupted, would materially impact the Group's ability to deliver important business services, meet regulatory obligations, or comply with applicable law. Equivalent to "critical or important" outsourcing under DFSA and FCA terminology.
Non-Material Outsourcing	Outsourcing of a function that does not meet the materiality threshold, assessed using the Materiality Assessment Framework in Section 4.
Procurement	The purchase of goods or standardised services from a vendor where Simpaisa retains full control over the process and the vendor has no ongoing operational role in service delivery. Procurement relationships are not subject to outsourcing governance requirements but are subject to vendor onboarding controls.
Partnership	A commercial arrangement with a third party to jointly develop, distribute, or market products or services. Partnerships involving operational dependencies on the partner for regulated service delivery are treated as outsourcing for the purposes of this Policy.
Cloud Service Provider (CSP)	A provider of on-demand computing, storage, networking, and platform services delivered via the internet. Simpaisa's primary CSPs are AWS and Cloudflare.
Sub-Outsourcing	An arrangement in which a third party engaged by Simpaisa in turn engages another party to perform part of the outsourced function.
Concentration Risk	The risk arising from excessive dependence on a single third party, technology platform, or geographic location such that a failure of that third party would simultaneously impair multiple important business services.
Fourth Party	A sub-contractor or supplier to a Simpaisa third party whose failure could indirectly impair Simpaisa's important business services.
Intragroup Outsourcing	Services provided by one Simpaisa Group entity to another. Intragroup arrangements are subject to a proportionate governance framework and formal intragroup service agreements.
SLA	Service Level Agreement - a contractual commitment by a third party to deliver services within defined performance, availability, and quality parameters.

3. Policy Statements¶

3.1 Governing Principles¶

3.1.1 Simpaisa shall at all times retain responsibility for any function it outsources. Outsourcing does not transfer regulatory accountability. The Group shall ensure that all outsourced functions are governed, monitored, and controlled to a standard consistent with that which would apply if the function were performed internally.

3.1.2 No function shall be outsourced where doing so would impair the Group's ability to meet its regulatory obligations, fulfil its duties to customers, or comply with applicable law.

3.1.3 The regulatory right of access and audit over outsourced functions shall be preserved in all material outsourcing contracts. No arrangement shall be entered into that would prevent a relevant regulator from accessing records, data, or premises associated with outsourced regulated functions.

3.1.4 The Group shall manage concentration risk by actively avoiding single-provider dependencies for critical functions, maintaining alternative providers or fallback arrangements, and monitoring the cumulative impact of third-party failures on the Group's risk profile.

3.1.5 All material outsourcing arrangements shall be notified to relevant regulators where required, prior to commencement of the arrangement.

3.2 Definitions of Outsourcing vs Procurement vs Partnership¶

3.2.1 The following decision framework shall be applied to classify all third-party engagements:

A third-party engagement is Outsourcing if: - The third party performs an ongoing operational process that Simpaisa would otherwise perform itself; - The function relates to or supports a regulated activity or Important Business Service; - Simpaisa relies on the third party's systems, people, or data to deliver a service to customers or meet regulatory obligations.

A third-party engagement is Procurement if: - Simpaisa purchases a standardised good or service (e.g. office supplies, software licences with no operational dependency, one-off consultancy); - Simpaisa retains full control over the function and can substitute the supplier without operational disruption; - The engagement is time-limited, project-based, and does not involve ongoing operational reliance.

A third-party engagement is a Partnership if: - A commercial agreement involves joint development, distribution, or marketing of products; - The partner does not have an ongoing operational role in Simpaisa's regulated service delivery.

3.2.2 Where there is doubt as to the appropriate classification, the COO shall determine the classification in consultation with the CCO and CDO, having regard to the substance of the arrangement.

4. Materiality Assessment Framework¶

4.1 Materiality Criteria¶

4.1.1 All outsourcing arrangements shall be assessed for materiality using the following criteria. An arrangement is classified as Material if any one of the following applies:

Criterion	Assessment
Important Business Service dependency	The third party supports one or more of the Group's Important Business Services as defined in the Operational Resilience Policy (SGP-OPS-001)
Regulated function	The outsourced function forms part of or directly supports a regulated activity of any Simpaisa entity
Customer impact	Failure of the third party would directly impair service delivery to customers or result in customer harm
Compliance function	The third party performs a function required by law or regulation, including AML/CFT screening, sanctions checking, or regulatory reporting
Data sensitivity	The third party processes, stores, or has access to confidential customer data, cardholder data (PCI DSS), or personal data at scale
Financial materiality	Annual contract value exceeds USD 250,000, or the third party is the sole source of a revenue-generating service
Substitutability	The third party cannot be replaced within 30 days without material operational disruption

4.1.2 Where a third-party arrangement is assessed as Non-Material, it shall be subject to standard vendor onboarding and periodic review but is not subject to the full due diligence, contractual, and ongoing monitoring requirements of this Policy applicable to material arrangements.

4.1.3 The materiality assessment shall be documented and retained in the Third-Party Register. Materiality assessments shall be reviewed annually and upon any material change to the third party's role or the Group's operating model.

4.2 Classification of Current Material Third-Party Relationships¶

Third Party	Service	IBS Dependency	Materiality Classification
Amazon Web Services (AWS)	Cloud compute, storage, networking, managed services	IBS-001, 002, 003, 004, 005, 006	Material - Critical
Cloudflare	Edge network, WAF, DDoS mitigation, routing	IBS-001, 003, 006	Material - Critical
Eastnets	Sanctions screening engine and watchlist management	IBS-004	Material - Critical
Binance	Cryptocurrency exchange and liquidity provider (crypto off-ramp)	IBS-005	Material - Critical
1LINK	Pakistan Interbank Fund Transfer (IBFT) network	IBS-001, 002	Material - Critical
Easypaisa	Pakistan mobile wallet disbursement	IBS-001, 002, 006	Material - High
JazzCash	Pakistan mobile wallet disbursement	IBS-001, 002, 006	Material - High
bKash	Bangladesh mobile wallet disbursement	IBS-001, 002, 006	Material - High
Nagad	Bangladesh mobile wallet disbursement	IBS-001, 002, 006	Material - High
Visa	Card scheme routing and settlement	IBS-001, 002	Material - High
Mastercard	Card scheme routing and settlement	IBS-001, 002	Material - High

5. Due Diligence Requirements¶

5.1 General Principles¶

5.1.1 Before entering into any material outsourcing arrangement, and before renewing an existing material arrangement, Simpaisa shall conduct comprehensive due diligence on the prospective third party. Due diligence shall be proportionate to the materiality and risk profile of the arrangement.

5.1.2 Due diligence findings shall be documented in a Third-Party Due Diligence Report and reviewed by the COO and CRO before contract execution. For Critical material arrangements, the report shall be reviewed by the Board or a delegated committee.

5.1.3 Due diligence shall be refreshed in full at every contract renewal and may be triggered at any point by a material adverse event affecting the third party.

5.2 Financial Due Diligence¶

5.2.1 For material third parties, the following financial assessments shall be conducted:

Review of the most recent audited financial statements (minimum 2 years);
Assessment of credit ratings (where available) or equivalent financial stability indicators;
Assessment of ownership structure, including any recent changes in control, private equity involvement, or distressed financial indicators;
Review of publicly available news and market intelligence regarding the third party's financial health.

5.2.2 Where a material third party is privately held or operates in a jurisdiction with limited financial transparency (e.g. certain frontier-market mobile wallet operators), the Group shall document alternative financial health indicators and apply enhanced ongoing monitoring.

5.3 Operational Due Diligence¶

5.3.1 Operational due diligence shall assess:

The third party's business continuity and disaster recovery arrangements, including RTO and RPO commitments;
The third party's own supply chain and sub-contractor dependencies (fourth-party risk);
Geographic concentration of the third party's operations and infrastructure;
Track record of service delivery, including historical incident data and uptime statistics;
Staffing and key person risk within the third party;
Capacity to support Simpaisa's anticipated volumes, including peak transaction scenarios.

5.4 Security Due Diligence¶

5.4.1 Security due diligence shall assess:

Current certifications held by the third party: ISO 27001, SOC 2 Type II, PCI DSS (where relevant), and any jurisdiction-specific certifications;
Penetration testing practices and frequency;
Vulnerability management and patching programmes;
Incident response capability and historical incident disclosure practices;
Data encryption standards (in transit and at rest);
Access control and identity management practices;
Sub-processor and data-sharing practices.

5.4.2 For third parties processing cardholder data on behalf of Simpaisa, confirmation of current PCI DSS compliance status and scope shall be obtained annually from a Qualified Security Assessor (QSA) report or Attestation of Compliance (AoC).

5.4.3 The CDO shall define minimum information security standards that all material third parties are required to meet. Third parties unable to demonstrate these standards shall not be engaged as material suppliers without Board approval and documented compensating controls.

5.5 Compliance and Regulatory Due Diligence¶

5.5.1 Compliance due diligence shall assess:

Applicable regulatory licences and authorisations held by the third party in each relevant jurisdiction;
History of regulatory enforcement actions, sanctions, fines, or adverse findings;
AML/CFT programme quality (where the third party is a financial institution or handles customer funds);
Sanctions screening practices (where the third party handles payment flows);
Data protection practices and applicable regulatory framework;
Approach to sub-outsourcing and contractual flow-down of compliance obligations.

5.5.2 Politically exposed persons (PEP) and adverse media screening shall be conducted on the ultimate beneficial owners and senior management of all new material third parties, and refreshed annually.

5.6 Reputational Due Diligence¶

5.6.1 Reputational due diligence shall assess:

Public perception of the third party, including media coverage, customer complaint trends, and social media indicators;
Any history of association with financial crime, regulatory action, or reputational incidents;
Alignment of the third party's values and practices with Simpaisa's brand and compliance culture;
Assessment of risks arising from the third party's other customers or business activities (e.g. Binance's regulatory history in multiple jurisdictions).

6. Contractual Requirements¶

6.1 Mandatory Contract Terms¶

6.1.1 All material outsourcing contracts shall include, at minimum, the following provisions:

Service Levels and Performance: - Defined SLAs covering availability, response times, and throughput aligned to Simpaisa's impact tolerances; - Remedies for SLA breach, including service credits and, for repeated or severe breaches, rights of termination; - Regular performance reporting obligations on the third party; - Requirements for advance notice of planned maintenance and change.

Audit Rights: - An explicit right for Simpaisa, its internal and external auditors, and relevant regulators to audit the third party's performance, controls, and records relating to the outsourced function; - The right to conduct on-site audits with reasonable notice (typically 10 business days) and without notice in the event of a material incident; - An obligation on the third party to provide audit cooperation and access to relevant staff, systems, and documentation.

Data Protection and Information Security: - Obligations to process data only as instructed by Simpaisa and in compliance with applicable data protection law; - Minimum information security standards, consistent with the Group's Data Governance Policy (SGP-CDO-001) and Information Security Policy; - Notification obligations for security incidents and data breaches, including notification to Simpaisa within 24 hours of discovery; - Data residency obligations where applicable (see Section 7 below); - Obligations in respect of data return and deletion upon contract termination.

Business Continuity: - Third-party obligation to maintain a business continuity plan and disaster recovery capability aligned with the RTOs and RPOs required for Simpaisa's Important Business Services; - Requirement to test business continuity arrangements at minimum annually and to share test results with Simpaisa; - Obligation to notify Simpaisa promptly of any incident affecting the third party's ability to deliver services.

Sub-Outsourcing Controls: - Prohibition on sub-outsourcing of material functions without Simpaisa's prior written consent; - Flow-down obligations requiring that sub-contractors are bound by equivalent standards for security, data protection, audit rights, and regulatory compliance; - Right for Simpaisa to object to or require replacement of a sub-contractor.

Exit and Transition: - Defined exit rights, including termination for breach, termination for regulatory requirement, and termination for convenience with defined notice periods; - Third-party obligations to support an orderly transition upon exit, including provision of data, documentation, and reasonable transition assistance for a period of not less than 90 days; - Data return and destruction obligations upon termination; - Prohibition on the third party disrupting services during any exit or dispute period.

Regulatory Compliance: - Obligation to maintain all licences, authorisations, and regulatory approvals required to perform the outsourced function; - Obligation to notify Simpaisa of any regulatory action, investigation, or change in regulatory status; - Obligation to comply with applicable law, including AML/CFT, sanctions, and data protection requirements; - Acknowledgement of regulators' right of access and audit.

Governing Law and Jurisdiction: - Governing law and dispute resolution provisions shall be assessed in the context of Simpaisa's enforcement position; preference shall be given to jurisdictions with reliable commercial courts and enforcement mechanisms.

6.2 Enhanced Provisions for Critical Third Parties¶

6.2.1 For third parties classified as Critical (see Section 4.2), contracts shall additionally include:

Dedicated relationship management provisions, including named contacts and escalation paths;
Incident management integration provisions, including participation in Simpaisa's incident response process during major outages;
Annual resilience testing participation (where operationally feasible);
Right to require the third party to remediate identified security or resilience gaps within defined timescales.

7. Cloud Provider Governance¶

7.1 AWS Governance¶

7.1.1 AWS is a Critical material third party supporting all of Simpaisa's Important Business Services. AWS governance shall include:

A designated AWS account management framework operating under the principle of least privilege, with multi-account architecture separating production, staging, and development environments;
AWS region selection and data residency controls enforced through AWS Service Control Policies (SCPs), preventing data from being stored or processed outside approved regions for jurisdictions with data localisation requirements;
Active monitoring of AWS service health and service interruption notifications, integrated into SRE alerting;
Annual review of AWS Enterprise Support Agreement and documented escalation path to AWS senior support during P1 incidents;
Participation in AWS Business Continuity and Resilience review programmes;
Annual assessment of AWS shared responsibility model obligations and Simpaisa's fulfilment of its responsibilities.

7.1.2 AWS Reserved Instance and contractual commitments shall be reviewed annually by the COO and CFO to assess concentration risk arising from financial commitment to a single provider.

7.1.3 The Group shall maintain a multi-region deployment strategy for all Important Business Services hosted on AWS, consistent with the Operational Resilience Policy's active-active architecture requirement.

7.2 Cloudflare Governance¶

7.2.1 Cloudflare is used for edge network services, web application firewall, DDoS mitigation, and - where data residency requirements permit - intelligent routing and CDN services. Cloudflare governance shall include:

Cloudflare account access controls managed through centralised identity management, with MFA enforced for all accounts;
Regular review of Cloudflare Workers, routing rules, and WAF policies by the SRE team, with change management embedded in the SRE model;
Monitoring of Cloudflare service status integrated into SRE dashboards;
Assessment of Cloudflare's data processing locations in the context of in-country data residency requirements: Cloudflare shall not be used for storage or processing of data subject to localisation requirements in Pakistan, Bangladesh, Nepal, or Iraq without confirmation that Cloudflare Dedicated Egress IP or equivalent in-country routing is in place;
Annual security review of Cloudflare configuration, including WAF rule effectiveness and Zero Trust access policies.

7.3 In-Country Data Residency and Cloud Deployment¶

7.3.1 For jurisdictions with data localisation requirements, the Group shall use a combination of: - AWS regional deployments (where available in-country or in-region, e.g. AWS Middle East region for UAE); - AWS Outposts or local cloud partners for in-country compute where a native AWS region is unavailable; - Cloudflare Data Localisation Suite to enforce data residency at the edge.

7.3.2 The CDO shall maintain a Data Residency Compliance Map (maintained in the Data Governance Policy, SGP-CDO-001) documenting the cloud infrastructure configuration for each jurisdiction and the controls in place to enforce data localisation requirements.

8. Concentration Risk Management¶

8.1 The Group shall assess and actively manage concentration risk arising from: - Single-provider dependency (e.g. AWS as the sole cloud provider for all Important Business Services); - Geographic concentration (e.g. all in-country connectivity routed through a single ISP); - Third-party interdependency (e.g. Cloudflare routing traffic to AWS; failure of one amplifying impact of the other); - Corridor concentration (e.g. Pakistan corridor entirely dependent on 1LINK for IBFT).

8.2 A Concentration Risk Assessment shall be conducted annually by the COO in conjunction with the CRO, covering: - Single points of failure in the third-party ecosystem; - Cumulative exposure to a single third party across multiple Important Business Services; - Financial exposure to a single third party; - Regulatory exposure arising from a single third party's regulatory standing.

8.3 For each identified concentration risk, the Group shall document: - The nature and magnitude of the risk; - Existing mitigants (e.g. secondary integrations, contractual protections); - Residual risk assessment; - Remediation plan where the residual risk is above appetite.

8.4 The following specific concentration risk mitigants are required: - A minimum of two active mobile wallet integrations per corridor (Pakistan: Easypaisa + JazzCash; Bangladesh: bKash + Nagad); - A documented fallback for Eastnets sanctions screening, including the ability to revert to manual screening for critical payment flows within 1 hour; - A cloud portability assessment conducted annually, assessing the feasibility and cost of migrating critical workloads from AWS to an alternative provider within 12 months.

9. Ongoing Monitoring and Performance Management¶

9.1 Performance Monitoring¶

9.1.1 All material third parties shall be subject to ongoing performance monitoring against agreed SLAs. Monitoring shall include:

Monthly SLA performance review by the relevant function owner (e.g. SRE team for cloud providers, Payments Operations for network operators);
Automated monitoring where technically feasible (e.g. Cloudflare and AWS performance metrics integrated into SRE dashboards);
Escalation to the COO where SLA performance falls below agreed thresholds for two consecutive months;
Formal performance review meeting with Critical third parties at minimum quarterly.

9.1.2 Third-party performance reports shall be consolidated into a monthly Third-Party Performance Dashboard reviewed by the COO and CDO.

9.2 Ongoing Due Diligence Refresh¶

9.2.1 Material third parties shall be subject to an annual due diligence refresh, including reassessment of financial health, regulatory status, security certifications, and any material changes to the third party's business or ownership.

9.2.2 Triggered reviews shall be initiated immediately upon: - A material security incident at the third party; - A regulatory action, investigation, or enforcement against the third party; - A change of ownership or control of the third party; - Material deterioration in the third party's financial position; - A material breach of contract; - A geopolitical or macroeconomic event materially affecting the third party's operations.

9.3 Third-Party Register¶

9.3.1 The COO shall maintain a Third-Party Register covering all material outsourcing arrangements. The Register shall include:

Field	Detail
Third-Party ID	Unique reference
Third-Party Name	Legal entity name
Service Description	Services provided to Simpaisa
IBS Dependency	Important Business Services supported
Materiality Classification	Critical / Material - High / Material / Non-Material
Contract Reference	Contract number and expiry date
Governing Entity	Simpaisa entity contracting with the third party
Due Diligence Date	Date of last full due diligence
Performance Rating	Current rating (RAG)
Sub-Outsourcing	Identified sub-contractors
Exit Plan Status	Documented / In progress / Not yet required
Regulatory Notification	Notified / Not required / Pending
Next Review Date	Date of next scheduled review

9.3.2 The Third-Party Register shall be reviewed by the COO monthly and presented to the Risk Committee quarterly.

10. DFSA Outsourcing Notification Requirements¶

10.1 The DFSA requires that Simpaisa's DIFC entity notifies the DFSA before entering into any material outsourcing arrangement that involves a regulated function or an Important Business Service. The following procedure shall apply:

10.2 Prior to entering into a new material outsourcing arrangement involving a DIFC-regulated function: - The CCO shall assess whether DFSA notification is required; - Where required, a notification shall be submitted to the DFSA at least 30 days before the arrangement commences (or as otherwise stipulated in DFSA Rules); - The notification shall include: a description of the outsourced function; the identity of the third party; an assessment of the risks and mitigants; and confirmation of compliance with DFSA outsourcing requirements; - The DFSA's response (or acknowledgement of no objection) shall be obtained before the arrangement commences.

10.3 Material changes to an existing notified outsourcing arrangement (including changes in sub-contractors for material functions, changes in the scope of services, and changes in data residency) shall be notified to the DFSA in accordance with DFSA notification requirements.

10.4 The CCO shall maintain a DFSA Outsourcing Notification Register documenting all notifications made, the DFSA's response, and the status of each arrangement.

11. Exit Planning¶

11.1 For each Critical and Material - High third-party arrangement, the COO shall maintain a documented Exit Plan. Exit plans shall be reviewed annually and tested (at tabletop level) as part of the Operational Resilience scenario testing programme.

11.2 Exit plans shall cover:

Element	Requirement
Exit Triggers	Circumstances under which exit would be initiated (regulatory direction, contract breach, financial failure of third party, strategic decision)
Alternative Providers	Identified alternative providers or in-house alternatives, with assessment of switching feasibility and cost
Data Migration	Plan for retrieving, migrating, and validating all data held by the third party
Transition Timelines	Estimated timescales for transition under planned and emergency exit scenarios
Customer and Regulatory Communication	Communication plan for merchants, customers, and regulators during exit
Contractual Protections	Specific contract clauses relied upon during exit (exit assistance, data return, continuity of service)
Dependencies	Identification of other third parties or internal systems affected by the exit

11.3 Exit plans for the following third parties are considered highest priority and shall be reviewed first in the annual cycle: AWS, Eastnets, 1LINK, Binance.

12. Roles and Responsibilities¶

Role	Responsibilities
Board of Directors	Approves this Policy. Approves entry into Critical material outsourcing arrangements. Receives quarterly Third-Party Risk report.
Chief Operating Officer (COO)	Policy Owner. Maintains Third-Party Register. Oversees due diligence and ongoing monitoring programme. Approves material outsourcing arrangements (below Board threshold).
Chief Digital Officer (CDO)	Accountable for cloud provider governance (AWS, Cloudflare). Defines minimum information security standards for third parties. Reviews security due diligence findings.
Chief Risk Officer (CRO)	Integrates third-party risk into the Group's risk framework. Reviews Concentration Risk Assessment. Escalates emerging third-party risks to Board.
Chief Compliance Officer (CCO)	Manages DFSA and other regulatory notification obligations. Conducts compliance and reputational due diligence. Maintains DFSA Outsourcing Notification Register.
Functional Owners	Responsible for day-to-day management and performance monitoring of third parties within their function. Initiate triggered reviews.
Procurement / Commercial	Supports contract negotiation and ensures mandatory contract terms are included. Maintains contract repository.
Internal Audit	Independent assurance over third-party management framework, including due diligence quality, contract compliance, and exit plan adequacy.

13. Monitoring and Reporting¶

Report	Frequency	Audience	Content
Third-Party Performance Dashboard	Monthly	COO, CDO	SLA performance, incidents, triggered reviews
Third-Party Risk Report	Quarterly	Risk Committee, Board	Material third-party risk events, concentration risk update, due diligence refresh status, exit plan status
DFSA Outsourcing Notification Register	As required	CCO, Board	Notifications made, DFSA responses
Annual Third-Party Register Review	Annually	Board	Full register review, materiality assessments, concentration risk assessment, exit plan testing outcomes

14. Exceptions and Escalation¶

14.1 Exceptions to this Policy - including entering into a material outsourcing arrangement without completed due diligence, or an arrangement that cannot meet mandatory contractual requirements - require written approval as follows:

Material - High arrangements: COO plus CRO approval, with time-bound remediation plan;
Critical arrangements: Board approval.

14.2 All exceptions shall be logged in the Exceptions Register and reported to the Risk Committee at the next quarterly meeting.

SGP-OPS-001: Operational Resilience Policy
SGP-CDO-001: Data Governance Policy
Information Security Policy
Procurement Policy
Contract Management Policy
Incident Management Policy

Appendices¶

Appendix A: Third-Party Register Template¶

(Full Register maintained in the Group's GRC system. Fields as defined in Section 9.3.1.)

Appendix B: Materiality Assessment Questionnaire¶

Instructions: Complete for all new third-party engagements. Answer each criterion. If any criterion is answered "Yes", the arrangement is classified as Material.

#	Criterion	Yes / No	Evidence
1	Does the third party support an Important Business Service?
2	Is the function a regulated activity of any Simpaisa entity?
3	Would failure cause direct customer harm?
4	Is the function required by law or regulation?
5	Does the third party process sensitive customer or cardholder data?
6	Is the annual contract value above USD 250,000?
7	Can the third party be substituted within 30 days without material disruption?

Classification: If any answer is "Yes" → Material. Assess further for Critical classification.

Appendix C: Due Diligence Checklist¶

Financial Due Diligence - [ ] Audited financial statements reviewed (last 2 years) - [ ] Credit rating or equivalent indicator obtained - [ ] Ownership and beneficial ownership verified - [ ] No adverse financial news identified

Operational Due Diligence - [ ] BCP/DR documentation reviewed - [ ] Uptime / incident history obtained - [ ] Sub-contractor map obtained - [ ] Capacity assessment completed

Security Due Diligence - [ ] ISO 27001 / SOC 2 certificate obtained - [ ] PCI DSS AoC obtained (where applicable) - [ ] Penetration testing frequency confirmed - [ ] Security questionnaire completed and reviewed - [ ] Data encryption standards confirmed - [ ] Incident notification process confirmed

Compliance Due Diligence - [ ] Regulatory licences verified - [ ] No enforcement history identified - [ ] AML/CFT programme assessed (where applicable) - [ ] PEP / adverse media screening completed on UBOs

Reputational Due Diligence - [ ] Media review completed - [ ] No adverse reputational issues identified - [ ] Binance-specific: regulatory status in all relevant jurisdictions confirmed

Appendix D: Mandatory Contract Clauses Summary¶

For use by Procurement and Legal in contract negotiation. All clauses must be present in material outsourcing contracts.

SLA definitions and service credits
Audit rights (Simpaisa, auditors, regulators)
Data protection and processing obligations
Information security minimum standards
Incident notification (within 24 hours)
Business continuity and DR obligations
Sub-outsourcing controls and consent requirements
Regulatory compliance obligations
Data residency requirements (jurisdiction-specific)
Exit and transition assistance obligations
Data return and destruction on termination
Governing law and dispute resolution

Appendix E: Exit Plan Template¶

Section	Content
Third-Party Name
Service
Exit Triggers
Alternative Providers Identified
Estimated Switching Cost
Estimated Switching Timescale (Planned)
Estimated Switching Timescale (Emergency)
Data Migration Plan
Customer/Merchant Communication Plan
Regulatory Communication Plan
Contractual Exit Provisions
Last Reviewed
Tabletop Test Date

POLICY 3: DATA GOVERNANCE POLICY¶

SIMPAISA GROUP

DATA GOVERNANCE POLICY

Field	Detail
Document Reference	SGP-CDO-001
Version	1.0
Status	Active
Owner	Chief Digital Officer (CDO)
Approver	Board of Directors
Effective Date	1 April 2026
Next Review Date	1 April 2027
Classification	Internal

Document Control¶

Revision History¶

Version	Date	Author	Changes
0.1	January 2026	CDO Office	Initial draft
0.2	February 2026	CDO Office, Legal, Compliance, Privacy Counsel	Internal review
0.3	March 2026	CDO	Regulatory framework mapping completed
1.0	April 2026	CDO	Board-approved final version

1. Purpose and Scope¶

1.1 Purpose¶

This Data Governance Policy ("Policy") establishes the framework by which Simpaisa Group ("Simpaisa" or "the Group") manages its data assets throughout their lifecycle - from creation and collection through use, sharing, archival, and deletion. It defines data ownership accountabilities, classification standards, quality expectations, and the controls necessary to ensure that data is handled lawfully, securely, and in a manner that supports the Group's business objectives and regulatory obligations.

As a cross-border payments operator processing transactions across nine jurisdictions, the Group handles substantial volumes of personal data, financial data, and cardholder data. The legal and regulatory landscape governing this data is complex: the Group is subject to data protection regimes in Singapore, Pakistan, Bangladesh, Nepal, the UAE/DIFC, the United Kingdom, and Canada, each with distinct requirements for consent, data residency, breach notification, and data subject rights.

This Policy provides a single integrated framework that addresses all applicable regimes, with jurisdiction-specific requirements called out where they diverge from the common framework.

This Policy satisfies requirements under:

DIFC Data Protection Law 2020 (DIFC DPL) - applicable to Simpaisa's DIFC entity;
UK General Data Protection Regulation (UK GDPR) and Data Protection Act 2018 - applicable to the UK entity;
Singapore Personal Data Protection Act 2012 (PDPA) - applicable to the Singapore HoldCo;
Pakistan Personal Data Protection Act 2023 (PDPA Pakistan) and Prevention of Electronic Crimes Act 2016 (PECA);
Bangladesh ICT Act 2006 and Bangladesh Bank data protection guidelines;
Nepal Privacy Act 2018 and NRB guidelines;
Canada Personal Information Protection and Electronic Documents Act (PIPEDA) and applicable provincial privacy laws;
PCI DSS v4.0 - applicable to all entities processing cardholder data;
ISO 27001:2022 (Information Asset Management);
DFSA Data Protection requirements applicable to DIFC-regulated entities.

1.2 Scope¶

This Policy applies to:

All Simpaisa Group entities and all employees, contractors, and third parties acting on behalf of any Simpaisa entity;
All data in the Group's possession or control, regardless of format (digital, paper, or otherwise) or location;
All data processing activities, whether performed by Simpaisa directly or by third-party processors on Simpaisa's behalf;
All technology systems, cloud infrastructure, and analytics platforms used to collect, store, process, or transmit Group data.

2. Definitions¶

Term	Definition
Data Asset	Any data held by the Group that has business, operational, regulatory, or commercial value.
Data Classification	The process of categorising data assets according to their sensitivity and the controls required to protect them.
Data Controller	The entity that determines the purposes and means of processing personal data. Simpaisa is the data controller for customer personal data in the jurisdictions in which it operates.
Data Custodian	The individual or team responsible for the technical implementation of data controls, including storage, backup, access management, and encryption. Typically within the Technology or SRE team.
Data Lifecycle	The stages through which a data asset passes: creation/collection → storage → use → sharing → archival → deletion.
Data Owner	The senior individual (typically at Director or Head level) accountable for a defined data domain, including classification decisions, access approvals, and quality standards.
Data Processor	A third party that processes personal data on behalf of Simpaisa as data controller.
Data Residency	The requirement that data is stored and/or processed within the borders of a specific country or jurisdiction.
Data Steward	The individual within a business function who manages data quality, maintains metadata, and ensures compliance with data governance standards for a specific data set or domain.
Data Subject	An identified or identifiable natural person about whom Simpaisa holds personal data.
DPA	Data Processing Agreement - a contractual instrument governing the relationship between Simpaisa as data controller and a data processor.
DIFC DPL	DIFC Data Protection Law 2020, administered by the DIFC Commissioner of Data Protection.
PCI DSS	Payment Card Industry Data Security Standard - a global security standard for organisations handling cardholder data.
Personal Data	Any information relating to an identified or identifiable natural person.
Restricted Data	The highest classification tier - data that, if disclosed, would cause severe harm to individuals, regulatory breach, or significant financial loss. Includes cardholder data and certain categories of personal data.
UK GDPR	The United Kingdom General Data Protection Regulation, as retained in UK law following the UK's departure from the EU.

3. Data Classification Scheme¶

3.1 Classification Tiers¶

3.1.1 All Group data shall be classified into one of four tiers. Classification determines the minimum controls required for storage, access, transmission, and disposal.

Tier 1: Public

Definition: Information that is approved for unrestricted public access and whose disclosure carries no risk to the Group, its customers, or third parties.

Examples: Marketing materials, published product information, publicly filed regulatory documents, press releases.

Controls: No access restriction required. May be transmitted unencrypted. Standard records management applies.

Tier 2: Internal

Definition: Information intended for internal business use and not authorised for external distribution, but whose inadvertent disclosure would not cause significant harm.

Examples: Internal policies and procedures, organisational charts, internal project documentation, meeting minutes, general operational reporting.

Controls: Access limited to employees and authorised contractors. Transmitted over secure channels (TLS 1.2 minimum). Not to be shared externally without function-head approval.

Tier 3: Confidential

Definition: Sensitive business, financial, or personal information whose unauthorised disclosure could harm the Group's competitive position, relationships, or regulatory standing, or could harm the individuals to whom the data relates.

Examples: Customer personal data (name, address, account details), merchant commercial terms, transaction data, employee personal data, non-public financial information, vendor contracts.

Controls: Access on a strict need-to-know basis, with access controlled through role-based access controls (RBAC). Encryption at rest and in transit required. External sharing requires Data Owner approval and a DPA or NDA as appropriate. Stored in systems with audit logging enabled.

Tier 4: Restricted

Definition: The most sensitive category. Data whose unauthorised disclosure would cause severe harm to individuals, result in regulatory breach, or cause significant financial or reputational damage to the Group. Includes all data categories that attract special regulatory protection.

Examples: Payment card data (PANs, CVVs, expiry dates - PCI DSS in scope), biometric data, government-issued identity document data, sensitive AML/CFT investigation records, cryptographic keys and secrets, passwords and credentials, data subject to specific regulatory restriction (e.g. SBP-classified data), personal data revealing racial or ethnic origin, health data.

Controls: Access limited to named individuals with explicit Data Owner authorisation. Encryption at rest (AES-256 minimum) and in transit (TLS 1.3 preferred). PAN data subject to tokenisation or masking in all non-production environments. No retention beyond the defined retention period. Disposal by certified secure deletion or physical destruction. All access logged and monitored. Annual access review mandatory.

3.2 Classification Responsibilities¶

3.2.1 Data Owners are responsible for classifying data within their domain. Where classification is unclear, the CDO shall make the final determination.

3.2.2 Default classification is Confidential. Any data that has not been explicitly classified shall be treated as Confidential until a formal classification decision is made.

3.2.3 Classification shall be reviewed upon any material change in the nature, use, or regulatory context of a data asset.

4. Data Ownership Model¶

4.1 Roles¶

4.1.1 Data Owners

Data Owners are senior individuals (Director level or above) accountable for defined data domains. They make decisions about data access, classification, and acceptable use. Data Owners for the Group's principal data domains are:

Data Domain	Data Owner
Customer Personal Data	Chief Compliance Officer (CCO)
Payment and Transaction Data	Chief Operating Officer (COO)
Merchant and Partner Data	COO
Product and Technology Data	Chief Digital Officer (CDO)
Employee Data	Chief People Officer / HR Director
Financial and Accounting Data	Chief Financial Officer (CFO)
Compliance and AML Data	CCO / MLRO
Analytics and AI/ML Data	Chief Digital Officer (CDO)
Cardholder Data (PCI DSS)	CDO (with co-ownership from COO and CCO)

4.1.2 Data Stewards

Data Stewards are operational owners within business functions, responsible for day-to-day data quality management, metadata maintenance, and compliance with classification and lifecycle controls. Each Data Owner shall appoint at least one Data Steward for each significant data set within their domain.

4.1.3 Data Custodians

Data Custodians are the technical teams (SRE, Engineering, IT) responsible for implementing the physical and technical controls for data storage, access management, backup, encryption, and deletion. Data Custodians act on the instructions of Data Owners and Stewards.

4.1.4 Chief Digital Officer

The CDO is the Group-level accountable officer for data governance. The CDO chairs the Data Governance Council, approves classification disputes, and reports to the Board on the data governance programme annually.

4.1.5 Data Governance Council

The Data Governance Council ("DGC") comprises the CDO (Chair), CCO, COO, Head of Engineering, and a representative Data Steward from each principal domain. The DGC meets monthly to review data quality metrics, policy compliance, incidents, and classification decisions.

5. Data Quality Standards and Controls¶

5.1 All data used for operational decision-making, regulatory reporting, financial settlement, or customer service shall meet the following quality standards:

Dimension	Standard
Accuracy	Data shall accurately represent the real-world entity or event it describes. Material inaccuracies shall be corrected within defined SLAs.
Completeness	Mandatory data fields for each data set shall be populated. Completeness thresholds shall be defined by Data Stewards and monitored.
Timeliness	Data shall be available within the time frame required for its intended use. Settlement data must be available for same-day reconciliation.
Consistency	Data representing the same entity or event shall be consistent across systems. Discrepancies shall be flagged and resolved through defined reconciliation processes.
Integrity	Data shall not be altered without authorisation. Audit trails shall record all material changes to data.
Lineage	For data used in regulatory reporting, analytics, and AI/ML, the origin, transformation, and flow of data shall be documented and traceable.

5.2 Data quality monitoring shall be automated wherever possible. Data quality dashboards shall be maintained by Data Stewards and reviewed by Data Owners monthly.

5.3 Data quality issues that affect regulatory reporting, customer transactions, or risk management shall be escalated to the Data Owner and CDO immediately, with root cause analysis completed within 5 business days.

6. Data Lifecycle Management¶

6.1 Creation and Collection¶

6.1.1 Personal data shall be collected only for specified, explicit, and legitimate purposes, and only to the extent necessary for those purposes (data minimisation).

6.1.2 Where personal data is collected directly from data subjects (customer onboarding, KYC, account registration), appropriate consent or another lawful basis shall be established before collection, and data subjects shall be provided with a clear privacy notice.

6.1.3 Where personal data is collected from third parties (credit bureaux, identity verification providers, correspondent banks), the lawful basis for collection and use shall be documented before the data is ingested.

6.1.4 All data collection mechanisms (web forms, APIs, mobile application, agent networks) shall be assessed for data minimisation compliance before deployment.

6.2 Storage¶

6.2.1 All Restricted and Confidential data shall be stored with encryption at rest using AES-256 or equivalent. Encryption keys shall be managed using a dedicated key management service (AWS KMS or equivalent) with strict access controls and annual key rotation.

6.2.2 Data shall be stored in the jurisdiction or region required by applicable data residency requirements (see Section 8). Data Custodians shall implement and maintain infrastructure controls to enforce storage location restrictions.

6.2.3 Backups of all production data classified as Confidential or Restricted shall be encrypted, stored in geographically separate locations (subject to data residency constraints), and tested for recoverability at minimum quarterly.

6.2.4 PCI DSS cardholder data shall be stored in the cardholder data environment (CDE), which is maintained in strict compliance with PCI DSS v4.0 requirements, including network segmentation, access controls, logging, and annual QSA assessment.

6.3 Use¶

6.3.1 Data shall be used only for the purposes for which it was collected and for which a lawful basis exists. Any new use of existing data that falls outside the original purpose shall require a new purpose assessment and, where applicable, fresh consent or regulatory authorisation.

6.3.2 Access to data shall be granted on a least-privilege basis. Role-based access controls shall be implemented and reviewed quarterly. Privileged access to Restricted data requires individual named authorisation from the Data Owner.

6.3.3 Personal data used for analytics, model training, or product development shall be pseudonymised or anonymised where possible. The use of production customer data in development, testing, or analytics environments is prohibited unless the CDO has approved an anonymisation process that eliminates re-identification risk.

6.4.1 Data shall not be shared with third parties (including processors, partners, and regulators) without a documented lawful basis and, for personal data, an executed DPA or equivalent legal instrument.

6.4.2 Before sharing data with a third party for the first time, the Data Owner shall complete a data sharing assessment documenting: the data to be shared, the third party's identity, the lawful basis, the security controls in place at the third party, and the contractual protections in place.

6.4.3 Cross-border transfers of personal data are subject to the requirements of Section 7 of this Policy.

6.4.4 Regulatory requests for data (court orders, regulatory production requests) shall be directed to the CCO and Legal. Data shall not be disclosed to regulators or law enforcement without CCO approval except where immediate legal obligation requires it (in which case, CDO and CCO shall be notified immediately).

6.5 Archival¶

6.5.1 Data that is no longer required for active operational purposes but must be retained for regulatory, legal, or audit purposes shall be archived in a secure, access-controlled archive environment. Archive access shall require Data Owner authorisation.

6.5.2 Archived data shall remain subject to the same classification, encryption, and access controls as active data.

6.5.3 Archive retention periods are defined in the Record Retention Schedule (Appendix D).

6.6 Deletion¶

6.6.1 Data shall be deleted at the end of its defined retention period, or upon a valid data subject deletion request, in accordance with applicable law.

6.6.2 Deletion of Restricted and Confidential data shall be performed using secure deletion methods that prevent recovery (cryptographic erasure or certified overwrite). Physical media containing Restricted data shall be destroyed by a certified data destruction provider.

6.6.3 PCI DSS cardholder data (PANs, CVVs) shall not be retained beyond the period required for transaction authorisation and settlement, except where a documented business or regulatory requirement exists. Any such extended retention requires CDO and CCO approval.

6.6.4 Deletion events for Restricted data shall be logged and the log retained for audit purposes.

7. Cross-Border Data Transfer Framework¶

7.1 General Principles¶

7.1.1 The Group shall not transfer personal data across national borders without a documented lawful basis for that transfer under the applicable law of the originating jurisdiction. The following sections set out the specific requirements for each jurisdiction in which the Group operates.

7.1.2 A Data Transfer Impact Assessment (DTIA) shall be completed before any new cross-border personal data transfer is established. DTIAs shall assess: the legal basis for transfer, the data protection standards in the destination country, and the contractual and technical safeguards in place.

7.1.3 The CDO shall maintain a Cross-Border Transfer Register documenting all active cross-border personal data flows, the legal basis relied upon, and the safeguards in place.

7.2 Pakistan¶

Applicable Law: Personal Data Protection Act 2023 (PDPA Pakistan); Prevention of Electronic Crimes Act 2016 (PECA); State Bank of Pakistan data localisation directives.

Key Requirements:

The SBP requires that payment data relating to Pakistani customers and transactions, including transaction records and customer financial data, be stored on servers located within Pakistan;
The PDPA Pakistan restricts the cross-border transfer of personal data to jurisdictions that provide an adequate level of data protection or where specified transfer mechanisms are in place;
PECA provisions may restrict the transfer of certain electronic data outside Pakistan;
Customer personal data and transaction records for the Pakistan corridor shall be stored on in-country infrastructure (AWS Outpost, local co-location, or equivalent) before any derived analytics data is processed internationally;
Cross-border transfers of Pakistan customer data to the Singapore HoldCo for group reporting or analytics shall be limited to anonymised or pseudonymised data wherever possible.

Controls Required: - In-country primary data store for Pakistan customer and transaction data; - SBP-compliant data architecture documented and reviewed annually; - Transfer mechanism (contractual clauses or adequacy determination) in place for any residual cross-border flows; - Country Manager (Pakistan) to certify annual compliance with SBP data residency requirements.

7.3 Bangladesh¶

Applicable Law: Information and Communication Technology Act 2006 (ICT Act); Bangladesh Bank guidelines on data protection and localisation; Digitisation and data localisation directives.

Key Requirements:

Bangladesh Bank requires that financial transaction data relating to Bangladesh customers be stored within Bangladesh;
Cross-border transfer of personal data is subject to restriction; transfers for legitimate business purposes (e.g. group risk management) may be permitted with appropriate safeguards;
Customer KYC and transaction data for the Bangladesh corridor shall be stored in-country;
The Group's Bangladesh entity shall appoint a local data protection contact.

Controls Required: - In-country primary data store for Bangladesh customer and transaction data; - Bangladesh Bank-compliant data architecture documented; - DPA or equivalent contractual instrument for any cross-border data flows to HoldCo or processors outside Bangladesh.

7.4 Nepal¶

Applicable Law: Privacy Act 2018 (Nepal); Nepal Rastra Bank (NRB) guidelines.

Key Requirements:

Nepal's Privacy Act establishes rights of data subjects and imposes obligations on data controllers regarding collection, storage, and transfer of personal data;
NRB guidelines require that financial data relating to Nepalese customers be processed and stored in Nepal;
Cross-border transfer of personal data is subject to consent requirements and, in certain cases, approval from the relevant authority.

Controls Required: - In-country data storage for Nepal customer and transaction data; - Consent management for any cross-border personal data flows; - NRB compliance confirmed annually by local legal counsel.

7.5 Iraq¶

Applicable Law: Central Bank of Iraq (CBI) directives; no comprehensive data protection legislation currently in force; sector-specific requirements apply.

Key Requirements:

The CBI may impose data localisation and storage requirements on payment data relating to Iraq operations;
In the absence of comprehensive data protection legislation, the Group shall apply its internal Confidential data standards as a minimum baseline for all Iraq customer data;
Cross-border transfers of Iraq customer data shall be documented and assessed against any applicable CBI requirements.

Controls Required: - In-country data storage for CBI-regulated transaction data where required; - Annual review by local legal counsel of applicable requirements; - CDO to maintain documentation of controls in place pending legislative development in Iraq.

7.6 Singapore¶

Applicable Law: Personal Data Protection Act 2012 (PDPA), as amended; MAS guidelines.

Key Requirements:

The PDPA requires consent (or an applicable exception) for the collection, use, and disclosure of personal data;
Cross-border transfers of personal data from Singapore are permitted where the receiving country provides a comparable standard of protection, or where the transferring organisation ensures comparable protection through contractual or other means;
Singapore is the HoldCo jurisdiction; data flows from subsidiary entities to Singapore for group reporting, risk management, and oversight purposes shall be governed by intragroup DPAs;
The Group must comply with the mandatory data breach notification obligation: breaches meeting the threshold (likely to result in significant harm or affecting ≥500 individuals) must be notified to the PDPC and affected individuals within 3 days of assessment.

Controls Required: - Intragroup DPAs in place for all personal data flows to Singapore HoldCo; - Privacy notices for Singapore-based customers and employees up to date; - Mandatory breach notification process documented and tested.

7.7 UAE / DIFC¶

Applicable Law: DIFC Data Protection Law 2020 (DPL 2020), administered by the DIFC Commissioner of Data Protection; UAE Federal Decree-Law No. 45 of 2021 on Personal Data Protection (outside DIFC).

Key Requirements:

The DIFC DPL 2020 is the primary data protection framework for Simpaisa's DIFC entity. It is broadly aligned with GDPR principles, requiring: lawful basis for processing; data subject rights (access, rectification, erasure, portability, objection); data protection by design and by default; data protection impact assessments (DPIAs) for high-risk processing; and mandatory breach notification within 72 hours to the DIFC Commissioner;
Cross-border transfers from the DIFC are permitted to jurisdictions on the DIFC Commissioner's adequacy list or where appropriate safeguards (standard contractual clauses approved by the DIFC Commissioner) are in place;
A Data Protection Officer (DPO) is required for the DIFC entity where processing is large-scale or involves sensitive personal data. Given the Group's payment data volumes, the Group shall appoint a DPO or a designated privacy lead responsible for DIFC DPL compliance;
Data Protection Impact Assessments (DPIAs) shall be conducted for all new payment processing flows, customer profiling activities, or analytics initiatives involving DIFC customer data.

Controls Required: - DPO (or designated privacy lead) appointed for DIFC entity; - DIFC-approved SCCs in place for cross-border transfers where required; - DPIA process implemented and maintained; - 72-hour breach notification process documented; - Data subject rights request handling process operational.

7.8 United Kingdom¶

Applicable Law: UK General Data Protection Regulation (UK GDPR); Data Protection Act 2018; ICO guidance.

Key Requirements:

UK GDPR requires: lawful basis for all processing; comprehensive data subject rights; Data Protection by Design; DPIAs for high-risk processing; appointment of a Data Protection Officer (mandatory where processing is large-scale special category data or systematic monitoring); and mandatory breach notification to the ICO within 72 hours of becoming aware;
Cross-border transfers from the UK require: an adequacy regulation, standard contractual clauses (UK International Data Transfer Agreement - IDTA), or an alternative transfer mechanism;
The UK entity shall maintain an Article 30-equivalent Record of Processing Activities (RoPA);
Where the UK entity processes personal data on behalf of a group entity, a DPA shall be in place.

Controls Required: - UK RoPA maintained and reviewed at least annually; - ICO registration maintained; - DPO appointed or documented assessment that appointment is not required (with justification); - UK IDTA or equivalent in place for transfers to non-adequate jurisdictions; - 72-hour ICO breach notification process documented.

7.9 Canada¶

Applicable Law: Personal Information Protection and Electronic Documents Act (PIPEDA); applicable provincial privacy laws (PIPA Alberta, PIPA British Columbia, Act respecting the protection of personal information in the private sector - Québec Law 25).

Key Requirements:

PIPEDA requires: consent for collection, use, and disclosure of personal data; identified purposes for collection; accuracy; safeguards; individual access rights; and challenging compliance;
Québec Law 25 (effective September 2023) introduced enhanced obligations including: mandatory privacy impact assessments for cross-border transfers; 72-hour breach notification to the Commission d'accès à l'information (CAI) and affected individuals; data minimisation; and transparency requirements;
Cross-border transfers from Canada require a privacy impact assessment and contractual safeguards ensuring equivalent protection;
The Group shall maintain a Canadian privacy notice meeting PIPEDA and provincial requirements.

Controls Required: - Privacy impact assessments completed for Canadian data flows to non-Canadian jurisdictions; - Contractual safeguards in place for cross-border transfers; - Breach notification process operational for CAI (Québec) and OPC (federal) requirements; - Canadian privacy notice maintained and current.

8. Data Residency Requirements¶

8.1 In-Country Data Storage¶

8.1.1 The following data residency requirements apply to the Group's operations. Compliance shall be maintained through the Group's cloud and infrastructure architecture:

Jurisdiction	Data Subject to Residency Requirement	Infrastructure Solution	Verification
Pakistan	Customer PII, transaction records, KYC data	AWS (nearest region) + local co-location / Cloudflare regional processing	Annual SBP compliance review
Bangladesh	Customer PII, transaction records, KYC data	AWS (nearest region) + local infrastructure	Annual BB compliance review
Nepal	Customer PII, NRB-regulated financial data	Local co-location with cloud gateway	Annual NRB / legal review
Iraq	CBI-regulated transaction data	Local hosting where required by CBI	Annual CBI / legal review
DIFC	DIFC customer data within DIFC / UAE	AWS me-central-1 (UAE)	Annual DIFC DPO review
Singapore	Singapore customer data	AWS ap-southeast-1 (Singapore)	PDPC compliance review
UK	UK customer data	AWS eu-west-2 (London)	ICO compliance review
Canada	Canadian customer data	AWS ca-central-1 (Canada)	OPC / CAI compliance review

8.1.2 The CDO shall maintain and annually certify a Data Residency Compliance Map documenting the infrastructure configuration and controls in place for each jurisdiction. The Map shall be reviewed by the CCO and presented to the Board as part of the annual Data Governance Report.

8.1.3 Cloudflare shall be configured using the Data Localisation Suite or equivalent controls to ensure that edge processing of data subject to residency requirements occurs within the relevant national or regional boundary. The SRE team shall verify Cloudflare residency configuration quarterly.

9. PCI DSS Cardholder Data Handling¶

9.1 Cardholder data - including Primary Account Numbers (PANs), cardholder names, expiry dates, and service codes - is classified as Restricted (Tier 4) under this Policy and is subject to the full requirements of PCI DSS v4.0.

9.2 The Group's cardholder data environment (CDE) shall be maintained in strict network isolation from non-CDE systems. Network segmentation controls shall be reviewed annually by the QSA as part of the PCI DSS assessment.

9.3 PANs shall be masked in all non-production environments, including development, testing, and analytics. Unmasked PAN data shall not appear in logs, error messages, or reports.

9.4 Card Verification Values (CVVs / CVCs) shall not be stored after authorisation under any circumstances.

9.5 Tokenisation shall be used wherever technically feasible to replace PANs with non-sensitive tokens in application databases, logs, and analytics systems. The CDO shall approve any instance where tokenisation is not technically feasible and shall document compensating controls.

9.6 The Group shall maintain a current PCI DSS Level 1 Merchant / Service Provider assessment conducted by a Qualified Security Assessor (QSA). The annual QSA assessment report (Report on Compliance) and Attestation of Compliance (AoC) shall be reviewed by the CDO and CCO and presented to the Board.

9.7 All employees who access the CDE or handle cardholder data shall complete PCI DSS awareness training annually.

10.1.1 Where processing of personal data relies on consent as its lawful basis, consent shall be: - Freely given, specific, informed, and unambiguous; - Obtained before processing commences; - Recorded with a timestamp and the version of the privacy notice presented at the time of consent; - Capable of being withdrawn at any time, with withdrawal as easy as giving consent.

10.1.2 The Group shall maintain a Consent Management Platform (CMP) capable of recording consent events, consent versions, and withdrawal events for all customer data subjects. The CMP shall be auditable and shall produce evidence of consent on demand.

10.1.3 Marketing communications to customers shall be governed by consent (opt-in) in all jurisdictions, irrespective of whether applicable law permits a different basis. This represents the Group's highest-common-denominator approach to consent.

10.2 Data Subject Rights¶

10.2.1 The Group shall respect and operationalise the following data subject rights in all jurisdictions where they are legally required, and as a matter of Group policy where they are not:

Right	Description	Standard Response Time
Right of Access	Data subjects may request confirmation of whether their personal data is processed and a copy of the data	30 days (extendable by 30 days with notice)
Right to Rectification	Data subjects may request correction of inaccurate personal data	30 days
Right to Erasure	Data subjects may request deletion of their personal data where no legitimate basis for retention exists	30 days (subject to legal retention obligations)
Right to Restrict Processing	Data subjects may request that processing is restricted pending resolution of a dispute	30 days
Right to Data Portability	Data subjects may request their personal data in a machine-readable format for transfer to another controller	30 days
Right to Object	Data subjects may object to processing based on legitimate interests or for direct marketing	Immediate for direct marketing; 30 days for other processing
Rights related to Automated Decision-Making	Data subjects may request human review of automated decisions that significantly affect them	30 days

10.2.2 Data subject rights requests shall be handled by the Privacy function (under the CCO), with operational support from Data Stewards and Data Custodians. All requests shall be logged in the Data Subject Rights Register.

10.2.3 Identity verification shall be conducted before fulfilling any data subject request, to prevent fraudulent or unauthorised disclosure.

11. Data Breach Notification Obligations¶

11.1 Breach Detection and Assessment¶

11.1.1 A personal data breach is any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored, or otherwise processed by the Group.

11.1.2 Upon becoming aware of a potential breach, the discovering employee shall immediately notify the Information Security team and the CDO. The CCO shall be notified within 1 hour.

11.1.3 The Information Security team shall conduct an initial triage within 2 hours to determine: the nature and extent of the breach; the personal data categories affected; the number of individuals affected; and the likely risk of harm to data subjects.

11.2 Regulatory Notification Timelines¶

11.2.1 Regulatory notification obligations by jurisdiction are as follows:

Jurisdiction	Regulator	Notification Trigger	Deadline
DIFC	DIFC Commissioner of Data Protection	All breaches likely to result in risk to individuals	72 hours from awareness
UK	ICO	Breaches posing risk to individuals	72 hours from awareness
Singapore	PDPC	Breaches affecting ≥500 individuals or likely to cause significant harm	3 calendar days from assessment
Canada (Federal)	OPC	Breaches posing real risk of significant harm	As soon as feasible
Canada (Québec)	Commission d'accès à l'information	Breaches affecting Québec residents	72 hours from awareness
Pakistan	PDPC Pakistan / SBP	As required under PDPA Pakistan and SBP directives	Per regulatory guidance; aim within 72 hours
Bangladesh	Bangladesh Bank	Per BB guidelines	Per regulatory guidance
Nepal	As per Privacy Act	Per Nepal Privacy Act	Per regulatory guidance

11.2.2 Notification to affected individuals shall be made without undue delay where the breach is likely to result in high risk to their rights and freedoms, and in any case within the timescale required by the applicable law.

11.2.3 The CCO shall maintain a Data Breach Register recording: breach reference, date of discovery, date of containment, affected data categories, number of individuals affected, regulatory notifications made, and remediation actions.

11.2.4 All breaches, including those below the regulatory notification threshold, shall be documented in the internal Data Breach Register for audit and trend-monitoring purposes.

12. Data Processing Agreements¶

12.1 Before allowing any third party to process personal data on behalf of Simpaisa, an executed Data Processing Agreement (DPA) shall be in place. DPAs are required with: cloud service providers (AWS, Cloudflare), compliance service providers (Eastnets), identity verification providers, analytics platform providers, and any other processor handling personal data.

12.2 DPAs shall include, at minimum: - The subject matter, duration, nature, and purpose of processing; - The type of personal data and categories of data subjects; - Obligations and rights of the data controller (Simpaisa); - Processor obligations including: processing only on documented instructions; confidentiality; technical and organisational security measures; sub-processor controls; assistance with data subject rights and breach notification; deletion or return of data at contract end; and audit cooperation.

12.3 Merchant and partner DPAs shall be maintained where merchants or partners process personal data in connection with Simpaisa services (e.g. white-label wallet operators who conduct customer onboarding). The CCO shall maintain a DPA Register tracking the status of all required agreements.

12.4 DPAs with cross-border transfer provisions shall include appropriate transfer mechanisms (SCCs, IDTA, or equivalent) for each jurisdiction involved.

13. Analytics and AI/ML Data Usage Governance¶

13.1 Data Minimisation in Analytics

13.1.1 Analytics and AI/ML systems shall access only the data necessary for the specific analytical purpose. Broad or speculative access to customer personal data for exploratory analytics is prohibited without Data Owner approval and a documented purpose assessment.

13.1.2 Personal data used in analytics shall be pseudonymised or anonymised at the point of extraction from production systems wherever technically feasible. The CDO shall define and maintain approved anonymisation and pseudonymisation techniques that satisfy the re-identification risk threshold applicable under DIFC DPL, UK GDPR, and Singapore PDPA.

13.2 AI/ML Model Governance

13.2.1 Any AI or machine learning model trained on Simpaisa customer data shall be subject to a Model Governance Review before deployment to production. The review shall assess: the data used for training; potential bias and fairness issues; explainability; regulatory compliance (including automated decision-making rights); and ongoing monitoring requirements.

13.2.2 AI/ML models used in credit risk assessment, fraud detection, customer segmentation, or sanctions screening shall be subject to enhanced governance, including documented model cards, annual validation by an independent reviewer, and bias testing across protected characteristics.

13.2.3 The use of customer personal data to train third-party AI/ML models (including models operated by cloud or SaaS providers) is prohibited without explicit Data Owner and CDO approval, a DPIA, and appropriate contractual safeguards.

13.3 Synthetic Data

13.3.1 The Group shall invest in synthetic data generation capabilities to enable model training, testing, and development without exposure of real customer data. Synthetic data used for model training shall be validated to ensure it does not encode real individual data.

14. Roles and Responsibilities¶

Role	Responsibilities
Board of Directors	Approves this Policy. Receives annual Data Governance Report. Accountable for overall data governance standards.
Chief Digital Officer (CDO)	Policy Owner. Chairs Data Governance Council. Accountable for data residency compliance, PCI DSS compliance, and analytics/AI governance. Reports to Board annually.
Chief Compliance Officer (CCO)	Accountable for personal data compliance across all jurisdictions. Manages data subject rights, breach notification, and DPA programme. Appoints DIFC DPO.
Chief Risk Officer (CRO)	Integrates data risk into Group risk framework. Oversees DPIA process for high-risk processing.
Data Owners	Accountable for data classification, access approval, and quality standards within their domain.
Data Stewards	Operational management of data quality, metadata, and lifecycle within their data set.
Data Custodians (SRE / Engineering)	Technical implementation of storage, access, encryption, backup, and deletion controls.
Internal Audit	Independent assurance over data governance framework, including classification, lifecycle management, breach response, and cross-border transfer compliance.
All Employees	Responsible for handling data in accordance with its classification. Mandatory completion of annual data protection training.

15. Monitoring and Reporting¶

Report	Frequency	Audience	Content
Data Quality Dashboard	Monthly	Data Governance Council	Quality metrics by domain; issues and resolutions
Data Subject Rights Log	Monthly	CCO, CDO	Requests received, fulfilled, pending; breach of response SLA
Data Breach Register	Monthly	CCO, CDO	All breaches; regulatory notifications; remediation status
Third-Party DPA Status	Quarterly	CCO	DPAs in place, pending, expired
Data Residency Compliance Map	Annually	CDO, Board	Confirmation of in-country infrastructure compliance
Annual Data Governance Report	Annually	Board	Overall programme status, breach summary, regulatory developments, PCI DSS QSA outcome, AI/ML governance update

16. Exceptions and Escalation¶

16.1 Exceptions to this Policy - including processing personal data without a DPA, storing data outside its required residency location, or retaining data beyond its defined retention period - require written approval from the CDO and, where personal data is involved, the CCO.

16.2 Exceptions with regulatory compliance implications shall be reported to the CRO and escalated to the Board if they pose material regulatory risk.

16.3 All exceptions shall be logged in the Exceptions Register and reviewed at the next Data Governance Council meeting.

SGP-OPS-001: Operational Resilience Policy
SGP-OPS-002: Outsourcing and Third-Party Management Policy
Information Security Policy
Acceptable Use Policy
Records Management Policy
AI and Machine Learning Governance Policy (to be developed)

Appendices¶

Appendix A: Data Classification Quick Reference Card¶

For distribution to all employees. Single-page summary of the four classification tiers and key handling rules.

Tier	Label	Examples	Can I email it?	Can I store on personal device?	Can I share externally?
1	PUBLIC	Marketing brochures	Yes	Yes	Yes
2	INTERNAL	Internal memos, org charts	Yes (internal only)	No	No - requires approval
3	CONFIDENTIAL	Customer data, merchant contracts	Encrypted only	No	DPA / NDA required
4	RESTRICTED	Card numbers, biometrics, credentials	Never by email	Never	Named authorisation required

Appendix B: Data Processing Agreement Template¶

Standard DPA template approved by Legal and CCO. Available in the Group's contract management system. Versions available for: (1) Simpaisa as Controller, processor engagement; (2) Simpaisa as Processor, controller engagement; (3) Intragroup agreement.

Appendix C: Data Protection Impact Assessment (DPIA) Template¶

Section	Content
Processing Description	Nature, scope, context, and purpose of processing
Necessity and Proportionality	Assessment of whether processing is necessary for the stated purpose
Data Subject Categories	Categories of individuals affected
Risks Identified	Likelihood and severity of risks to data subjects
Mitigation Measures	Controls to address identified risks
Residual Risk Assessment	Risk after mitigation
DPO Opinion	(where applicable)
Approval	CDO and CCO sign-off
Review Date

Appendix D: Record Retention Schedule¶

Data Type	Retention Period	Basis	Secure Deletion Required
Customer Transaction Records	7 years from transaction date (10 years for AML-flagged records)	Regulatory (AML/CFT, MAS, SBP)	Yes
Customer KYC / Identity Documents	5 years post-relationship end (10 years where SAR filed)	AML/CFT regulations	Yes
PCI DSS Cardholder Data (PAN)	Minimum required for authorisation only; no extended retention unless explicitly justified	PCI DSS v4.0	Yes
Employee Personal Data	Duration of employment + 7 years	Employment law, tax	Yes
Merchant Contract and Transaction Data	7 years post-contract end	Commercial law	Yes
Compliance Screening Records	7 years from screening date	AML/CFT	Yes
System and Application Logs	1 year (security logs: 2 years)	ISO 27001, PCI DSS	Yes
Marketing Consent Records	Duration of consent + 3 years	GDPR / PDPA	Yes
Data Breach Records	5 years from breach date	Regulatory	Yes
DPIA Records	5 years from assessment or end of processing	GDPR / DIFC DPL	Yes

Note: Where multiple jurisdictions impose different retention periods for the same data type, the longest applicable period governs, unless a shorter period is mandated by a specific jurisdiction and the data cannot be segregated by jurisdiction.

Appendix E: Data Subject Rights Request Log Template¶

Field	Content
Request Reference
Date Received
Data Subject Identity
Jurisdiction
Right(s) Exercised
Identity Verification Status
Assigned Handler
Response Due Date
Response Sent Date
Outcome	Fulfilled / Partially fulfilled / Refused (with reason)
Escalation Required	Yes / No

Appendix F: Cross-Border Transfer Register Template¶

Field	Content
Transfer Reference
Originating Jurisdiction
Destination Jurisdiction
Data Categories Transferred
Volume / Frequency
Data Subjects Affected
Legal Basis for Transfer
Transfer Mechanism	SCCs / IDTA / Adequacy / Other
DPA / DTIA Completed	Yes / No
Date Established
Last Reviewed

End of Simpaisa Group Policy Suite - SGP-OPS-001, SGP-OPS-002, SGP-CDO-001

All three documents are approved by the Board of Directors of Simpaisa Holdings Pte Ltd and are effective from 1 April 2026. Questions regarding interpretation or application of any policy should be directed to the respective Policy Owner.

These three documents are production-ready. Here is a summary of what has been delivered:

Policy 1 - Operational Resilience (SGP-OPS-001): Covers all six Important Business Services with quantified impact tolerances, the active-active AWS/Cloudflare architecture mandate, the SRE model without CAB, six mandatory scenario tests, frontier-market-specific controls (Pakistan, Bangladesh, Nepal, Iraq), full communication protocols for regulators and merchants, DFSA-specific requirements, and board reporting obligations. Six appendices including the Infrastructure Resilience Map template, Exception form, and Scenario Test Record.

Policy 2 - Outsourcing and Third-Party Management (SGP-OPS-002): Full three-way definition framework (outsourcing vs procurement vs partnership), seven-criterion materiality assessment, classification table for all named vendors (AWS, Cloudflare, Eastnets, Binance, 1LINK, Easypaisa, JazzCash, bKash, Nagad, Visa, Mastercard), five-domain due diligence requirements, full mandatory contract clause suite, AWS and Cloudflare governance sections, concentration risk management including specific mitigants by corridor, DFSA notification process, and exit plan templates for all Critical third parties.

Policy 3 - Data Governance (SGP-CDO-001): Four-tier classification scheme, three-level ownership model (Owner/Steward/Custodian), data lifecycle controls from collection through certified deletion, full jurisdiction-by-jurisdiction cross-border transfer framework covering all eight jurisdictions with specific legislation cited, in-country data residency compliance table, PCI DSS cardholder data controls, consent management, data subject rights with response SLAs, breach notification timelines by jurisdiction, DPA requirements, AI/ML governance, and a retention schedule covering all principal data types.

Simpaisa Group - Policy Suite¶

POLICY 1: OPERATIONAL RESILIENCE POLICY¶

Document Control¶

Revision History¶

Distribution¶

Related Policies¶

1. Purpose and Scope¶

1.1 Purpose¶

1.2 Scope¶

2. Definitions¶

3. Policy Statements¶

3.1 Commitment to Operational Resilience¶

3.2 Important Business Services¶

3.3 Impact Tolerances¶

3.4 Active-Active Architecture Requirement¶

3.5 Data Residency and Regulatory Requirements¶

3.6 SRE Model for Incident Response¶

4. Mapping of Resources Supporting Important Business Services¶

4.1 Framework¶

4.2 People Dependencies¶

4.3 Technology Dependencies¶

4.4 Third-Party Dependencies¶

4.5 Facilities Dependencies¶

5. Roles and Responsibilities¶

6. Procedures and Controls¶

6.1 Scenario Testing Programme¶

6.2 Frontier Market Resilience Controls¶

6.3 Communication Protocols¶

7. Monitoring and Reporting¶

7.1 Operational Metrics¶

7.2 Board and Committee Reporting¶

7.3 Annual Self-Assessment¶

8. DFSA Expectations for Operational Resilience¶

9. Exceptions and Escalation¶

10. Related Policies¶

Appendices¶

Appendix A: Infrastructure Resilience Map (RESTRICTED)¶

Appendix B: Service Dependency Register¶

Appendix C: Remediation Prioritisation Framework¶

Appendix D: Media Statement Templates¶

Appendix E: Exception Request Form¶

Appendix F: Scenario Test Record Template¶

POLICY 2: OUTSOURCING AND THIRD-PARTY MANAGEMENT POLICY¶

Document Control¶

Revision History¶

1. Purpose and Scope¶

1.1 Purpose¶

1.2 Scope¶

2. Definitions¶

3. Policy Statements¶

3.1 Governing Principles¶

3.2 Definitions of Outsourcing vs Procurement vs Partnership¶

4. Materiality Assessment Framework¶

4.1 Materiality Criteria¶

4.2 Classification of Current Material Third-Party Relationships¶

5. Due Diligence Requirements¶

5.1 General Principles¶

5.2 Financial Due Diligence¶

5.3 Operational Due Diligence¶

5.4 Security Due Diligence¶

5.5 Compliance and Regulatory Due Diligence¶

5.6 Reputational Due Diligence¶

6. Contractual Requirements¶

6.1 Mandatory Contract Terms¶

6.2 Enhanced Provisions for Critical Third Parties¶

7. Cloud Provider Governance¶

7.1 AWS Governance¶

7.2 Cloudflare Governance¶

7.3 In-Country Data Residency and Cloud Deployment¶

8. Concentration Risk Management¶

9. Ongoing Monitoring and Performance Management¶

9.1 Performance Monitoring¶

9.2 Ongoing Due Diligence Refresh¶

9.3 Third-Party Register¶

10. DFSA Outsourcing Notification Requirements¶

11. Exit Planning¶

12. Roles and Responsibilities¶

13. Monitoring and Reporting¶

14. Exceptions and Escalation¶

15. Related Policies¶