Skip to content

STD-GOV-134: Third-Party Risk Management

Field Value
Standard STD-GOV-134
Title Third-Party Risk Management
Status Draft
Owner Security Lead
Created 2026-04-03
Review Quarterly

Purpose

Establish a structured approach to managing risks from third-party vendors and partners that Simpaisa depends upon. As a payment gateway processing $1B+ across PK, BD, NP, IQ and EG, Simpaisa's reliability and compliance posture is directly tied to its vendors — from payment channels (Easypaisa, bKash, eSewa) to infrastructure providers (Cloudflare, AWS, ControlPlane.com).

Scope

All third-party vendors, partners and service providers that Simpaisa integrates with or depends upon for production operations. Includes payment channels, cloud infrastructure, security services, development tools and regulatory service providers.

Current State

  • Vendor relationships managed per-market by integration teams.
  • No centralised vendor risk registry.
  • SLA monitoring exists for some payment channels but is informal.
  • No contingency plans for critical vendor failure.
  • Vendor security assessments done at onboarding but not repeated.

Gaps

  1. No centralised vendor risk registry with classification.
  2. No annual reassessment of critical vendors.
  3. No contingency plans for permanent vendor failure.
  4. No quarterly SLA monitoring across all vendors.
  5. Vendor failure not included in disaster recovery drills.

Target State

  • Centralised vendor risk registry in Beads (tag vendor-risk).
  • Annual assessment for critical vendors; biennial for non-critical.
  • Contingency plan documented for every critical vendor.
  • Quarterly SLA monitoring with automated tracking.
  • Vendor failure scenarios included in DR drills.

Vendor Classification

Tier Definition Assessment Cadence
Critical Production transaction path; outage = revenue loss Annual
High Supports operations; outage = degraded service Annual
Medium Efficiency enablers; outage = inconvenience Biennial
Low Non-essential; easily replaceable On renewal

Critical Vendors (Current)

Vendor Category Markets Tier
Easypaisa Payment channel PK Critical
JazzCash Payment channel PK Critical
bKash Payment channel BD Critical
eSewa Payment channel NP Critical
Cloudflare Edge / CDN / DLP All Critical
AWS Cloud infrastructure All Critical
ControlPlane.com Kubernetes platform All Critical
Card networks Visa/Mastercard All Critical

Annual Assessment Framework

Each critical vendor assessment covers:

# Area Assessment Method
1 Financial stability Financial statements, credit rating review
2 Security posture Security questionnaire (SIG Lite)
3 Compliance Certifications (PCI DSS, ISO 27001, SOC 2)
4 SLA performance Actual vs contracted uptime and latency
5 Incident history Vendor incidents impacting Simpaisa
6 Concentration risk Revenue dependency percentage
7 Data handling PII processing, storage, retention
8 Business continuity Vendor's own DR/BCP documentation

Quarterly SLA Monitoring

  • Automated SLA tracking for all Critical and High vendors.
  • Metrics collected: availability, latency, error rates, response times.
  • OpenTelemetry metrics per vendor integration endpoint.
  • Quarterly report compiled and reviewed at ARB.
  • SLA breach triggers formal vendor communication.

Contingency Plans

Every Critical vendor must have a documented contingency plan answering:

  1. Detection: How do we know the vendor is failing? (monitoring, alerts)
  2. Immediate response: What do we do in the first 30 minutes?
  3. Short-term mitigation: How do we continue operations for 24-72 hours?
  4. Alternative provider: Who is the backup vendor? Is integration ready?
  5. Migration plan: How long to fully migrate if vendor fails permanently?
  6. Communication: How do we inform affected merchants and regulators?

Example: If Easypaisa goes down permanently — route PK mobile wallet transactions to JazzCash; timeline to integrate alternative: 2 weeks for existing API, 6 weeks for full parity.

Vendor Failure in DR Drills

  • Annual DR drill must include at least one vendor failure scenario.
  • Simulate: payment channel outage, Cloudflare outage, AWS region failure.
  • Test contingency plan execution and measure recovery time.
  • Findings tracked in Beads with tag dr-drill.

Actions

# Action Owner Deadline
1 Create vendor risk registry in Beads Security Lead 2026-Q2
2 Conduct annual assessment for all Critical vendors Security Lead 2026-Q2
3 Document contingency plans for Critical vendors Platform Lead 2026-Q2
4 Build automated SLA monitoring per vendor Platform Team 2026-Q3
5 Include vendor failure in next DR drill Security Lead 2026-Q3

References

  • VENDOR-INTEGRATION-REGISTER.md
  • INFRASTRUCTURE-STANDARDS.md
  • INCIDENT-RESPONSE-PLAYBOOK.md
  • SECURITY-ARCHITECTURE.md