Third-Party Vendor Risk Management for Indian Companies

Third-party and vendor risk management (TPRM) is the process of identifying, assessing, and continuously monitoring the security risks that suppliers, SaaS platforms, contractors, and other external parties introduce into your organisation. For Indian companies, this is no longer optional: vendors now account for a significant share of data breaches, and the DPDP Act 2023 places explicit obligations on organisations that share personal data with third parties. If a vendor is breached and your customers' data leaks, you are accountable.

This guide explains why vendors are a serious breach vector, how to build a practical TPRM programme from scratch, what your obligations are under Indian law, and how to assess a vendor's security posture before you sign — or renew — a contract.

Why Vendors Are Your Biggest Unmanaged Attack Surface

Your internal team may follow strong security hygiene. But every SaaS tool you connect, every contractor you give access to, every API integration you enable extends your attack surface to their security posture — which you cannot control.

Three dominant breach patterns via third parties are:

Supply-chain compromise. An attacker compromises a software vendor upstream. When the vendor pushes an update, the malicious payload reaches every customer. The 2020 SolarWinds attack and the 2021 Kaseya VSA ransomware event both followed this pattern and affected thousands of organisations that had no direct vulnerability themselves.

SaaS data exposure. A misconfigured third-party SaaS platform — CRM, HR software, document management — exposes your data because the vendor's cloud storage bucket or API endpoint is improperly secured. The breach belongs to the vendor but the liability sits with you.

Contractor and insider risk. Developers, auditors, or managed-service providers who have privileged access to your systems are often granted that access without the same onboarding rigour as employees. When their credentials are phished or their systems are compromised, attackers walk in through a legitimate door.

Building a TPRM Programme: The Six Pillars

1. Vendor Inventory — Know What You Have

You cannot manage risk you have not mapped. Start by cataloguing every vendor relationship:

1. SaaS platforms (CRM, HRMS, ERP, analytics, payments, email, storage)
2. Cloud infrastructure providers (AWS, Azure, GCP, OCI)
3. Contractors, freelancers, and managed service providers with system access
4. Software and open-source libraries integrated into your product (software supply chain)
5. API integrations with third-party services (payment gateways, SMS, logistics)

2. Risk Tiering — Not All Vendors Are Equal

Tiering vendors by risk allows you to apply proportionate due diligence rather than treating a stationery supplier the same as your cloud database provider.

3. Vendor Due Diligence — Security Questionnaires and Evidence

Before onboarding a Critical or High-tier vendor, send a security questionnaire. Do not accept verbal assurances. Ask for evidence.

Key areas to cover in a vendor security questionnaire:

1. Data handling: What data will you store? In which regions? How long? How is it encrypted at rest and in transit?
2. Access controls: Do you enforce MFA for all staff with access to our data? How is privileged access managed?
3. Certifications: Do you hold ISO 27001, SOC 2 Type II, PCI-DSS, or equivalent? Provide the certificate and the audit period.
4. Incident response: What is your breach notification SLA? Have you had a security incident in the past 24 months? What was the impact and remediation?
5. Subprocessors: Do you share our data with any subcontractors or sub-processors? Who are they?
6. Penetration testing: How frequently do you run external VAPT? Can you share a summary report or attestation letter?
7. Business continuity: What is your RTO and RPO? Do you have a tested DR plan?

4. Security Clauses in Vendor Contracts

Questionnaires assess current posture. Contracts create enforceable obligations going forward. Your vendor agreements — especially for Critical and High-tier vendors — should include:

1. Data Processing Agreement (DPA): Mandatory for any vendor acting as a Data Processor under DPDP. Must specify what data is processed, the purpose, retention, and deletion obligations.
2. Security standards clause: Vendor must maintain security controls at least equivalent to ISO 27001 or SOC 2 controls.
3. Breach notification SLA: Vendor must notify you within 72 hours (aligning with DPDP and good practice) of discovering a breach involving your data.
4. Right to audit: You retain the right to request a copy of the vendor's latest third-party security audit or to conduct an audit with reasonable notice.
5. Subprocessor restrictions: Vendor may not engage new subprocessors for your data without prior written consent.
6. Data deletion on offboarding: Vendor must delete or return all your data within a defined period upon contract termination, with written confirmation.

5. Continuous Monitoring

Onboarding due diligence is a point-in-time check. Vendor risk is dynamic. A vendor that was ISO 27001 certified last year may have had its certificate lapse. A SaaS platform that was secure at onboarding may have introduced a new third-party integration that creates new exposure.

Continuous monitoring activities include:

1. Annual re-assessment: Re-run the security questionnaire for Critical vendors every year, or after any major vendor incident.
2. Certificate tracking: Track expiry dates for ISO 27001, SOC 2, and PCI-DSS certificates. Set calendar reminders 90 days before expiry.
3. Threat intelligence feeds: Subscribe to public breach disclosure services (Have I Been Pwned enterprise, data breach news) to get early warning if a vendor is compromised.
4. Contractual milestone checks: Review security clauses at contract renewal to ensure they still reflect current requirements.
5. Incident response drills: At least once a year, table-top a scenario where a critical vendor notifies you of a breach. Do you know what to do? Who to call? What to tell your customers?

6. Vendor Offboarding — Close Every Door

When a vendor relationship ends, the security work is not done until access is revoked and data is confirmed deleted. Offboarding checklist:

1. Revoke all API keys, OAuth tokens, and credentials the vendor held
2. Disable or delete SSO/SAML provisioning for contractor accounts
3. Remove vendor IP ranges from firewall allowlists
4. Confirm data deletion in writing (DPA obligation)
5. Rotate any shared secrets the vendor was aware of
6. Archive the vendor file for audit purposes

The TPRM Lifecycle — Vendor Onboarding to Offboarding

graph TD
    A[Vendor Identified] --> B[Classify Vendor Tier]
    B --> C{Critical or High?}
    C -->|Yes| D[Send Security Questionnaire]
    C -->|No| E[Standard Contract Review]
    D --> F[Review Evidence and Certifications]
    F --> G{Risk Acceptable?}
    G -->|No| H[Reject or Require Remediation]
    G -->|Yes| I[Negotiate DPA and Security Clauses]
    H --> D
    I --> J[Onboard Vendor - Grant Scoped Access]
    E --> J
    J --> K[Continuous Monitoring]
    K --> L{Annual Review or Incident?}
    L -->|Review| M[Re-assess Security Questionnaire]
    L -->|Incident| N[Invoke Incident Response Plan]
    M --> G
    N --> O{Breach Impacted Our Data?}
    O -->|Yes| P[Notify Affected Users and Regulators]
    O -->|No| K
    P --> K
    K --> Q[Contract End - Offboarding]
    Q --> R[Revoke Access and Rotate Secrets]
    R --> S[Confirm Data Deletion in Writing]
    S --> T[Archive Vendor File]

    style A fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style D fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style F fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style G fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style H fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style I fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style J fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style K fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style L fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style M fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style N fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style O fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style P fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style Q fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    style R fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style S fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
    style T fill:#1e3d2f,stroke:#10B981,color:#e2e8f0

Vendor Risk Distribution — Where the Exposure Lives

pie title Vendor Risk Tier Distribution for Typical Indian SMB
    "Critical - Core SaaS and Cloud" : 15
    "High - Data-Adjacent Vendors" : 25
    "Medium - Operational Tools" : 35
    "Low - No Data Access" : 25

Most Indian SMBs discover that 15–20% of their vendor relationships are Critical-tier — yet these receive the least formal scrutiny. The pie above reflects a typical profile: a small number of Critical vendors carrying enormous risk, surrounded by a long tail of lower-risk relationships.

DPDP Act 2023 — What "Data Processor" Obligations Actually Mean

The Digital Personal Data Protection Act 2023 introduces a two-party model for data handling:

1. Data Fiduciary: The entity that determines the purpose and means of processing personal data. This is typically your organisation — the company that collected the data from users.
2. Data Processor: Any third party that processes personal data on behalf of, and under the instructions of, the Data Fiduciary. This includes cloud providers, SaaS vendors, analytics platforms, HR software providers, and contractors handling personal data.

You cannot outsource accountability. As Data Fiduciary, you are responsible for ensuring your Data Processors maintain adequate security safeguards. If a vendor is breached and your users' data is exposed, you face the regulatory consequence — not just the vendor.

You must have a contract. DPDP requires that processing by a Data Processor be governed by a valid contract. A DPA is not optional for any vendor touching personal data. The contract must specify the purpose, the data types, and the security obligations.

Breach notification flows through you. When a vendor (Data Processor) experiences a breach affecting your users' data, you as the Data Fiduciary are required to notify the Data Protection Board of India. The DPDP Act 2023 requires prompt notification — your vendor contract must include a clause requiring the vendor to notify you rapidly so you can meet your own regulatory timeline.

Subprocessors must be controlled. If your vendor engages sub-vendors who touch your users' data, you need visibility into those subprocessors and the right to approve or reject them. This is a contractual requirement you must negotiate.

The DPDP Act 2023 text is published by MeitY and the Data Protection Board of India will be the enforcement authority once fully notified. For detailed DPDP compliance guidance specific to your organisation, see the /dpdp-compliance page.

How to Assess a Vendor's Security Posture

A vendor questionnaire is a starting point, not the end. Here is a structured approach to actually understanding whether a vendor's security posture is adequate:

Certifications and Third-Party Attestations

Ask for current certificates, not past ones. ISO 27001 certification must be current (certificate expiry date on the document). SOC 2 Type II reports cover a defined audit period — a report that is more than 18 months old tells you little about the vendor's current state.

Acceptable attestations for Critical vendors:

1. ISO 27001:2022 (information security management) — see ISO 27001 overview
2. SOC 2 Type II (security, availability, confidentiality)
3. PCI-DSS Level 1 (if handling card data)
4. CERT-In empanelled VAPT attestation letter (for Indian-hosted infrastructure)

Penetration Testing Evidence

Ask: "Has your externally accessible infrastructure been penetration tested in the last 12 months by an independent third party?" Request the attestation letter or executive summary. You do not need the full report — you need confirmation that the test was done, by whom, when, and what the remediation status of critical findings is.

If a vendor cannot provide any evidence of external VAPT, that is a significant red flag for a Critical-tier vendor. A free VAPT scan can also give you a quick first-pass view of a vendor's externally exposed attack surface before you engage deeply.

Incident History

Ask vendors directly: "Have you experienced a security incident in the last two years that resulted in unauthorised access to customer data?" A vendor that has experienced an incident and handled it well — with detection, containment, customer notification, and documented remediation — is often more trustworthy than a vendor that claims a perfect record. Assess the response, not just the incident.

Architecture Review

For Critical vendors, request a high-level architecture diagram. You want to understand:

1. Where your data is stored and in which regions
2. How data is encrypted (at rest: AES-256 minimum; in transit: TLS 1.2+ minimum)
3. Who within the vendor organisation has access to your data
4. Whether the vendor environment is multi-tenant and how tenant isolation is enforced

Starting TPRM Without a Dedicated Team

For Indian SMBs — especially those without a full-time security team — TPRM can feel like an enterprise programme that does not scale to their reality. It does not have to be complex to be effective.

Practical starting point for a company with 10–50 vendors:

1. Week 1: Build the vendor inventory in a spreadsheet. One row per vendor, columns for: tier, data access type, contract expiry, certification status, last review date.
2. Week 2: Identify your Critical-tier vendors (usually 3–8 for an SMB). Send them the security questionnaire.
3. Week 3–4: Review responses. Flag gaps. Escalate to your legal counsel to insert DPA and security clauses at the next contract renewal.
4. Month 2 onwards: Set up annual review reminders. Subscribe to breach disclosure alerts for your top vendors. Build offboarding runbooks for your top 5 Critical vendors.

Bachao.AI automates the security assessment layer — scanning vendor-facing infrastructure to give you an objective view of a vendor's externally exposed vulnerabilities. Dhisattva AI Pvt Ltd built this specifically for Indian organisations that need VAPT-grade intelligence without the cost and timeline of a traditional audit engagement.