Business Continuity Plan (BCP)

This plan provides the framework for Tanqory to maintain continuity of critical services during unexpected disruptions. It covers Business Impact Analysis (BIA), risk management, continuity and recovery strategies, crisis communications, and continual testing/improvement. The English version prevails; if any translation conflicts arise, the English governs.

1) Purpose and Scope

The plan preserves continuity for core services (Platform, Payments, API, Authentication, Admin/Merchant/Partner Portals) and supporting processes (Support, Billing, Communications) during disruptions. It minimizes business, reputational, legal, and contractual impact through defined and tested Recovery Time/Point Objectives (RTO/RPO), while protecting data and security throughout an incident. It sets clear roles/responsibilities and coordination with external providers. Scope covers all personnel, critical business processes, infrastructure/data/apps, and locations (data centers/offices/remote work) across all regions and critical vendors under contract. It links to sub-plans: Disaster Recovery (DR), Incident Response Plan (IRP), Backup Policy, Access Control Policy, and Third-Party Risk Management (TPRM). Review at least annually or after architectural changes/lessons learned, and invoke when services are impeded (e.g., downtime beyond SLA, natural disasters, cyber events, or critical vendor failure).

2) Governance & Roles

• BCP/DR Steering Committee led by the CISO/CTO approves, updates, and oversees annual testing.
• Incident Commander (IC) is appointed per event, empowered to direct, decide failover/restore, and coordinate the Crisis Management Team (CMT).
• Service Owners define RTO/RPO, maintain recovery runbooks, and ensure team readiness.
• Communications Lead manages internal/external comms (customers, partners, regulators) in line with legal/contractual notice duties.
• Legal/Privacy Lead assesses data protection/tax/contract requirements and advises on regulatory notifications.
• Vendor Manager coordinates TPRM, critical supplier status (cloud/payment/network), and escalation paths.
• HR/People Lead handles workforce readiness, on-call/shift rotations, remote work, and employee communications.
• Each role requires a named backup and current emergency contact information (see appendix).

3) Business Impact Analysis (BIA), RTO/RPO

• Critical functions: Payments, Checkout, Core API, Auth/Identity, Customer/Merchant Data, Admin/Merchant/Partner Portals, Logging/Monitoring, Support Communications.
• Sample RTO/RPO (refined per-service runbooks): Critical RTO ≤ 15 minutes, RPO 0–5 minutes; High RTO ≤ 1 hour, RPO ≤ 15 minutes; Medium RTO ≤ 4 hours, RPO ≤ 1 hour; Low RTO ≤ 24 hours, RPO ≤ 4 hours.
• Impacts considered across revenue, reputation, legal/data protection, and contractual obligations (customer SLAs).
• Recovery priority: (1) Payments/Checkout/API/Auth (2) Data stores/backups (3) Notifications/Status Page (4) Dashboards/Reporting.
• Maintain BIA in the appendix with owners and last review date; link to the Risk Register.
• Use BIA to scope DR/BCP tests and set the resilience budget.

Sample RTO/RPO Table

4) Continuity Strategies & Infrastructure

• Multi-region/data center design with LB/Anycast DNS and health checks.
• Multi-AZ for critical services with hot/warm standby aligned to BIA.
• Data replication (sync/async) per RPO, encrypted in transit/at rest; full/incremental backups with tested restores.
• Capacity buffer and auto-scaling for peak/emergency loads; DR resource reservations.
• Configuration/Infrastructure as Code (IaC) to enable rapid, consistent rebuilds.
• Service-specific failover/fallback runbooks with decision points, approvers, steps, and expected timelines.
• Minimum Viable Service (MVS) mode defined for severe events to keep essential functions running with reduced features.
• Data residency/contractual requirements drive region/offsite backup selection; comply with local law.
• KMS/HSM for key management and RBAC for recovery access.

Replication/Failover Matrix (example)

5) Incident & Crisis Management

• Follow the Incident Response Plan: detect/notify, severity rating (P1–P4), appoint IC, open war room/channels, log the timeline.
• For severe crises, convene CMT: Crisis Director (CEO/CTO), Comms Lead, Legal/Privacy, Ops/Eng Leads, Customer Success.
• Execute failover/fallback per runbook and BIA; log decision, time, and approver for audit/lessons learned.
• Customer channels: Status Page, email, in-app; regulators as required (e.g., personal data incidents).
• If personal data or payments are implicated, invoke Data Breach Playbook/PCI Incident Runbook.
• Record incidents in tickets with RCA and preventive actions within defined timelines.

6) Communications & Stakeholders

• Use Status Page, email broadcasts, and in-app banners for incident notice, impact, and recovery ETA consistent with SLA/regulatory duties.
• Internal urgent channels: Slack/Teams war room, on-call phone; external: status.tanqory.com, support@tanqory.com, security@tanqory.com.
• Message templates must include incident description, scope, affected services, expected RTO, customer actions (if any), and next update time.
• Define what can be disclosed to avoid security/privacy violations.
• Legal/Privacy Lead to file regulator notices (data/financial) within statutory timelines.
• Prepare Q&A for frontline/Customer Success to ensure consistent messaging.
• For P1 incidents, target customer status updates every 60–120 minutes (adjust per Enterprise contracts) and document in runbooks/contracts.

7) Third-Party Dependencies & Supply Chain

• Maintain a critical vendor register (Cloud, CDN, Payment Gateway, DNS, SMS/Email) with SLA, escalation channels, and outage impact.
• Plan fallbacks (e.g., multi-DNS, secondary payment processor, out-of-band comms).
• Review vendor BCP/DR per TPRM cycle and retain evidence (SOC 2/ISO 27001).
• Monitor vendor status pages/RSS automatically and tie to service switch runbooks.
• For personal data, confirm DPA and cross-border measures comply with PDPA/GDPR/other laws.
• Critical vendor matrix (example):

  Vendor	Service	Key SLA	Notify/Escalation	Fallback	Owner
  AWS/GCP/Azure	Compute/Storage/DB	99.9–99.99%	Contract escalation + status page	Cross-region/multi-cloud	Vendor Manager
  Payment Processor A	Payments	99.9%	Hotline + portal	Switch to Processor B (per contract)	Head of Payments
  DNS Provider	DNS/Anycast	99.99%	NOC hotline	Secondary DNS	Network Lead
  CDN/WAF	CDN/Security	99.9%	Portal/hotline	Origin + alternate CDN	Security Lead
  SMS/Email Provider	Messaging	99.9%	Portal/hotline	Backup provider	Comms Lead

8) People, Facilities, and Operations

• Support remote work for key teams with VPN, MFA, and endpoint protection.
• Work-area recovery options if the primary office is unusable.
• Shift/on-call structure to ensure 24/7 coverage for critical services.
• Maintain emergency contact lists (staff, leadership, key vendors) with alternate channels.
• Train staff on BCP/DR roles; conduct evacuation/physical safety drills as needed.

9) Testing, Exercises, and Improvement

• Test BCP/DR at least annually: tabletop, simulations, and technical DR failover/restore.
• Test backup/restore at least quarterly for critical systems; record duration and data completeness.
• Conduct After Action Reviews (AAR) and Improvement Plans with owners and deadlines.
• Update runbooks after each incident/test.
• Track metrics: achieved RTO/RPO, MTTR, and exercise success rate.
• If customer/regulated requirements apply (e.g., Enterprise/financial), run additional mandated tests.
• Suggested cadence: tabletop every 6 months; simulation annually; DR failover annually (or more per risk). Log results, approvals, and actual RTO/RPO/MTTR for audit.

10) Maintenance & Governance

• Review the document at least annually, or immediately after major incidents/architectural changes.
• Record versions/changes in Version History and notify stakeholders of material updates.
• Store BCP/DR, runbooks, AARs, and test logs in access-controlled repositories with off-production backups.
• Check alignment with local laws (data protection/tax/financial sector) and customer contract requirements.
• Integrate with Enterprise Risk Management (ERM) and ISMS for unified controls and metrics.
• Record retention: keep BCP/IR/DR/AAR documents and test/metric logs for at least 3–5 years or the longer of legal/contractual requirements before deletion/anonymization.

11) Appendices

Appendix A: BIA/RTO/RPO (Sample)

Appendix B: Emergency Contacts (Sample)

• Security/Incident: security@tanqory.com, on-call (in runbook), status.tanqory.com
• Operations/NOC: ops@tanqory.com, NOC hotline (internal)
• Legal/Privacy: legal@tanqory.com, dpo@tanqory.com (if applicable)
• Customer Communications: support@tanqory.com, press@tanqory.com (for public statements)
• Key vendors: Cloud (AWS/GCP/Azure) – escalation per contract; Payment Processor – per TPRM register

Appendix D: Compliance Mapping (Sample)

Appendix E: Data Residency & Sectoral Requirements (Sample)

• If a customer/contract mandates data location, select region/offsite backup accordingly and record in contract/runbook.
• For regulated verticals (financial/health/public sector), confirm specific standards/laws (e.g., in-country backup, mandated recovery time) and document in runbooks and contract schedules.
• For cross-border transfers, apply lawful safeguards (e.g., SCC, DPF, permitted derogations) and notify customers per contract.

Appendix C: Glossary

• BCP (Business Continuity Plan) A plan to keep business services running.
• DR (Disaster Recovery) Recovery of systems/data after a disruptive event.
• BIA (Business Impact Analysis) Analysis of business impact from disruptions.
• RTO (Recovery Time Objective) Target time to restore a service.
• RPO (Recovery Point Objective) Maximum tolerable data loss point.
• IRP (Incident Response Plan) Plan for incident handling.
• CMT (Crisis Management Team) Organization-level crisis team.
• TPRM (Third-Party Risk Management) Management of external provider risk.
• AAR (After Action Review) Post-incident/exercise review.
• MTTR (Mean Time To Recover) Average time to restore service.
• MVS (Minimum Viable Service) Minimum acceptable service level in a severe event.

Version History