Short Summary
A vendor that passed its assessment in January can be breached, acquired or out of business by June, so enterprises need to watch third parties continuously. With third parties involved in 48% of breaches in Verizon’s 2026 DBIR (Security Magazine), the gap between reviews is where most risk now lives.
This guide covers the ten signal categories to track, how to prioritise alerts and respond, how monitoring meets ongoing-oversight duties under DORA, ISO 27001, PCI DSS, RBI and the DPDP Act, and four worked incidents.
The problem
Most programmes assess vendors at onboarding and again every 12 to 24 months, assuming risk stays still in between. It does not. In one year a SaaS vendor may add an AI subprocessor abroad, have an engineer’s admin credentials stolen by infostealer malware, let its SOC 2 report lapse, be acquired, or breach your SLA repeatedly.
Annual reviews miss these for three reasons:
- Evidence ages immediately. A SOC 2 report describes a past period; a questionnaire describes one day.
- Attacks move fast. Leaked credentials can be used within hours of appearing for sale.
- Scope drifts silently. Business teams add data and integrations to approved vendors without telling the risk team.
Teams that try to monitor often drown in alerts that lack context (is this vendor critical? does it hold our data?), spread across separate tools, with no playbook for what happens next. Good monitoring fixes all three: the right signals, joined to vendor context, with a defined response.
Why it matters
Third-party involvement in breaches rose from about 15% (2024 DBIR) to 30% (2025) and 48% (2026) (Tenchi Security, Verizon). And vendors fix weaknesses slowly, according to the 2026 DBIR (Axonius, SpyCloud):
| 2026 DBIR finding | What it means for monitoring |
|---|---|
| Only 23% of third parties fully fixed missing cloud MFA | Keep checking after a vendor promises a fix |
| Weak passwords and permission issues took a median of nearly 8 months to fix | Track how long vendor findings stay open |
| Most high-profile third-party cloud incidents came from weak authentication | Watch leaked credentials, token scopes and vendor access |
Incidents such as the 2025 Salesloft Drift OAuth token theft showed that customers who knew their integrations could revoke tokens within hours. Regulators also now expect ongoing oversight: DORA requires lifecycle monitoring of ICT providers, ISO 27001 control 5.22 requires regular supplier review, and PCI DSS 12.8.4 requires at least annual checks of service providers’ compliance.
Technical explanation
Continuous third-party monitoring is a pipeline: collect signals about each vendor, join them to what you know about the relationship, score whether the risk has changed, and route each change to a defined response. Its value comes from the join, not the feeds.
Continuous monitoring pipeline · sources, context, scoring, response
Raw feeds on the left are only noise until the shaded step attaches tier, data, access and contract context; every outcome then flows back into the vendor’s record.
What to track: ten signal categories
| # | Signal | What to track | Alert when |
|---|---|---|---|
| 1 | Cyber posture | Exposed services, unpatched internet-facing software, TLS and email security | Critical CVE on a vendor asset; rating drops sharply |
| 2 | Credential exposure | Vendor staff credentials in infostealer logs, leaked API keys | Credentials for a vendor with access to you appear |
| 3 | Breach intelligence | Breach disclosures, ransomware leak sites, regulator notices | The vendor is named in a breach |
| 4 | Evidence freshness | SOC 2, ISO 27001, PCI AOC and pen test dates and scope | Critical evidence expires or shows exceptions |
| 5 | Access and integrations | Vendor accounts, OAuth scopes, API key age, dormant accounts | New high-privilege scope; account unused 90 days |
| 6 | Fourth parties and location | Subprocessor lists, hosting regions | New subprocessor for your data or an unapproved country |
| 7 | Operational performance | Uptime, SLA breaches, outages | Repeated SLA breaches on a critical service |
| 8 | Financial health | Credit rating, layoffs, late filings | Downgrade or insolvency signals |
| 9 | Legal and sanctions | Sanctions, litigation, change of control | Sanctions match or acquisition by a restricted party |
| 10 | AI and data use | AI features, model training terms | Terms allow training on your data by default |
Match intensity to tier: Tier 1 vendors get all ten with real-time alerts, Tier 2 most of them, and Tiers 3 and 4 only breach, evidence and sanctions screening. Every alert must be joined to the vendor record (tier, data held, access, contract terms, open findings), or analysts cannot tell which alerts matter.
Prioritise and respond
\text{Alert priority} = \text{Signal severity} \times \text{Tier weight} \times \text{Exposure factor}
Severity runs 1 to 5, tier weight 4 (Tier 1) to 1 (Tier 4), and exposure is 1.5 if the vendor holds sensitive data or privileged access, otherwise 1.
| Score | Level | Response target |
|---|---|---|
| 20+ | P1 | Contact vendor and contain within 4 hours |
| 10–19 | P2 | Vendor response within 2 business days |
| 5–9 | P3 | Next monthly review |
| Below 5 | P4 | Trend analysis only |
A confirmed breach at a Tier 1 vendor holding customer data scores 5 × 4 × 1.5 = 30 (P1); the same breach at a Tier 3 vendor with no sensitive data scores 10 (P2).
For P1 and P2 alerts, run a predefined playbook: confirm with the vendor’s named security contact, scope your exposure from the vendor record, contain by rotating credentials and revoking tokens, assess notification duties (CERT-In within 6 hours, DPDP, GDPR within 72 hours, DORA), track remediation and reassess the vendor.
Compliance impact
Regulators increasingly treat vendor oversight as a duty that lasts the whole relationship, and continuous monitoring produces the dated evidence that proves it.
| Framework | Ongoing-monitoring expectation |
|---|---|
| EU DORA | Lifecycle monitoring of ICT providers, current register of information, concentration risk, incident reporting |
| EU NIS2 | Supply chain security under Article 21 with management oversight |
| ISO 27001:2022 | Control 5.22: monitor, review and manage changes in supplier security and service delivery |
| SOC 2 | CC9.2: ongoing vendor risk management |
| PCI DSS v4.0 | 12.8.4: check service providers' PCI DSS status at least every 12 months |
| GDPR and India DPDP Act | Processor oversight, subprocessor control, breach notification |
| CERT-In Directions (2022) | Report specified incidents within 6 hours |
| RBI IT Outsourcing Directions and SEBI CSCRF | Ongoing monitoring of service provider performance, risk and controls |
When an auditor asks “how do you know your critical vendors are still secure?”, the strong answer is a monthly posture trend, an evidence-expiry tracker and a timestamped alert log, not “we assessed them last year”.
This is a summary for awareness, not legal advice.
Example use cases
These four scenarios are illustrative composites of common real-world patterns.
Use case 1: Leaked credentials at a payroll provider
A Pune manufacturer’s Tier 1 payroll provider has support access to its payroll tenant. At 09:10, the credential feed flags a support engineer’s password and session cookie in an infostealer log. Priority: 4 × 4 × 1.5 = 24 (P1).
By 09:40 the SOC had suspended the provider’s support access; by 10:15 the vendor confirmed the infected laptop and revoked the engineer’s sessions; by 13:00 a log review found no unusual exports. Access was restored two days later with phishing-resistant MFA and just-in-time approval. Lesson: without credential monitoring, the company would have learned of this only if the vendor chose to disclose it.
Use case 2: Concentration risk exposed by outages
An online retailer ran its storefront, payment page and login through one delivery and security provider, each rated Tier 2. Three outages in six weeks, one during a festive sale, scored 13.5 (P2), but the concentration view showed one provider behind three critical services. The retailer re-tiered it to Tier 1 and added a tested failover provider for payments. Lesson: track which critical services share a provider.
Use case 3: A CRM vendor adds an AI subprocessor
An insurance broker’s CRM vendor added a US-based language-model provider and switched on AI summaries by default. The notice went to an unread mailbox, but monitoring caught the subprocessor list change the same day (13.5, P2). The DPO reviewed it within the 30-day objection window, disabled the feature, secured a no-training commitment and updated GDPR and DPDP records before piloting it. Lesson: terms and subprocessor changes are risk events.
Use case 4: Financial distress at a managed IT provider
A hospital chain’s Tier 1 managed service provider showed layoffs (month 1), a credit downgrade and late filings (month 2), then doubled ticket times and missed patch cycles (month 3). No single signal was alarming, but the trend was. The hospital secured admin credentials and runbooks, moved privileged access to its own tooling and ran a tender. When the provider entered insolvency four months later, the hospital switched suppliers in three weeks without service loss. Lesson: watch trends, not just alerts.
Continuous monitoring checklist
Tick an item only when you can show evidence.
Foundations
- ☐ One vendor record holds tier, data, access, contract terms and open findings
- ☐ Monitoring intensity is defined per tier
- ☐ Contracts require prompt notice of incidents, subprocessor and material changes
Signals
- ☐ External posture and critical CVEs monitored for Tier 1 and 2 vendors
- ☐ Credential, leaked-key and breach intelligence covers vendors with access to you
- ☐ Evidence expiry alerts fire 60 days before SOC 2, ISO or PCI documents lapse
- ☐ Vendor accounts and OAuth scopes reviewed; tokens unused for 90 days disabled
- ☐ Subprocessor, data location, terms and AI feature changes tracked
- ☐ SLA performance, concentration, financial health and sanctions monitored
Response and reporting
- ☐ Alerts prioritised by severity, tier and exposure, with P1/P2 response targets
- ☐ A third-party incident playbook names owners and maps notification duties
- ☐ You can suspend a vendor’s access within one hour
- ☐ Major events trigger out-of-cycle reassessment and tracked remediation
- ☐ Leadership sees critical vendor trends and concentration risk at least quarterly
- ☐ Monitoring records are retained as audit evidence
How ServQual and SUSAN help
Monitoring fails when vendor signals, evidence and remediation live in separate tools. SUSAN, ServQual’s AI-driven cybersecurity, privacy and GRC platform, joins them in one continuous assurance workflow.
- SUSAN Third-Party Risk holds the vendor record every alert needs (owner, data, access, risk rating, evidence) and tracks reassessment triggers such as new access, new subprocessors, incidents and expired evidence.
- SUSAN Continuous Monitoring & Evidence tracks evidence freshness, maps evidence to controls and frameworks, connects SIEM, EDR and XDR signals to GRC workflows, and assigns remediation owners.
- Connected modules such as AI Risk Scoring, DPDP Compliance and the Unified GRC Dashboard cover AI vendors, processor obligations and leadership reporting.
ServQual’s Managed SOC team can triage third-party alerts and run the incident playbook, while its ISO 27001, SOC 2, DORA, NIS2 and DPDP services turn monitoring records into audit-ready evidence. In use case 1, SUSAN would instantly show the payroll provider’s tier, data and access, link the alert to that record, and track the vendor’s fix to closure.
“Third-party risk does not stand still between annual assessments. Continuous monitoring turns vendor changes into actionable risk signals before they become incidents.”
Jayesh Thakkar
Product Manager | ServQual
FAQ
Most frequent questions and answers
No. Periodic assessments examine vendor controls in depth, while continuous monitoring identifies when risk changes and when an out-of-cycle reassessment is needed.
Enterprises should monitor cyber posture, leaked credentials, breach intelligence, evidence freshness, vendor access, fourth parties, operational performance, financial health, sanctions and legal changes, and AI/data-use changes.
No. Security ratings show only part of the external posture. They do not provide complete visibility into internal controls, integrations, subprocessors, financial condition or contract obligations.
Monitoring should be scaled according to vendor tier, alerts should be joined to vendor context, and priority should consider severity, tier and exposure. Lower-priority findings can be handled through periodic review rather than immediate escalation.
Examples include confirmed breaches, leaked vendor credentials, new privileged access, critical vulnerabilities, significant evidence expiry, unapproved subprocessors, sanctions matches or material operational failures.
For high-priority alerts, enterprises should confirm the event with the vendor, determine exposure, revoke or rotate access where necessary, assess notification duties, track remediation and perform an out-of-cycle reassessment.
Useful evidence includes posture trends, evidence-expiry records, timestamped alerts, vendor access reviews, subprocessor changes, remediation status and incident-response records.
SUSAN Third-Party Risk maintains vendor context such as ownership, data, access, risk rating and evidence, while Continuous Monitoring & Evidence tracks freshness, maps evidence to controls and assigns remediation ownership.
Move Beyond Annual Vendor Reviews
Track changing vendor risk, evidence freshness, access, incidents and remediation continuously with ServQual and SUSAN.
Disclaimer: This article is provided for general Third-Party Risk Management and Cybersecurity guidance. Monitoring requirements, response priorities and regulatory obligations depend on vendor criticality, contractual terms, data exposure, jurisdiction and applicable regulatory requirements.
