Third-Party and Vendor Security Assessments: Managing Supply-Chain Risk Beyond the Questionnaire
The 2020 SolarWinds breach, the 2021 Kaseya ransomware attack, and a series of Indian BFSI incidents involving compromised third-party integrations have made supply-chain and vendor risk management a board-level conversation. The implicit assumption that the security of your organisation is bounded by your own perimeter is no longer defensible — your attack surface includes every vendor, SaaS application, system integrator, and outsourcing partner that has access to your data, your networks, or your users. Regulatory frameworks have caught up: the RBI's outsourcing guidelines, SEBI's CSCRF vendor risk management requirements, and the DPDP Act 2023's data processor obligations all create formal accountability for third-party risk.
The limits of security questionnaires
The dominant approach to vendor security assessment is the questionnaire: a spreadsheet of 200 to 400 yes/no questions covering IT governance, access management, encryption, incident response, and DR. Questionnaires are useful as a first-pass filter — they surface vendors who have not considered specific control areas — but they have a fundamental structural weakness: they are self-reported. A vendor who does not have a vulnerability management process can still answer "Yes — we have a documented vulnerability management policy" if they drafted one last month. Questionnaire-based programmes effectively measure whether vendors have documentation, not whether their controls work. The log4shell and similar supply chain incidents were predominantly at vendors who would have answered questionnaires positively.
The gap between questionnaire answers and actual security posture is consistently revealed when questionnaire responses are compared to the results of actual technical testing of the same vendor. In our experience, vendors with clean questionnaire responses regularly have critical findings when their applications are actually tested — IDOR vulnerabilities in APIs used by the enterprise buyer, insecure direct database access from vendor support tooling, or credentials stored in plaintext in configuration files accessible to the vendor's support team.
Tiering vendors by risk: right-sizing the assessment depth
Effective vendor risk programmes tier vendors by their risk profile and apply assessment depth proportional to risk. Tier 1 (highest risk) vendors are those with access to the most sensitive data, systems, or networks: cloud infrastructure providers with production access, managed security service providers with SOC access, core banking or ERP platform vendors, payment processors, and identity providers. These vendors merit a full technical assessment — penetration testing of their integration endpoints, review of their security architecture for the services you consume, and review of their SOC 2 or ISO 27001 audit reports. Tier 2 vendors (moderate risk) merit questionnaire plus evidence review — SOC 2 report, ISO 27001 certificate, CERT-In audit report where available. Tier 3 vendors (low risk) can be assessed through questionnaire alone with periodic review.
Technical assessment of vendor integrations
The integration point between an enterprise and its Tier 1 vendor is the most technically assessable attack surface. For a bank integrating with a third-party fraud analytics SaaS, the integration surface includes the API endpoint the bank's core banking system calls, the credentials used for that API call (how are they rotated? how are they stored in the bank's systems?), the data sent to the vendor (is it minimised? is it encrypted in transit with TLS 1.2+ and valid certificate?), and the vendor's access to the bank's production environment (is it narrowly scoped? is it audited and logged?). A targeted penetration test of these integration points — operating as the vendor's API consumer — is the most direct technical assessment of the vendor risk surface.
The DPDP Act creates additional accountability: enterprises acting as data fiduciaries must ensure that their data processors (vendors who process personal data on their behalf) implement comparable technical measures. A vendor relationship that involves processing Indian citizen personal data requires a data processing agreement and technical due diligence. The enterprise cannot simply outsource the data protection obligation to the vendor — it retains accountability for the outcome. Our security services include vendor integration security assessments.
RBI and SEBI outsourcing risk requirements
RBI's Guidelines on Managing Risks and Code of Conduct in Outsourcing of Financial Services by Banks (and the equivalent for NBFCs) require that banks retain oversight of outsourced activities, conduct due diligence before and during outsourcing relationships, and ensure that outsourced vendors meet the same security standards that the bank itself is required to meet. For Tier 1 outsourcing relationships, this means the bank must have a documented assessment of the vendor's security posture, including evidence of penetration testing and IS audit. SEBI's CSCRF requires that Qualified Stock Brokers and MIIs manage third-party cyber risk and include critical vendors in their incident response and BCP planning.
Building a vendor risk programme that scales
A practical vendor risk programme combines a risk tiering model, a questionnaire and evidence review process for Tier 2/3 vendors, and a technical assessment programme for Tier 1 vendors. The technical assessment calendar should be aligned with vendor contract renewal cycles — building assessment requirements into vendor contracts is the most effective governance mechanism. Require Tier 1 vendors to provide annual CERT-In audit reports (for India-regulated vendors), SOC 2 Type II reports (for international SaaS vendors), or to grant the enterprise permission to conduct their own penetration testing of the integration surface.
CyVigilant supports enterprise vendor risk programmes through third-party security assessments and vendor integration penetration testing. To discuss scoping, explore our VAPT services or talk to an expert about your vendor risk programme.
Put this into action.
Book a 30-minute scoping call with a CERT-In empanelled security expert.
Talk to an ExpertMore articles
SEBI CSCRF 2024: A Compliance Roadmap for Stock Brokers and Market Infrastructure Institutions
SEBI CSCRF 2024: VAPT cadence, audit documentation, CERT-In empanelment, and compliance timelines for brokers and MIIs.
May 12, 2026IRDAI Cyber Security Guidelines: What Annual IS Audits and VAPT Mean for Insurers
IRDAI IS audit and VAPT obligations for insurers explained: annual audit scope, CERT-In empanelment, DPDP Act implications, and what regulators examine.
May 12, 2026What CERT-In Empanelment Means for Your Security Audit
CERT-In empanelment explained: what it is, why it matters for RBI/SEBI/IRDAI regulated entities, Safe-to-Host certificates, and what to expect from a compliant audit.
