How to Build an Effective Third-Party Risk Monitoring Program

Why One-Time Vendor Assessment is Not Third Party Risk Management

Most regulated enterprises in India treat vendor onboarding as the finish line. A detailed questionnaire goes out, due diligence reports come back, the risk team signs off, and the vendor enters the ecosystem. From that point forward, the assumption is that the vendor’s risk profile remains static. This assumption is where third party risk monitoring fundamentally breaks down.

The reality is that a vendor’s risk posture on Day 1 has almost no correlation with their risk posture on Day 365. Security configurations drift, financial health fluctuates, regulatory statuses change, sub-contractors get added. Without continuous monitoring, you are making risk decisions based on stale information, and regulators across BFSI, pharma, and healthcare are increasingly unwilling to accept that approach.

Assessment vs. Monitoring: A Structural Difference

A vendor risk assessment is a point-in-time evaluation. It captures a snapshot of a third party’s controls, certifications, financial standing, and compliance posture at a specific moment. It answers the question: “Is this vendor acceptable to onboard today?”

Third party risk monitoring, by contrast, is an ongoing discipline. It answers a different question entirely: “Does this vendor continue to meet the risk thresholds we set when we onboarded them?” The distinction matters because the answer to the second question changes continuously, often without any notification to the regulated enterprise relying on that vendor.

Consider a mid-sized NBFC that onboarded a cloud infrastructure provider after a thorough assessment in 2022. The provider met all RBI outsourcing guidelines, demonstrated ISO 27001 certification, and showed strong financials. Eighteen months later, the provider quietly lost a key certification, experienced a data breach affecting another client, and changed ownership structure through a private equity acquisition. Without active monitoring, the NBFC’s risk register still shows a “low risk” classification for a vendor whose actual risk profile has materially changed.

For a detailed breakdown of what initial assessments should cover, refer to our guide on vendor risk assessment in BFSI. The point here is that even the most thorough initial assessment has a shelf life.

What Changes After Onboarding

The factors that shift a vendor’s risk profile post-onboarding fall into several categories, each with its own velocity of change and detection difficulty.

Security Posture Drift

A vendor’s cybersecurity controls are not static artifacts. Patching cadences slip, staff turnover leads to configuration errors, new attack surfaces emerge as the vendor adopts new technologies or expands services. The SOC 2 Type II report you received during onboarding reflects audit period controls, not current-state controls. Between audit cycles, significant degradation can occur without any external visibility.

CERT-In’s 2022 directives on incident reporting timelines (6 hours for certain categories) added another dimension. A vendor who suffers a reportable incident and fails to notify CERT-In within prescribed timelines creates regulatory exposure for every regulated entity in their client base, regardless of whether the incident directly affected those clients’ data.

Financial Health Deterioration

Vendor insolvency or financial distress is a concentration risk that many Indian enterprises underestimate. When a critical technology vendor enters financial difficulty, service continuity becomes uncertain, key personnel leave, and investment in security controls typically drops. For BFSI entities subject to RBI’s Business Continuity Management guidelines, this creates a direct compliance gap if the vendor provides services classified as critical or material.

Regulatory and Legal Status Changes

Vendors operating in regulated sectors face their own compliance obligations. A payment aggregator losing its RBI authorization, a data processor failing to register under DPDP Act requirements, a pharma contract manufacturer receiving FDA warning letters: these events fundamentally alter the risk calculus for downstream entities relying on those vendors.

Subcontracting and Fourth-Party Risk

Perhaps the most opaque area of post-onboarding change is fourth-party risk. Your vendor subcontracts a portion of service delivery to another entity whose controls you have never assessed. RBI’s Master Direction on Outsourcing of Information Technology Services explicitly requires that outsourcing agreements address sub-contracting, yet monitoring whether vendors actually comply with sub-contracting restrictions requires ongoing vigilance, not a one-time contractual clause.

What Indian Regulators Expect on Third Party Risk Monitoring

The regulatory expectation across Indian financial services, insurance, and capital markets is unambiguous: ongoing monitoring is not optional. The specific requirements vary by regulator, but the direction is consistent.

RBI’s framework is particularly prescriptive. The Master Direction on Outsourcing explicitly states that regulated entities cannot outsource the management responsibility for risk, even when they outsource the activity itself. This means a bank cannot argue that monitoring vendor risk is the vendor’s own responsibility. The obligation sits with the regulated entity, permanently.

SEBI’s CSCRF adds another layer for market infrastructure institutions and intermediaries. The framework expects that third-party risk assessments are not one-time events but part of a continuous assurance cycle. For stock brokers, depositories, and mutual fund AMCs, this translates into periodic evidence collection from vendors, not just annual questionnaire refreshes.

Building a Continuous Vendor Monitoring Process

Moving from point-in-time assessment to continuous third party risk monitoring requires structural changes in how risk teams operate. It demands three foundational capabilities: automated signal detection, risk-tiered monitoring cadences, and evidence-based escalation workflows.

Risk-Tiered Monitoring Cadences

Not every vendor warrants the same monitoring intensity. A critical payment processing partner handling lakhs of transactions daily requires fundamentally different oversight than a facilities management vendor. The monitoring cadence should reflect the vendor’s risk tier, which itself should be determined by factors including data sensitivity, transaction criticality, replaceability, and regulatory classification.

For most regulated enterprises, a three-tier model works effectively. Tier 1 (critical/material vendors) receives quarterly monitoring reviews with monthly automated signal checks. Tier 2 (significant vendors) receives semi-annual reviews with quarterly signal checks. Tier 3 (standard vendors) receives annual reviews with automated alerts on material changes.

This tiered approach allows risk teams to allocate finite capacity where it matters most, without leaving any vendor entirely unmonitored. The challenge, of course, is operationalizing this across hundreds or thousands of vendors. This is precisely where platforms like eQomply provide structural support, enabling risk teams to configure monitoring frequencies by vendor tier, automate evidence collection requests, and track completion rates without relying on manual follow-ups and spreadsheet trackers.

Automated Signal Detection

Continuous monitoring does not mean a human analyst reviews every vendor every day. It means establishing automated detection mechanisms that surface material changes requiring attention. These signals include financial filing anomalies, news alerts on litigation or regulatory action, certificate expiry notifications, SLA breach patterns, and incident reports.

The challenge for Indian enterprises is that many of these signals exist in disparate, unstructured sources: MCA filings, court records, CERT-In advisories, vendor self-disclosures, and industry forums. Consolidating these into a single risk view per vendor is operationally complex without purpose-built infrastructure.

Evidence-Based Escalation

When a monitoring signal fires, the response needs to be structured, not ad-hoc. A robust monitoring process defines clear escalation paths: what constitutes an informational signal versus one requiring immediate re-assessment, who owns the response, what evidence needs to be collected, and what timeline applies.

Consider an insurance company regulated by IRDAI that detects a news report about its claims processing vendor facing a ransomware attack. The monitoring process should automatically trigger a workflow: notify the vendor relationship owner, request incident details from the vendor, assess data exposure, evaluate whether IRDAI notification obligations are triggered, and document all actions taken with timestamps. Doing this manually, across email chains and shared drives, creates gaps that become audit findings.

Triggers for Re-Assessment

Continuous monitoring exists on a spectrum. At one end is passive signal detection. At the other end is full re-assessment, essentially repeating the initial due diligence process. Understanding what triggers a move from monitoring to re-assessment is critical for resource planning and regulatory defensibility.

Event-Driven Triggers

Certain events should automatically trigger a comprehensive re-assessment regardless of where the vendor sits in its regular monitoring cycle. These include confirmed data breaches affecting the vendor, material changes in vendor ownership or corporate structure, loss of regulatory licenses or key certifications, litigation or enforcement action by a regulator, vendor entering insolvency or corporate debt restructuring, and discovery of unauthorized sub-contracting.

For a capital markets intermediary regulated by SEBI, learning that a technology vendor providing order management systems has lost its ISO 27001 certification is not something that can wait for the next scheduled quarterly review. It requires immediate re-assessment because it potentially affects the entity’s own SEBI compliance posture.

Time-Based Triggers

Even in the absence of event-driven signals, regulators expect periodic full re-assessments. RBI’s outsourcing guidelines reference annual reviews of material outsourcing arrangements. IRDAI expects periodic audits of IT service providers. These time-based triggers ensure that even “quiet” vendors, those generating no adverse signals, receive fresh due diligence at defined intervals.

Threshold-Based Triggers

A third category of trigger relates to cumulative risk score degradation. Individual monitoring signals may not independently warrant re-assessment, but their accumulation over time might. Three minor SLA breaches in a quarter, combined with delayed responses to evidence requests and a slight downgrade in financial ratings, may collectively push a vendor past a risk threshold that triggers full re-assessment.

Implementing threshold-based triggers requires a scoring mechanism that aggregates signals over time, something that is nearly impossible to maintain accurately in spreadsheet-based vendor management systems. This is where a structured GRC platform adds material value, maintaining running risk scores per vendor and automatically flagging when aggregate thresholds are breached. eQomply’s risk management capabilities, including its unified risk register and configurable scoring methodology, are designed to support exactly this kind of continuous, evidence-backed vendor risk governance.

The Cost of Not Monitoring

The consequences of treating assessment as a one-time exercise are not theoretical. In 2023, RBI’s supervisory actions against multiple banks and NBFCs specifically cited deficiencies in ongoing vendor oversight. SEBI’s cybersecurity inspections have flagged entities that could demonstrate initial vendor assessments but not ongoing monitoring evidence. The pattern is clear: regulators are moving beyond asking “did you assess this vendor?” to asking “show us your monitoring trail for the past 12 months.”

Beyond regulatory exposure, the operational risks are significant. A critical vendor failure without early warning creates crisis-mode responses, board-level escalations, and potential customer impact. Early detection through monitoring converts potential crises into managed transitions, whether that means activating exit clauses, onboarding alternate vendors, or working with the existing vendor on remediation.

Operationalizing What Regulators Already Expect

Third party risk monitoring is not a new regulatory concept. RBI, SEBI, IRDAI, and CERT-In have all been directionally consistent for years: regulated entities must maintain ongoing visibility into their vendor ecosystem. What has changed is the specificity of expectations and the willingness of regulators to cite monitoring gaps in supervisory findings.

For compliance leaders and risk officers at regulated Indian enterprises, the path forward requires moving from periodic, questionnaire-driven vendor reviews to structured, evidence-based continuous monitoring supported by appropriate technology infrastructure. The volume of vendors, the velocity of change, and the granularity of regulatory expectations make manual approaches untenable at scale.

If your organization is still treating the initial vendor assessment as the primary risk management activity, you have a structural gap that will eventually surface, either through a vendor incident or a regulatory observation. Building the monitoring muscle now, with clear tiering, defined triggers, and automated evidence collection, is both a compliance imperative and an operational advantage. If you are evaluating how to build this capability into your existing risk governance framework, a conversation with our team can help you map what continuous vendor monitoring looks like for your specific regulatory context.