Vendor risk monitoring tracks each vendor’s risk indicators throughout the relationship so you can confirm its controls still hold. When something changes (a breach, data loss, financial deterioration, a compliance lapse), you can act immediately. You do not need to wait for the next review.
On September 30, 2025, the California Privacy Protection Agency announced that Tractor Supply agreed to pay $1,350,000. One violation was “[d]isclosing personal information to other companies without entering into contracts that contain privacy protections.” The remedies did not stop at paperwork. Tractor Supply must also monitor its own sites. As part of its opt-out remedies, it must scan its digital properties at least quarterly and keep a full, current inventory of tracking technologies (the Board’s order, para 68(a)).
For vendor-risk, privacy, security, and compliance leads, this guide shows what that watching can tell you about a vendor’s handling of your data.
Key takeaways
- Vendor risk monitoring tracks changes after approval and complements periodic assessments.
- No single signal source gives the full picture. Use multiple sources.
- Website and app monitoring reveals where data goes, but not what vendors do internally.
- Regulations vary: some require ongoing oversight, while others rely on contractual safeguards. None explicitly mandates continuous vendor monitoring.
- Review signals as they arrive, reassess vendors by risk tier, and act on trigger events.
- Assign every alert to an owner and record the resulting decision.
What is Continuous vendor risk monitoring?
Continuous vendor risk monitoring is the ongoing, automated process of tracking third-party risk indicators across cybersecurity risks, financial risk, operational risk, compliance risk, and reputational risk throughout the lifespan of a business relationship.
It is the part of a vendor risk management (VRM) program that runs after a vendor is approved. Due diligence and contracting come before it. The guide to third-party privacy risk management covers each stage of the vendor lifecycle.
How It Works
- Automated Data Ingestion: Systems continuously pull live feeds from external sources such as threat intelligence databases, credit rating services, regulatory filings, dark web leak sites, and news outlets.
- Real-Time Alerting: When a risk threshold is crossed (e.g., an expired SSL certificate, a data breach, or a drop in financial health), the system generates automated alerts for your team to investigate.
- Audit Trail Generation: Tools timestamp and log every alert, risk shift, and remediation action taken, supporting compliance requirements (such as DORA or NYDFS Part 500).
How is vendor risk monitoring different from a vendor risk assessment?
An assessment is a dated, mostly vendor-supplied answer to whether a vendor is acceptable, while monitoring watches for the changes that alter that answer. Monitoring lasts as long as the relationship does.
| Vendor risk assessment | Vendor risk monitoring | |
| Timing | Before selection, then at set intervals | Throughout the relationship |
| Question answered | Is this vendor acceptable for this service? | Has anything changed that alters that answer? |
| Evidence source | Mostly the vendor: questionnaires, audit reports such as SOC reports, documents, testing where the risk justifies it | Feeds, notices, your own records, and your own observations |
| Depth | Deep, at one point in time | Broad, and shallow per signal |
| What it misses | Everything that changes after the review date | Whatever no signal source can see, such as security controls inside the vendor |
| Output | A risk rating, a tier, and conditions for approval | Alerts, recorded decisions, and early reassessments |
An annual review is a point-in-time assessment that captures one date. A breach or a financial slide in the middle of the year stays invisible until the next cycle unless something is watching. Breaches through third parties are common. Verizon’s 2026 Data Breach Investigations Report found third-party involvement in 48% of the breaches it analyzed, up from 30% the year before. Its measure includes breaches made possible by a flaw in a vendor’s product.
Between assessments, monitoring can catch material or repeat audit findings, financial deterioration, security breaches, and data loss. You can then escalate and respond promptly.
A vendor risk assessment will of course look at whether the vendor can deliver the service in a safe manner and whether they can meet your obligations. Privacy is one of the elements of that. For the privacy questions, see the guide to third-party privacy risk.
Can continuous monitoring replace periodic vendor risk assessments?
No, not on its own. Monitoring is broad and shallow per signal, so it flags change but does not give an assessment’s depth.
The two work as a loop. Monitoring starts once the vendor is onboarded and measures drift against the baseline and tier that due diligence set. From then on, it checks what questionnaires claimed and decides when the next reassessment comes early.
- Due diligence sets the vendor’s baseline and its risk tier.
- Monitoring watches the vendor’s signals against that baseline.
- A material change opens up a decision point: an early, targeted reassessment or a tier change.
- The reassessment resets the baseline, and monitoring carries on from it.
Which vendor risks should you monitor?
The changes worth watching are the ones that show a vendor’s risk to you has moved, from security incidents and financial condition to strategy, subcontractors, data location and continuity, drawn from more than one kind of source. Each source sees only one slice.
Risk factors to track include:
- security incidents, new threats and vulnerabilities, and how the vendor responds to them
- changes in financial condition, and changes to or lapses in insurance cover
- audits, testing results and compliance with applicable laws
- changes in business strategy, in agreements with other entities, and in key personnel
- reliance on subcontractors, and where they and any related data sit
- business continuity, resumption plans and recovery testing
- the vendor’s ability to protect your systems, information and data
| Source | What it sees | What it cannot see | Vantage | How fresh |
| Security ratings and attack-surface scans | Internet-facing assets and exposed weaknesses | Controls inside the vendor and how it handles your data. Scores also differ by provider: a 2021 comparison of four rating providers scoring the same organization found normalized scores from 57% to 80%, and ratings draw on data “collected or purchased from public and private sources” (the U.S. Chamber of Commerce principles, whose supporters include rating firms) | Outside-in | Daily or continuous |
| Breach and dark-web intelligence, incl. leaked-credential and paste-site feeds | Incidents and data already exposed or offered for sale | Anything not yet leaked or posted | Outside-in | Near real time |
| Financial feeds | Credit changes, filings, financial deterioration | Security and data handling | Outside-in | Monthly, or as filed |
| Adverse media | Reported incidents, lawsuits, leadership news | Anything not reported | Outside-in | Daily to weekly |
| Sanctions and watchlist screening of the vendor and its owners | A listing of the vendor or its owners. Screening repeats because the lists change, and the compliance framework of the Office of Foreign Assets Control (OFAC) expects a sanctions program to be “capable of adjusting rapidly to changes published by OFAC” | Security and data handling | Outside-in | Each time the lists change |
| Questionnaires and attestations | What the vendor states, or what an auditor tested for a past period | What changed since, and whether practice matches the answers. The October 2025 industry letter of the New York State Department of Financial Services (NYDFS) makes the point for due diligence that qualified people must interpret the responses | Inside-out, with the vendor’s cooperation | Yearly or on request |
| Contract notices | Changes the vendor must report, such as new sub-processors or data locations | Anything the contract does not require, or the vendor does not send | Vendor-reported | When sent |
| Risk exchanges | Shared, pre-completed assessments | The same limits as questionnaires, and they may be older | Inside-out | When updated |
| Your own access and integration records | Accounts, credentials, API tokens, OAuth grants, and integrations a vendor holds into your systems | What the vendor does with that access on its side | Your own records | Each time you review them |
| Dependency mapping | Vendors that rely on the same provider | Controls at those providers | Mixed | When the inventory changes |
| Observed outbound data flows from your own public pages and apps | Which data leaves and which recipients receive it. Repeating the observation shows what changed since the last check | Processing inside the vendor, and back-end and server-side flows | Your own pages and apps (this page’s name for the vantage) | Each time the observation repeats |
Concentration risk is about depending on a single provider for a number of activities, and on this page it also covers a number of vendors who are reliant on the same fourth party (a vendor’s own vendor). You see it once you’ve signed. The methodology is fourth-party dependency mapping.
For EU financial entities, concentration is assessed before contracting under the Digital Operational Resilience Act (DORA). Critical or important functions get specific concentration tests.
Through your own identity and SaaS records, you can watch the accounts, tokens, OAuth grants, and integrations a vendor holds in your systems. A compromised vendor can use that access.
What is the difference between outside-in and inside-out monitoring?
Outside-in monitoring observes a vendor’s security posture from public and purchased data without its involvement, while inside-out evidence comes from inside the vendor, in documents it provides or tests of its controls run with its cooperation. Inside-out evidence, such as security questionnaires and audit reports, is deep but periodic. Outside-in trades depth for breadth.
How is a monitoring tool different from vendor management or GRC software?
A monitoring tool flags changes in a vendor’s exposure or shows what your own pages and apps send, while vendor management or governance, risk, and compliance (GRC) software acts on those alerts. That software holds the inventory, assessments, contracts, and workflows. Some platforms bundle or integrate both.
Where do a monitoring tool’s alerts land? A useful test is whether they reach the GRC and ticketing systems where your team already decides and records.
What should you monitor for vendors without a SOC 2 report?
Without a SOC 2 report, rely more on outside-in, breach, financial, and adverse-media signals. Ask for other assurance you can check. Examples are an ISO 27001 certificate, an entry in the Cloud Security Alliance (CSA) STAR Registry, or a recent penetration-test summary.
Where risk justifies it, go further. Test the vendor’s controls yourself.
Can vendor monitoring tell you what a vendor does with your data?
Watching what your public websites and apps send won’t tell you what a vendor does with your data once it’s in their own systems. It will tell you what data leaves their systems and who the vendors and recipients are. Re-running the check will show you when that changes.
Inside the vendor, the contract does it all. The information, the audit, the scan and test rights with the attestations, and the notice obligations are all there. After-the-fact incidents, enforcement, the seeded test credentials, and what the vendor chooses to disclose are all there.
| Question about a vendor’s data handling | Can watching your own pages and apps answer it? | What answers it otherwise |
| Which vendors and recipients receive data from your pages and apps? | Yes, for vendors whose code runs there | Contract notices and the vendor’s own disclosures |
| Which fields does that code collect? | Yes, for what it sends (the Leaky Forms study shows it for email and password fields) | The vendor’s documentation, which may be incomplete |
| Has a new recipient appeared since the last check? | Yes, by repeating the observation | Sub-processor notices, if the contract requires them |
| What does the vendor store, and for how long? | No | Information, audit, scan and test rights in the contract |
| Does it share the data onward from its own systems? | No | Sub-processor notices and audits |
| Has login data you gave the vendor been stolen and used? | No, not from your pages | Seeded test credentials, which show it once attackers use them (UC San Diego’s 2017 story on its Tripwire study) |
| Does it use the data for its own purposes, such as model training? | No | Contract terms, privacy-scoped attestations and audits |
What pages and apps send can be observed down to the field. The Leaky Forms study did it. It crawled the 100,000 most popular websites in May 2021 and traced email and password inputs, field by field, to the tracker domains that received them.
In its desktop crawls, email addresses reached tracking, marketing, or analytics domains before the form was submitted on 2,950 sites visited from the US. The count from the EU was 1,844. A 2018 study of 5,855 children’s apps ran each app on test phones and captured its network traffic to see what data it shared and with whom.
Testing with its own account, MELURNA’s research found a sign-up form with no method attribute that put a test password into the page URL (MELURNA research, “Broadcast, Not Stolen”, August 2026). That URL was transmitted to 31 third-party hostnames. Across the top 100,000 domains, 7,874 had a credential or personal-data form without a method attribute, a count of risky markup, not of confirmed leaks.
As the US Department of Health and Human Services (HHS) puts it in its guidance on online tracking technologies (a court has since vacated part of it, on a different point), “[g]enerally, tracking technologies developed by third parties (e.g., tracking technology vendors) send information directly to the third parties who developed such technologies”.
California’s privacy regulator has ordered a related check. The California Privacy Protection Agency’s announcement of its Tractor Supply decision describes Tractor Supply’s remedy as including “scanning its digital properties to inventory tracking technologies”.
An app gets the same check by capturing and decrypting a test device’s network traffic while the app is used. Encrypted traffic needs the test device to trust an inspection certificate, which the children’s-apps study’s capture tool installed. Apps that pin certificates resist this.
A one-time check of whether a vendor’s observed behavior matches the paperwork is in the guide to third-party privacy risk. Repetition on a schedule makes it monitoring.
On your own site, third-party scripts and tags are vendors that receive data straight from your visitors’ browsers. PCI DSS covers those on payment pages. Its requirements 6.4.3 and 11.6.1, in the PCI Security Standards Council’s words, “focus on ensuring that payment page scripts are properly authorized, checked for integrity, and monitored for tampering”.
Site scripts need their own monitoring method. The guide on how to monitor the scripts and tags on your site covers it, including how to catch a tag stack that drifts.
What do regulators expect from ongoing vendor monitoring?
The US banking guidance, NYDFS, Gramm-Leach-Bliley Act (GLBA), SEC and DORA texts, and NIS2 for the entity types its implementing regulation lists, call for ongoing or periodic oversight of vendors. Several scale it to risk.
Under GDPR Article 28, HIPAA’s business associate rules and the service-provider rules of the California Consumer Privacy Act (CCPA), the texts rely on contract terms and rights. None states a duty to monitor. Even so, the European Data Protection Board (EDPB) says controllers should verify processors’ guarantees at appropriate intervals.
Several regimes let supervisors demand records. The 2023 US banking guidance says supervisory reviews “evaluate risks and the effectiveness of risk management”.
No rule among the texts we read requires a firm to monitor its vendors continuously in those words. DORA’s subcontracting standard comes nearest.
For information and communication technology (ICT) services supporting critical or important functions, the contract must oblige the ICT provider to monitor its own subcontractors. The aim is that its obligations are “continuously met” (Delegated Regulation (EU) 2025/532, Art. 4(1)(b)). NIST CSF 2.0 also uses the word.
Adoption of NIST CSF is voluntary or mandated. Under its “Continuous Monitoring” category, the framework includes monitoring external service providers.
| Regime | Applies to | Force | Monitoring expectation | Evidence expected |
| Interagency Guidance on Third-Party Relationships (2023) | US banking organizations supervised by the Federal Reserve, the Federal Deposit Insurance Corporation (FDIC) and the Office of the Comptroller of the Currency (OCC) | Supervisory guidance that “does not have the force and effect of law” | Ongoing monitoring “commensurate with the level of risk and complexity of the relationship”, which “may be conducted on a periodic or continuous basis” | Examples the agencies have observed: an inventory, risk and performance reports from the third party, remediation plans, periodic board reporting. In September 2026, the federal banking agencies and the National Credit Union Administration (NCUA) proposed third-party risk management guidance that would replace this guidance. Comments close November 16, 2026 |
| DORA with Delegated Regulation (EU) 2024/1773 | EU financial entities | Regulation | For critical or important functions, the contract gives “the right to monitor, on an ongoing basis, the ICT third-party service provider’s performance” (Art. 30(3)(e)). For all ICT contracts, the contract must require the provider to “notify the financial entity in advance if it envisages changing” where data is processed (Art. 30(2)(b)) | A register of all ICT contracts, available “upon its request” to the competent authority (Art. 28(3)). The performance assessment “is to be documented” (Delegated Regulation 2024/1773, Art. 9(3)) |
| 23 NYCRR 500.11 with the NYDFS Industry Letter of October 21, 2025 | NYDFS covered entities | Rule (the letter is guidance) | “periodic assessment of such third-party service providers based on the risk they present and the continued adequacy of their cybersecurity practices”. The letter asks for policies “for the ongoing monitoring and oversight of TPSPs” (third-party service providers) | Records supporting the annual compliance certification, kept five years (500.17(b)(3)). NYDFS reviews third-party policies “during examinations and investigations” |
| NIS2 Art. 21, with Implementing Regulation (EU) 2024/2690 | Essential and important entities, as each member state transposes it | Directive | Supply chain security, including relationships with direct suppliers. Article 21’s text has no explicit ongoing-monitoring duty. For the entity types it lists, the implementing regulation requires monitoring suppliers’ practices “at planned intervals and when significant changes to operations or risks or significant incidents” related to the services occur | Supervisors may request “evidence of implementation of cybersecurity policies” (for essential entities, Art. 32(2)(g). For important entities, Art. 33(2)(f), ex post, when non-compliance is indicated) |
| GDPR Art. 28 | Controllers that use processors | Regulation | Article 28’s text names no monitoring duty. The levers are information and audit rights (Art. 28(3)(h)) and sub-processor notice (Art. 28(2)). The EDPB’s Guidelines 07/2020 (version 2.1, para 99) call the duty to use only processors with sufficient guarantees “a continuous obligation”, verified “at appropriate intervals” | The ability to demonstrate compliance (Arts 5(2) and 24(1)) |
| HIPAA business associate rules (45 CFR 164.504(e)) | Covered entities | Rule | Under the Privacy Rule, covered entities “are not required to monitor or oversee” how business associates carry out privacy safeguards (HHS FAQ, created 2002, reviewed 2023). But under 45 CFR 164.504(e)(1)(ii) a covered entity that knew of a pattern of material breach must take reasonable steps to cure it or end the violation and, if that fails, terminate the contract “if feasible”. A January 2025 proposal would require written verification from business associates, at least once every 12 months, that they have deployed the technical safeguards the Security Rule requires. It is not in force, and the latest Unified Agenda projects final action for July 2027 | A business associate contract giving satisfactory assurances |
| CCPA service-provider rules (Civ. Code 1798.100(d) and CCPA regulations § 7051) | Businesses subject to the CCPA | Statute and regulations | The contract grants “rights to take reasonable and appropriate steps to help ensure” compliant use (1798.100(d)(3)). Under § 7051(a)(6), those steps “may include ongoing manual reviews and automated scans of the service provider’s system and regular internal or third-party assessments, audits, or other technical and operational testing at least once every 12 months”, and Civ. Code 1798.140(ag)(1) and (j)(1)(C) use the same 12-month wording for service providers and contractors. A business that “never enforces the terms of the contract nor exercises its rights to audit or test” the vendor’s systems “might not be able to rely on” the defense that it had no “reason to believe” the vendor would misuse the information (Civ. Code 1798.145(i)(1), and § 7051(c), an example) | Contract terms, plus evidence of due diligence, enforcement or audits |
| GLBA Safeguards Rule, 16 CFR 314.4(f) | Financial institutions under FTC jurisdiction | Rule | “Periodically assessing your service providers based on the risk they present and the continued adequacy of their safeguards” (314.4(f)(3)) | Not specified in this provision |
| SEC Regulation S-P, 17 CFR 248.30, as amended in 2024 | Covered institutions: brokers, dealers, investment companies, and investment advisers and transfer agents registered with the SEC or another appropriate regulatory agency | Rule | Written policies and procedures “reasonably designed to require oversight, including through due diligence and monitoring, of service providers”, as part of the incident response program (248.30(a)(5)(i)) | Written policies and procedures |
| NIST CSF 2.0 | Any organization | Framework that “may be adopted voluntarily and through governmental policies and mandates” | Supplier risks “monitored over the course of the relationship” (GV.SC-07), and “External service provider activities and services are monitored to find potentially adverse events” (DE.CM-06) | Not specified |
Recurring items across several of these texts include:
- an inventory or register of third-party relationships
- monitoring reports and documented assessments with their results
- remediation plans and how they were tracked to closure
- reporting to senior management or the board
- records you can produce on request
Regulators’ minimum oversight for fourth parties is in the regulatory floor for fourth parties.
How do you set up vendor risk monitoring?
Set-up starts with the inventory and follows a fixed order, which is this page’s own synthesis: list your vendors as records, tier them, record each one’s baseline, pick signals and a cadence per tier, set triggers, thresholds and alert owners, staff it with people who can act, document and report, and set a review date. Each step has a test. That makes the list a monitoring checklist.
- List your vendors as records. Done when every vendor that touches your data, systems, or customers has a record with the fields below.
- Tier them. Done when each record carries a tier and the reason for it, for example, high, medium, or low risk. High-risk vendors get more monitoring.
- Record each vendor’s baseline. Done when the due diligence findings, the approved data and access, and the conditions of approval are on file for each vendor.
- Pick signals, sources, and a cadence per tier. Done when each tier has named sources and a check frequency for each.
- Set triggers, thresholds, and alert owners. Done when every alert type has a threshold, an owner, and a route.
- Staff it with people who can act. Done when the people who review alerts have the expertise, authority, and accountability to act on them.
- Document and report. Done when decisions are recorded, and a reporting schedule to leadership exists.
- Set a review date. Done when the program itself has a date to be re-checked against what its alerts turned out to be.
Through feeds and reviews, you can monitor vendors only once they are listed. Your own pages and apps are the exception. Watching what they send can surface recipients nobody listed.
A current inventory, covering key subcontractors where the risk warrants it, also shows which vendor relationships carry higher risk. Kept complete, it helps you see when a relationship’s risk has changed. So the vendor inventory comes first.
| Inventory field | What it records |
| Business owner | Who inside your organization owns the relationship and hears about alerts |
| Activity and criticality | What the vendor does for you, and how much depends on it |
| Data the vendor receives | Which categories of data, and from which systems, pages, or apps |
| Access paths into your systems | Accounts, credentials, API tokens, OAuth grants and integrations the vendor holds |
| Related subcontractors | Where the risk warrants it, the providers the vendor relies on |
| Last assessment date | When the baseline was last checked |
| Tier | The monitoring intensity the vendor gets |
How often should continuous vendor monitoring check each vendor?
Each in-scope vendor’s automated signals should be watched continuously, at the speed each source updates, with reassessment on a cycle set by tier and whenever a trigger fires. Tier sets the pace. Where the binding rules we found address frequency at all, several set it by risk rather than a fixed interval, among them the GLBA Safeguards Rule and NYDFS Part 500.
Fixed intervals appear mainly in three places. The PCI Security Standards Council says customers must monitor their service providers’ PCI DSS compliance status at least annually (Requirement 12.8, FAQ 1312). California’s 12-month testing figure is a measure a business may contract for, not a required interval.
For businesses that meet the regulations’ thresholds, California’s cybersecurity audit must assess the business’s oversight of service providers, contractors, and third parties where applicable. First reports are due from April 2028 to April 2030 by revenue band, and the audit is yearly after April 2030 (11 CCR 7120, 7121, 7123(c)(15)). Its yearly cycle is the second fixed interval.
California’s audit cycle covers the business’s oversight of service providers, contractors, and third parties as a whole. It is not a per-vendor review.
Orders against single companies also set fixed intervals. One example is the Federal Communications Commission’s (FCC) 2025 Comcast decree, which requires biennial vendor risk classification assessments.
Where a rule or order above names an interval, that interval applies to the firms it covers. The tier lists below are practice, not rule.
Always-on signals
- Critical vendors: breach, incident, certificate-expiry, and outage alerts as they arrive. Ratings and threat intelligence daily, news weekly, financial and certification data monthly.
- Other in-scope vendors: the same automated feeds, with alerts routed by severity rather than read one by one.
Formal reassessment
- Critical vendors: at least yearly, and at once when monitoring flags a material change.
- Lower tiers: a yearly re-check, plus a review whenever a trigger event occurs.
- Every tier: a trigger event overrides the calendar.
“Continuous” does not mean instantly. It means each source is checked as fast as it updates.
Breadth comes from automated feeds on every in-scope vendor. The top tier gets the depth. Depth means more sources and a person reading each alert.
The vendors that handle sensitive data or large volumes, are critical to your operations, or are seen sending data beyond their stated purpose get the most monitoring. Re-tier them when any of that changes.
Which vendor changes should trigger an immediate review?
Review a vendor at once when something changes the basis on which you approved it. A breach is one such change. Others include a posture drop past your threshold, a lapsed certification or expired evidence, material or repeat audit findings, financial deterioration, an ownership or key-personnel change, a change to its privacy policy or terms, an enforcement action or sanctions listing, a continuity incident, a new recipient seen in what your own pages and apps send, or a change in the data, access, locations or sub-processors involved.
| Trigger | Example signal | How you learn of it | What the first review checks |
| Security | |||
| Breach or security incident at the vendor | Breach notice, news report, breach-intelligence alert | Monitoring feed, vendor notice | Which of your data and access were involved |
| Widely exploited vulnerability in software the vendor runs | Advisory, scan finding | Monitoring feed | Whether the vendor is exposed and has patched |
| Posture drop past your threshold | Rating fall, newly exposed service | Monitoring feed | Whether the change is real and material |
| Compromise of a vendor credential, token or integration | Identity alert, revoked token | Your own records, vendor notice | Which access paths to cut or rotate |
| Assurance | |||
| Lapsed certification or expired evidence | Certificate or report past its date | Your own records, vendor notice | Whether current evidence exists |
| Material or repeat audit findings | Audit report, attestation exceptions | Vendor notice, requested report | Whether remediation is on track |
| Business health | |||
| Financial deterioration | Credit downgrade, bankruptcy filing | Monitoring feed | The vendor’s financial stability, its ability to keep delivering, and exit readiness |
| Ownership, strategy or key-personnel change, or new agreements with other entities | Merger news, leadership change | Monitoring feed, vendor notice | Whether control or accountability moved |
| Insurance lapse | Cover lapsed or reduced | Vendor notice, requested certificate | Whether contract requirements still hold |
| Continuity incident | Outage, missed service level agreements, failed recovery test | Monitoring feed, vendor notice | Impact on your service and on recovery |
| Legal and sanctions | |||
| Enforcement or regulatory action | Regulator order, lawsuit | Monitoring feed | Whether it touches your data or service |
| Sanctions or watchlist listing of the vendor or its owners | Screening hit | Monitoring feed | Whether you may keep dealing with it |
| Data handling | |||
| Vendor privacy policy or terms change | New purposes, new recipients | Vendor notice, your own reading of the policy | Whether new uses fit your contract |
| New recipient seen in what your own pages and apps send | New domain, new data field | Your own observation | Who the recipient is and why it receives data |
| Change in the data, access or data location involved | New data types, systems or regions | Vendor notice (see the DORA row in the regulator table), your own records | Whether the basis of approval still holds |
| Sub-processor added or replaced | Sub-processor notice | Vendor notice | The new party’s role and location (see how to watch fourth parties) |
| AI feature or AI provider added | Release notes, new AI terms | Vendor notice, your own observation | Who now processes your data and how, and whether it may train models on it. NYDFS guidance of October 2024 says risk assessments should address “the AI technologies utilized by TPSPs and vendors”. How to vet an AI vendor is in the guide to third-party privacy risk |
A new sub-processor, including a new AI provider, usually reaches you as a notice the vendor owes you. GDPR and the CCPA set notice duties.
Under GDPR Art. 28(2), a processor with general authorization must tell you of intended additions or replacements. You get the chance to object. Under the CCPA, a service provider must notify the business when it engages another person to help process the data (Civ. Code 1798.140(ag)(2)).
Several of these triggers reach you only if the vendor tells you about changes you cannot observe. The contract should require notice. Its clauses are in the guide to third-party privacy risk.
The first review is a targeted check, not a full reassessment. What changed and the tier set its scope.
What should happen when a vendor monitoring alert fires?
When an alert fires, check that it is real, rate it against the threshold set for the vendor’s tier, give it an owner, ask the vendor, and decide one outcome from a fixed list. Then record the decision with its evidence.
- Threshold, set beforehand. Set thresholds from your organization’s risk appetite and the vendor’s tier. That way, a small change at a vendor with production access or customer data escalates, while the same change at a low-risk vendor is only logged.
- Validate the signal. Confirm the alert is real and concerns this vendor’s assets.
- Classify severity against the tier. The same finding means more at a critical vendor than at a peripheral one.
- Name an owner and tell the business owner. One person drives it to closure.
- Ask the vendor a specific question, with a deadline. Ask about this signal, not for a fresh questionnaire.
- Decide one outcome from the table below.
- Track it to closure and record it. Keep the decision, the reason, the evidence, the owner, and the dates, including “no action, because”.
- Feed the outcome back into the vendor’s tier, its reassessment date, and your thresholds.
Automated playbooks can do the routine work on alerts. People keep the decisions.
| Outcome | When it fits |
| No action, with the reason recorded | The signal was false, or real but immaterial for this vendor |
| Remediation with a deadline | The vendor can fix the issue, and the risk can wait for the fix |
| Targeted reassessment | The change touches the basis of approval and needs a closer look |
| Compensating controls | You can reduce the risk on your side while the vendor fixes it |
| Reduce or pause the vendor’s access, or require reapproval | The risk runs through the access paths the vendor holds into your systems |
| Incident response | The alert shows a real incident that touches your data or service: hand it to your incident response plan, and see when a finding becomes a privacy incident and who answers for a vendor incident |
| Exit | The vendor can no longer be trusted with the service. Plan exits in advance, and offboarding is covered in the guide to third-party privacy risk |
| Accept the risk, with a named approver and an expiry date | The residual risk is within appetite, and it is logged in your risk register |
How can a small team keep vendor monitoring manageable?
Tiered monitoring and tuned alerts keep vendor monitoring manageable. Without them, alerts can outpace a small team. That happens when every vendor is watched the same way and no rule says what each alert should lead to.
- Match monitoring and alert severity to each vendor’s tier, and route alerts by urgency.
- Merge duplicate alerts about the same event into one case.
- Retune thresholds from what past alerts turned out to be.
- Automate the routine work, using the split below.
More than headcount, proportion decides it. A small team can keep close watch on the critical few and run the rest on automated feeds with a light process.
| Automate | Keep with a person |
| Evidence collection and filing | Accepting risk and granting exceptions |
| Chasing vendors, reminders and deadlines | Cutting a vendor’s access |
| Scheduling reviews and rescans | Deciding to exit a vendor |
| First-pass AI summaries of alerts and documents, checked against the source before they drive a decision | Vendor conversations about material findings |
| Pre-filling reviews from evidence already held | Any decision an AI summary would drive |
You can outsource the monitoring work. The responsibility for the result stays with you. As NYDFS Acting Superintendent Kaitlin Asrow said in October 2025,
“regulated entities are still ultimately accountable for protecting consumers and managing risk.”
Which metrics show vendor monitoring is working?
Coverage, time from signal to decision, alert precision, and follow-through show whether monitoring covers the vendors that matter and turns signals into decisions quickly. Each catches a different failure.
| Metric | What it shows | How to compute it | Failure it catches |
| Coverage by tier | Whether the vendors that matter are watched | Monitored in-scope vendors divided by all in-scope vendors, per tier | Vendors missing from the inventory or from the feeds |
| Time from signal to decision | Whether alerts turn into decisions | Median days from alert to recorded outcome, per severity | Alerts that sit unread |
| Alert precision | Whether the alerts are worth reading | Alerts that led to action divided by all alerts, and separately, material events found late or by other routes | Noise that hides real signals, and blind spots |
| Follow-through | Whether decisions are carried out | Triggered reassessments completed on time, findings closed by their deadline, and overdue findings at critical vendors | Decisions that never reach the vendor |
| Material changes found | Whether vendor risk is rising or falling | Count of material changes per period, by tier and type | A drift no single alert shows |
Of the metrics in the table, the first four are key performance indicators for the monitoring itself. Material changes found is a key risk indicator.
For leadership, a few measures suffice. Report a small, fixed set on a regular cadence, with the trend, from the same data the team uses. A quarterly cadence is a practice choice, not a rule, though reporting to senior management or the board recurs across several of the regulator texts.
How does MELURNA watch where vendor data goes?
MELURNA watches what your websites and apps send, with no agents or integrations and no access to your internal systems. We follow sensitive data past the approved vendor to AI services, subprocessors, and other downstream recipients, and changes over time.
DISCLAIMER: This guide is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information, and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.
