Third-Party Risk Management Policy

This policy defines how Tanqory selects, assesses, contracts, monitors, and offboards vendors, suppliers, subprocessors, partners, contractors, cloud/SaaS providers, and payment/logistics providers to protect customer/merchant data and business continuity. It aligns with ISO/IEC 27001/27701, SOC 2 practices, GDPR/PDPA, and sectoral requirements. The English version governs; if translations conflict, the stricter law or the more specific/latest document prevails. Updates are made when laws/standards or supply-chain risks change. The goal is to apply a risk-based, evidence-driven approach that balances speed of onboarding with rigor of controls, while providing transparent audit trails for customers, regulators, and internal oversight.

1) Purpose & Scope

Applies across the lifecycle: sourcing (procurement), pre-contract due diligence, contracting, continuous monitoring, incident handling, and offboarding/termination. Covers all third parties that access systems or process data for Tanqory. Enterprise-specific obligations may be further defined in Order Forms/contract appendices. Scope includes technical integrations (APIs/webhooks/SDKs), managed services, professional services with system access, and ancillary services (e.g., logistics, call centers) when they touch data or operations. Vendor-provided tools installed on endpoints or networks are also in scope when they have privileged access or telemetry.

2) Roles & Responsibilities

• Procurement: drive sourcing, initial screening, and commercial terms.
• Security: technical risk assessment (encryption, access, system privileges, vuln management).
• Privacy/Legal: DPA review, cross-border transfer mechanisms, contractual/privacy terms.
• Service Owner/Business: business impact, criticality, RPO/RTO requirements, replaceability.
• Risk Committee/Exec: approve high-tier vendors or exceptions beyond policy thresholds.
• Finance: evaluate financial health/viability and verify billing/insurance when required.
• Compliance: align with sectoral rules (e.g., PCI, healthcare, financial services) and maintain evidence for audits.
  All decisions and approvals must be logged for auditability (who, when, rationale, evidence). Responsibilities include maintaining a vendor inventory (owner, tier, data types, regions, subprocessors, renewal date) and ensuring renewals trigger reassessment when scope changes.

3) Risk Tiering

Vendors are tiered by data/system access, business impact, regulatory exposure, and replaceability:

• Tier 1 (Critical): processes customer/payment data, core infrastructure/production admin, or outage materially hits revenue/compliance.
• Tier 2 (High): important internal data/systems (e.g., HR/CRM/security tools) with elevated access but not core payments.
• Tier 3 (Medium): limited data/tools (e.g., analytics/marketing with restricted data).
• Tier 4 (Low): office utilities/no access to sensitive data.
  Scoring factors: data type (PII/payment/confidential), environment (Production/Admin vs Non-Prod/Read-only), business impact if unavailable, regulatory scope (PCI, HIPAA, cross-border), vendor lock-in/replaceability. Tier drives depth of assessment and required controls. A structured scorecard (e.g., 1–5 per factor) is used to reduce subjectivity; thresholds for each tier are documented and reviewed annually. Tiering also influences minimum insurance requirements, notification SLAs, and frequency of continuous monitoring.

4) Pre-Contract Due Diligence

• Tier 1: SOC 2 Type II or ISO 27001/27701, recent pen test (≤12 months), security/privacy questionnaire, DPA and transfer mechanisms (SCC/IDTA/DPF or equivalent), PCI DSS if payment-related, financial/continuity review.
• Tier 2: standard questionnaire + DPA + contract review; evidence of security controls (audit report/attestation).
• Tier 3: short questionnaire/attestation; confirm basic security/privacy, access limits, encryption/logging.
• Tier 4: minimal standard clauses/PO with baseline security terms.
  Assess least privilege access, encryption in transit/at rest, key/secret management, vulnerability management, audit logging, IRP/BCP. Approvals depend on risk treatment/compensating controls where gaps exist. For critical integrations (auth/payments/PII), require named points of contact, escalation paths, and confirmation of data residency/processing locations. Financial due diligence (for Tier 1–2) includes creditworthiness and going-concern checks. Where evidence is insufficient, require remediation plans with timelines before contract signature.

5) Contractual Controls

Contracts must define scope of services/data, security/privacy obligations, incident notice (24–72h by severity/regulation), audit/report rights (e.g., SOC 2/ISO), cross-border transfer terms (SCCs/IDTA/DPF or equivalent), subprocessor conditions/notice, data return/destruction, applicable RPO/RTO, and insurance (cyber/professional) by tier. For payment data, include PCI DSS requirements and prohibit storage/viewing of PAN/CVV in clear text. Additional clauses for higher tiers: right to conduct or receive penetration test summaries, obligation to maintain change logs and notify of material architectural changes, requirement to maintain business continuity/DR commensurate with contracted RPO/RTO, and to support customer regulatory inquiries where applicable. For AI/model providers handling customer data, add prohibitions on training on customer data without written consent and require model/data lineage documentation on request.

6) Continuous Monitoring

• Tier 1–2: annual review or upon major change/incident; refreshed SOC 2/ISO, vuln scan/pen test results, critical vuln remediation status, current subprocessor list.
• Tier 3: review every 1–2 years or on scope change.
• Tier 4: light monitoring (news/status checks).
  Track due dates, documents, findings, and remediation to show compliance history and risk trends. Use automated vendor monitoring (where available) for breach/news/adverse events; validate status changes (e.g., mergers, bankruptcy). Require updated DPA/transfer safeguards if regulatory adequacy changes. For PCI/financial vendors, align monitoring cadence with regulatory expectations (e.g., semi-annual for payment processors if mandated).

7) Change Management & Subprocessors

Changes to scope, access, data use, region, or adding/altering subprocessors require prior notice and impact assessment. Vendors must maintain a subprocessor inventory and provide advance notice (e.g., 30 days) so Tanqory can object or require safeguards. Data use expansions trigger retiering and additional controls. Cross-border moves must be assessed for lawful transfer mechanisms and recorded. Material changes (e.g., new data categories, production access, hosting region change, new auth/payment flow integration) require refreshed due diligence for Tier 1–2 and, where needed, customer notice per contract. Subprocessor onboarding by vendors must meet equivalent standards (flow-down of security/privacy terms, incident notice, deletion/return, residency). Objection and exit/mitigation options should be enumerated in the contract.

8) Incident & Continuity

Vendors must maintain and test IRP and BCP/DR. They must notify Tanqory of material incidents promptly (24–72h depending on severity/regulation). For incidents affecting customer/payment data, provide cause, scope, affected population, mitigations, and remediation plan with ETAs. Tanqory will assess business/customer impact and communicate per its IRP/BCP to meet legal/contract duties. For Tier 1–2, require named 24/7 contacts, escalation paths, and participation in joint incident calls if incidents affect Tanqory customers. Vendors must support forensics by preserving logs/evidence with chain of custody. Where incidents trigger legal notice (e.g., GDPR/PDPA/PCI), vendors must furnish required details to enable timely regulatory/customer notification. DR expectations: meet or exceed contracted RPO/RTO; test at least annually (semi-annually for critical payment/auth providers if required by contract).

9) Data Return/Destruction & Offboarding

Upon termination or request, vendors must return data in machine-readable form (e.g., CSV/JSON) via secure channels, then delete/destroy all copies/backups within agreed timelines (e.g., 30–60 days unless law requires retention) and provide a Certificate of Destruction. If retention is legally required, scope, purpose, duration, and access limits must be documented; remaining data must not be used for other purposes. Offboarding includes revoking credentials/API keys, disabling integrations/webhooks, confirming subprocessor deletions, and updating inventories/CMDB. For SaaS with customer-generated content, ensure export formats are complete and documented. Validate deletion via attestation or evidence (e.g., log excerpts) when feasible for Tier 1–2.

10) Data Handling & Residency

Data must be encrypted in transit (TLS) and at rest (e.g., AES-256); RBAC enforced; access logged. For personal/payment data, apply Privacy by Design/Default, data minimization, PCI DSS where applicable. If data residency is required, select compliant regions/offsite locations and document in contracts/DPA. Cross-border transfers must use lawful mechanisms (SCCs/IDTA/DPF/adequacy plus supplementary measures if needed) and be disclosed in the DPA/contract. For AI/analytics vendors, specify whether customer data may be stored/processed outside agreed regions and prohibit training on customer data without explicit consent. Require clear data flow diagrams/locations for Tier 1–2. Sensitive data in test environments must be masked or synthetic unless contractually authorized with controls.

11) Recordkeeping & Audit

Maintain records of assessments, approvals, contracts, evidence, monitoring results, incidents, and offboarding. Retain ≥3–5 years or longer per law/contract. Protect records with encryption and least privilege. TPRM and this policy are subject to internal/external audit under ISMS/SOC 2; remediation plans must be tracked to closure. Maintain an auditable trail of risk scores, mitigation decisions, exceptions, and waivers with expiry. Ensure evidence of vendor certifications and their validity periods. Support customer/regulator requests for vendor assurance (e.g., sharing SOC 2 under NDA) per contract.

12) Policy Updates

Review at least annually or upon legal/standard/supply-chain changes or post-incident lessons. Material changes are posted to https://legal.tanqory.com and/or emailed to registered stakeholders with effective date/version. The English version is authoritative.

---

Appendix A: Sample Tiering & Required Evidence

Additional evidence (as applicable): AI/ML model cards or data sheets for vendors processing customer data; SBOM or supply-chain attestations for software components; secure SDLC evidence for SDKs/agents deployed in Tanqory environments; data flow diagrams and residency statements for Tier 1–2.

Appendix B: Standards Mapping (Audit Aid)

• ISO/IEC 27001:2022 Annex A: A.5 (supplier relationships), A.5.19–A.5.23 (supply chain/contract/monitoring), A.8 (asset/access/vuln/logging in DD/monitoring).
• ISO/IEC 27701: controller/processor requirements for subprocessors, DPA, cross-border transfers.
• SOC 2: CC3 (risk), CC4 (monitoring), CC7 (change/incident/vuln); reference vendor SOC 2 Type II for Tier 1–2.
• PCI DSS (if card data): Req.12 (security policy/vendor mgmt), Req.9/10 (logging/monitoring) for payment-related vendors.
• GDPR/PDPA: DPA, SCCs/IDTA/DPF/supplementary measures, audit rights/incident notice, Privacy by Design/Default and data minimization.

Glossary

• TPRM: Third-Party Risk Management.
• DPA: Data Processing Agreement.
• IRP: Incident Response Plan.
• BCP/DR: Business Continuity / Disaster Recovery.
• RPO/RTO: Recovery Point/Time Objective.
• SCCs: Standard Contractual Clauses.
• IDTA: International Data Transfer Addendum.
• PCI DSS: Payment Card Industry Data Security Standard.
• SOC 2: Security/privacy control attestation for service organizations.
• RBAC: Role-Based Access Control.
• PO: Purchase Order.
• PII: Personally Identifiable Information.