Vendor risk management is the process of assessing, contracting, and monitoring the cybersecurity posture of every SaaS provider, contractor, and outsourcing partner that touches your data or systems — before you sign, and for as long as the relationship lasts. For Indian SMBs, this means tiering vendors by data sensitivity, collecting evidence like SOC 2 or ISO 27001 reports, embedding DPDP-compliant data-processing terms into contracts, and monitoring access continuously instead of trusting a one-time questionnaire.
Most SMBs skip this entirely. They onboard a payroll SaaS, a marketing automation tool, or a freelance developer on a handshake and an NDA template, hand over admin access or customer data, and never look at the vendor's security posture again. That gap is exactly where a growing share of breaches originate — not through your own front door, but through a vendor's unpatched server, leaked API key, or ex-employee's still-active login.
Why Third-Party Risk Is Now a Board-Level Issue
Every SaaS subscription, payment gateway, cloud host, logistics partner, and outsourced dev shop is a door into your systems. Some of those doors are wide open by design — a CRM vendor has your customer list, a payroll processor has employee bank details and PAN numbers, an IT managed-service provider has domain admin credentials. If any of them gets breached, the blast radius lands on you, your customers, and — under the Digital Personal Data Protection (DPDP) Act, 2023 — your compliance obligations, regardless of whose server actually leaked the data.
The DPDP Act treats the "Data Fiduciary" (you, the business collecting customer data) as accountable for how that data is processed, even when a "Data Processor" (your vendor) is doing the actual processing. You cannot outsource the liability, only the labor. That single fact is why vendor risk management has moved from an IT checklist item to a board-level compliance requirement.
Step 1: Build a Risk Tier, Not a Single Checklist
Not every vendor needs the same scrutiny. A stock-photo subscription and your core banking API integration do not carry the same risk, and treating them identically wastes time on the low-risk vendors while under-scrutinizing the ones that matter. A simple three-tier model works for most SMBs:
| Tier | Example vendors | Data/access exposure | Assessment depth |
|---|---|---|---|
| Tier 1 — Critical | Payment gateway, cloud host, IT/MSP, HR/payroll SaaS, core dev contractors | Full customer PII, financial data, or privileged system access | Full questionnaire + evidence review + contract clauses + annual re-assessment |
| Tier 2 — Significant | CRM, marketing automation, analytics, ticketing tools | Partial customer data, limited integrations | Lightweight questionnaire + evidence request + standard DPA clause |
| Tier 3 — Low | Design tools, stock assets, non-integrated SaaS | No customer data, no system access | Standard terms review only, no ongoing monitoring |
Step 2: Ask the Right Questions Before You Sign
A security questionnaire doesn't need to be fifty pages to be useful. For an Indian SMB, the essentials cluster around five areas: data handling, access control, incident history, subcontracting, and compliance posture.
Core questions worth asking every Tier 1 and Tier 2 vendor:
- Where is our data physically stored and processed — which country, which cloud region?
- Is data encrypted at rest and in transit? What encryption standard?
- Do you have a documented incident response plan, and have you had a breach in the last 24 months?
- Who at your organization has access to our data, and is that access role-based and logged?
- Do you subcontract any part of the service to a fourth party, and if so, who?
- Do you hold a current SOC 2 Type II report, ISO/IEC 27001 certification, or an independent VAPT report from the last 12 months?
- What is your data retention and deletion policy once the contract ends?
- Do you support a written Data Processing Agreement compliant with the DPDP Act?
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanStep 3: Evidence — What SOC 2, ISO 27001, and VAPT Reports Actually Tell You
Certifications are shortcuts, not guarantees, and it helps to know what each one actually covers before you accept it as proof.
- SOC 2 Type II is an American Institute of CPAs (AICPA) attestation that a vendor's controls — around security, availability, confidentiality, or privacy — operated effectively over a defined period, typically six to twelve months. It's strong evidence of operational maturity for SaaS vendors, but check the report's scope: some vendors only get Type II coverage for part of their infrastructure.
- ISO/IEC 27001 certification confirms a vendor runs a certified Information Security Management System (ISMS). Check the certificate's scope statement and expiry date — an ISO 27001 certificate scoped only to "customer support operations" doesn't tell you anything about the engineering environment that actually touches your data.
- VAPT (Vulnerability Assessment and Penetration Testing) reports are point-in-time technical evidence that a vendor's specific application or infrastructure was tested for exploitable weaknesses. Ask for the report date (anything older than 12 months is stale), the scope tested, and whether critical findings were remediated and re-verified.
None of these replace your own judgment. A vendor can be SOC 2 certified and still have a misconfigured S3 bucket outside the audit's scope. Evidence review narrows risk; it doesn't eliminate it.
Step 4: Contract Terms That Actually Protect You
Security questionnaires are diagnostic. Contracts are enforcement. For Indian SMBs, the contract with any vendor touching personal data should include, at minimum:
- A DPDP-compliant Data Processing Agreement (DPA) — defining the vendor as a Data Processor, specifying the purpose and scope of processing, and prohibiting use of data beyond that scope.
- Breach notification timelines — a contractual obligation for the vendor to notify you within a fixed, short window (commonly 24–72 hours) of discovering an incident, so you can meet your own regulatory notification duties.
- Right-to-audit clause — your ability to request evidence, run a security review, or commission an independent assessment during the contract term.
- Subcontracting/fourth-party disclosure — the vendor must disclose and get approval before adding subcontractors who will touch your data.
- Data return and deletion on termination — a defined process and timeline for the vendor to return or verifiably delete your data once the relationship ends.
- Liability and indemnification — clarity on which party bears cost if the vendor's negligence causes a breach affecting your customers.
Step 5: Continuous Monitoring — Don't Stop at Onboarding
A vendor assessed as low-risk at signing can drift. Staff turnover, an infrastructure migration, a new subcontractor, or a missed certification renewal can all change a vendor's risk profile without you noticing — unless monitoring is built into the relationship, not treated as a one-time gate.
Practical continuous monitoring for an SMB, scaled to your team size:
- Annual re-assessment for Tier 1 vendors — re-send the questionnaire, re-check certification validity and VAPT report freshness.
- Access reviews every quarter — confirm the vendor's active users/API keys against your system still match who should have access. Revoke immediately for role changes or offboarded vendor staff.
- Breach and news monitoring — track public disclosures for your Tier 1 vendors; a vendor breach reported publicly should trigger your own incident response check, not wait for their notification.
- Renewal-linked review — tie the security re-assessment to the contract renewal date so it's never skipped for lack of a trigger.
Step 6: Offboarding — The Step Everyone Skips
Vendor risk doesn't end when the contract ends — it often peaks right there. An ex-vendor with lingering admin access, an unrevoked API key, or a copy of your data sitting on their servers after the engagement is a live liability with no active relationship managing it.
A proper offboarding checklist should cover:
| Offboarding step | Why it matters |
|---|---|
| Revoke all system access and API keys | Prevents unauthorized access post-termination |
| Confirm data return or certified deletion | Closes the DPDP data-minimization obligation |
| Remove vendor contacts from internal systems and shared drives | Closes informal access paths outside the main integration |
| Update your vendor inventory/register | Keeps your risk-tier list accurate for audits |
| Document the offboarding for compliance records | Evidence for DPDP accountability and future audits |
How Big Is the Third-Party Risk Problem, Really?
Third-party and supply-chain involvement in breaches has been rising industry-wide for several years. Verizon's 2025 Data Breach Investigations Report found third-party involvement in roughly 30% of breaches — about double the share it measured the year before — and the direction is consistent across independent research: attackers increasingly find it easier to compromise a smaller, less-scrutinised vendor than to breach a well-defended primary target directly.
Building a Vendor Risk Management Program That Fits an SMB
You don't need a dedicated third-party risk team to run this well. Start with a spreadsheet: list every vendor, tier them by data/access exposure, and set a review cadence for Tier 1 and Tier 2. Add the DPA clauses to your standard contract template so every new vendor gets them by default instead of relying on someone remembering to ask. Run a periodic technical check — an automated scan or a free VAPT scan — on the systems and integrations that connect to your critical vendors, since your own exposed endpoints are often the easiest path into a vendor relationship.
Bachao.AI's platform, built by Dhisattva AI Pvt Ltd, helps Indian SMBs run continuous automated vulnerability assessments on their own infrastructure — a useful complement to vendor-side evidence review, since a hardened perimeter on your end limits how much damage a compromised vendor integration can actually do. For deeper reading on the regulatory side of vendor accountability, MeitY's official DPDP resources (meity.gov.in) and CERT-In's advisories (cert-in.org.in) are the primary sources worth bookmarking. For more on meeting India's data protection obligations end-to-end, see our DPDP compliance guide.
Vendor risk isn't a one-time gate you clear before signing a contract — it's a standing discipline that scales with how much access and data you hand out. Indian SMBs that build even a lightweight version of this process — tiering, evidence, contract clauses, monitoring, and clean offboarding — close one of the most exploited and least examined gaps in their security posture.