Chapter 6: Third-Party Risk Management (TPRM)

Financial institutions in the GIFT IFSC rely extensively on third-party service providers, cloud hyperscalers, external market data feeds, software vendors, and outsourced IT operations to maintain technological competitiveness. However, outsourcing operational activities does not outsource regulatory accountability. If a third-party vendor suffers a catastrophic cyber breach or data leakage, ultimate legal, regulatory, and reputational liability remains with the regulated entity.

Third-Party Risk Management (TPRM) is the end-to-end framework of policies, procedures, and continuous oversight mechanisms designed to identify, assess, manage, and mitigate the cybersecurity, operational, and compliance risks introduced by external entities throughout their relationship lifecycle.

                          THE 5-STAGE TPRM LIFECYCLE
                                       │
     ┌───────────────────┬─────────────┴─────────────┬───────────────────┐
     ▼                   ▼                           ▼                   ▼
[ 1. SOURCING &     [ 2. DUE DILIGENCE &        [ 3. CONTRACTUAL    [ 4. ONGOING        [ 5. OFFBOARDING
  RISK TIERING ]         ASSESSMENT ]                SAFEGUARDS ]        MONITORING ]        & EXIT ]
- Define scope      - SOC 2 Type II reports     - Right to audit    - Continuous threat - Data purge certs
- Classify critical - Security architecture     - Breach notice SLA   telemetry         - Revoke access
  vs non-critical   - Financial stability       - Data ownership    - Annual reassessment- Return assets

1. Risk-Based Vendor Tiering

Prior to conducting due diligence, organizations must categorize prospective vendors into risk tiers based on the criticality of the services provided and their access to corporate networks and data:

2. Pre-Contractual Due Diligence and Vendor Assessment

Before entering into commercial commitments with Tier 1 or Tier 2 third parties, the regulated entity must execute rigorous due diligence:

• Independent Security Assurance Reports: Demanding and reviewing recent SOC 2 Type II (System and Organization Controls) reports, focusing on the Trust Services Criteria (Security, Availability, Confidentiality, and Processing Integrity). Unlike Type I reports which assess control design at a single point in time, Type II reports verify operational effectiveness over a testing window (typically 6 to 12 months).
• ISO/IEC 27001 & 27017/27018 Certifications: Verifying valid accreditation for information security management and cloud data privacy controls.
• Financial and Operational Stability: Reviewing audited financial statements to ensure the vendor is not in immediate danger of insolvency, which could precipitate abrupt service cessation.
• Adversarial Assessment: Subjecting the vendor’s internet-facing assets to non-intrusive external vulnerability scanning and security rating evaluations.

A robust third-party risk framework translates technical security expectations into legally binding contractual covenants. In the absence of explicit contractual protections, financial institutions cannot compel external vendors to remediate vulnerabilities, report breaches promptly, or permit regulatory inspections.

                    ESSENTIAL CONTRACTUAL SAFEGUARDS IN TPRM
                                       │
     ┌───────────────────┬─────────────┴─────────────┬───────────────────┐
     ▼                   ▼                           ▼                   ▼
[ RIGHT TO AUDIT ]   [ BREACH NOTIFICATION ]     [ DATA RESIDENCY &  [ ESCROW & SOURCE
- Inspect facilities - Statutory SLA: Notify       OWNERSHIP ]         CODE DEPOSITS ]
- Independent pen-     within 2-6 hours          - Encrypted at rest - Third-party agent
  testing rights     - Forensic data preservation- Immediate return  - Software release
- Regulatory access  - Full liability indemnity    upon termination    upon bankruptcy

1. Mandatory Contractual Safeguards for GIFT IFSC Entities

Under IFSCA Cyber Security Guidelines, all outsourcing and third-party contracts must explicitly incorporate:

1. Right to Audit and Inspect: The regulated entity, its internal/external auditors, and statutory officers of the IFSCA must have the legal right to inspect the vendor’s premises, examine technical logs, and audit cybersecurity controls relevant to the outsourced services without impediment.
2. Mandatory Security Incident Notification SLAs: The vendor must be contractually bound to notify the regulated entity’s CISO of any confirmed or suspected cybersecurity incident within 2 to 6 hours of discovery. The vendor must provide continuous forensic updates and preserve evidence.
3. Data Ownership, Sovereignty, and Location: Explicit declaration that all customer records, transaction data, and intellectual property remain the exclusive property of the regulated entity. Prohibition against cross-border data transfer without prior written regulatory consent.
4. Sub-Contracting (Fourth-Party) Restrictions: The vendor is legally barred from sub-contracting or sub-outsourcing any critical operational components to fourth-party entities without obtaining prior formal written authorization from the regulated entity.
5. Business Continuity and Disaster Recovery (BCP/DR): Mandating that the vendor maintain an active DR site with recovery capabilities meeting the financial entity's Recovery Time Objective (RTO) and Recovery Point Objective (RPO), with annual shared failover drill participation.

2. Software Supply Chain Security: SBOM and Source Code Escrow

• Software Bill of Materials (SBOM): A formal, machine-readable inventory cataloguing all third-party software components, libraries, open-source modules, and dependencies embedded within a software product (utilizing industry standards such as SPDX or CycloneDX). If a critical vulnerability (e.g., Log4Shell) emerges in an open-source library, the SBOM enables instant identification of affected enterprise software assets.
• Source Code Escrow Agreements: For proprietary, mission-critical third-party software (such as exchange matching engines or core banking platforms), the vendor must deposit the complete source code, compilation scripts, and technical documentation with an independent Escrow Agent. In the event of vendor bankruptcy, liquidation, or failure to maintain the software, the source code is legally released to the regulated entity to guarantee business continuity.

3. Concentration Risk in the Financial Sector

Concentration Risk occurs when multiple financial institutions or critical market infrastructures within the GIFT IFSC depend on the identical third-party service provider or cloud platform (e.g., several major brokers relying on a single market data vendor or cloud region).

• Systemic Vulnerability: A single cyber outage or ransomware infection at the concentrated vendor can trigger systemic cascading contagion across the entire financial ecosystem.
• Mitigation Strategies: Multi-cloud architectures, maintaining secondary warm-standby vendors, periodic concentration risk mapping, and setting maximum operational exposure caps for any single external vendor.

The modern outsourcing ecosystem is rarely a simple, one-to-one relationship. Primary vendors (third parties) frequently depend upon extensive networks of sub-contractors, specialized software vendors, and cloud providers (fourth parties). Unless strictly governed, this creates hidden blind spots that erode enterprise cybersecurity and regulatory oversight.

                    THE EXPANDED SUPPLY CHAIN (FOURTH PARTIES)
                                         │
                   [ REGULATED FINANCIAL ENTITY (IFSC) ]
                                         │
                               (Direct Contract / SLA)
                                         ▼
                        [ THIRD PARTY: Primary Vendor ]
                         (e.g., FinTech SaaS Provider)
                                         │
                             (Sub-Outsourcing Chains)
                                         ▼
                      [ FOURTH PARTY: Sub-Contractor ]
                   (e.g., Cloud Hyperscaler / Data Host)
                                         │
                                         ▼
                     [ FIFTH PARTY: Sub-tier Dependency ]
                     (e.g., Open-Source Package / CDN)

1. Managing Fourth Parties and Sub-Outsourcing Risks

• The Sub-Outsourcing Dilemma: A financial institution may thoroughly vet its primary software vendor, only for that vendor to host sensitive customer databases on an unhardened, non-compliant fourth-party public cloud server.
• Governance Requirements:
  • The primary contract must mandate that the third party enforces security, privacy, and audit standards identical to or more stringent than those imposed on the third party itself across all downstream sub-contractors.
  • The third party must maintain and disclose an accurate register of all fourth parties handling regulated entity data.
  • The regulated entity retains the absolute right to veto the appointment of any proposed fourth-party sub-contractor.

---

2. The Cloud Shared Responsibility Model

When regulated entities migrate infrastructure, applications, or data to public cloud service providers (CSPs like AWS, Microsoft Azure, Google Cloud), security responsibilities are divided between the CSP and the customer according to the service model:

                      CLOUD SHARED RESPONSIBILITY BREAKDOWN
                                        │
     ┌────────────────────────┬─────────┴─────────┬────────────────────────┐
     ▼                        ▼                   ▼                        ▼
 [ ON-PREMISES ]           [ IaaS ]            [ PaaS ]                 [ SaaS ]
 Customer Manages:        Customer Manages:   Customer Manages:        Customer Manages:
 - Data & Access          - Data & Access     - Data & Access          - Data & Access
 - Applications           - Applications      - Applications           - User Credentials
 - Operating System       - Operating System  - Basic Config           CSP Manages:
 - Network & Firewalls    - Network Config    CSP Manages:             - Everything else
 - Hypervisor & Servers   CSP Manages:        - OS, Runtime, DB Engine   (App, OS, Infra)
 - Physical Facilities    - Physical / Hyper  - Physical / Hyper

• Infrastructure as a Service (IaaS): The CSP is responsible for the physical security of data centres, power, cooling, physical servers, storage disks, and virtualization hypervisors ("Security OF the Cloud"). The customer is responsible for configuring operating systems, network firewalls, installing security patches, managing databases, enforcing encryption, and managing IAM accounts ("Security IN the Cloud").
• Platform as a Service (PaaS): The CSP manages the underlying operating system, hardware, database software, and execution runtime. The customer remains responsible for securing application code, API integrations, and data access.
• Software as a Service (SaaS): The CSP manages the entire technology stack, application code, infrastructure, and availability. The customer remains responsible for data classification, user credential management, role-based access assignment, and monitoring user activities.
• Crucial Rule: In every cloud service model, Data Classification, Access Governance, and Regulatory Compliance remain 100% the responsibility of the financial institution.

---

3. Secure Vendor Offboarding and Termination Protocols

The termination of a vendor contract presents significant data exposure and unauthorized access risks if not governed by disciplined offboarding procedures:

1. Immediate Revocation of Logical and Physical Access: Deactivating all vendor user accounts, terminating Site-to-Site VPN tunnels, revoking API keys, invalidating SSL/TLS client certificates, and reclaiming physical access badges.
2. Data Retrieval and Cryptographic Sanitization: Ensuring all proprietary data, client records, and software code are securely transferred back to the financial entity, followed by certified data erasure on the vendor’s storage arrays in accordance with NIST SP 800-88 Guidelines for Media Sanitization.
3. Formal Certificate of Destruction: Demanding a legally binding, officer-signed Certificate of Destruction confirming that all electronic and physical copies of confidential data have been permanently purged from primary storage, shadow copies, and backup media.
4. Post-Termination Survival of Confidentiality: Enforcing contractual clauses stipulating that non-disclosure, confidentiality, and regulatory audit cooperation obligations survive indefinitely post contract termination.