SEBI CSCRF ID.2 Third-Party Risk: Building a TPRM Programme That Satisfies Regulators

In SEBI's 2023–24 inspection cycle, ID.2 — Third-Party Risk Management — was cited as the #2 most common gap across all regulated entity categories, behind only ID.1 (Identity and Access Management). Yet most CISOs treat TPRM as a contract management problem rather than a cyber risk management discipline.

The stakes are significant. SEBI does not distinguish between a breach caused directly by a regulated entity and one caused by a vendor acting on its behalf. The licence holder bears full liability. With DPDP Act penalties of up to ₹250 crore for data protection failures — including those caused by vendors — the cost of an inadequate TPRM programme has never been higher.

What SEBI CSCRF ID.2 Actually Requires

SEBI CSCRF Identify domain sub-category ID.2 covers the full lifecycle of third-party cyber risk management. The framework requires regulated entities to demonstrate:

• ID.2.1 — A maintained inventory of all third parties with access to systems or data
• ID.2.2 — Risk-based tiering of vendors by criticality and data sensitivity
• ID.2.3 — Contractual security requirements including right to audit and incident notification SLAs
• ID.2.4 — Periodic vendor assessments (annual for Tier 2, semi-annual for Tier 1)
• ID.2.5 — Continuous monitoring of critical vendors and sub-contractor disclosure
• ID.2.6 — Exit strategy and data return/deletion provisions for Tier 1 vendors

Vendor Classification Framework for Indian BFSI

The most important TPRM decision is vendor tiering — the basis for all subsequent assessment frequency, contractual requirements, and monitoring intensity. SEBI expects a documented, risk-based rationale for each vendor's tier assignment.

The 6 Contractual Controls SEBI Inspectors Look For

During an inspection, SEBI may request 2–3 vendor contracts for review. These six clauses are specifically checked — their absence is a finding:

1. Right to Audit

The regulated entity must retain the right to conduct or commission a security audit of the vendor's systems and processes, on reasonable notice (typically 30 days). This right should extend to sub-contractors who access regulated data. Many legacy contracts signed before CSCRF was enforced lack this clause — a SEBI finding if uncorrected.

2. Incident Notification SLA

Vendors must notify the regulated entity of any security incident affecting shared systems or data within 2 hours of discovery — consistent with the 6-hour CERT-In reporting window that the regulated entity itself must meet. A 24-hour or "reasonable time" SLA does not satisfy CSCRF ID.2.

3. Data Return and Deletion on Exit

Upon contract termination, the vendor must return all regulated data in a specified format within a defined period (typically 30 days) and provide a certificate of deletion. The deletion must include backups and disaster recovery copies. This is the "exit strategy" element of ID.2.6.

4. Sub-contractor Disclosure and Approval

The vendor must disclose all sub-contractors who will access the regulated entity's data or systems, and obtain prior written approval before adding new sub-contractors. This provision prevents "fourth-party risk" from materialising invisibly — a growing concern as cloud vendors increasingly chain sub-processors.

5. Access Provisioning and Deprovisioning

Vendor access must follow a formal provisioning process aligned with the regulated entity's IAM policy. Access must be deprovisioned within 24 hours of contract termination or personnel change. Shared service accounts for vendor access are specifically prohibited under SEBI CSCRF ID.1.

6. Minimum Security Standards

The contract must specify baseline security requirements: MFA for remote access, encryption of regulated data in transit and at rest, patch management SLA (critical patches within 30 days), and compliance with applicable Indian regulations (CERT-In, DPDP where applicable).

Inherent Risk Scoring: The Calculation SEBI Expects

SEBI expects vendor risk tier assignments to be supported by an inherent risk score, not just judgment. A defensible scoring model considers four dimensions:

Inherent Risk Score = (Data Sensitivity × 0.35) + (System Criticality × 0.35) + (Geography × 0.15) + (Concentration × 0.15). Scores above 3.5 automatically qualify for Tier 1 regardless of perceived criticality.

TPRM Maturity Levels

Most Common ID.2 Inspection Failures