2026-09-17, News · Google · Brand Monitoring · Engineering

Third-party risk monitoring with news and search data: a continuous vendor watch

Continuous third-party risk monitoring means watching the vendors you already depend on for public signs that their risk has changed: a breach disclosure, a lawsuit, a regulator’s order, layoffs, a going-concern warning, an acquisition. The annual questionnaire tells you what the vendor said about itself last spring. News coverage and search results tell you what happened on Tuesday.

What follows is the data pipeline for a vendor watch built on Google News and Google Search results. Public web data cannot prove a vendor is safe or show anything that was never published, and it does not by itself satisfy any regulatory expectation.

Why point-in-time assessments leave a gap

Most third-party risk programs are built around onboarding due diligence plus a periodic reassessment. The gap is everything that happens in between.

US banking regulators describe the expectation directly. The 2023 Interagency Guidance on Third-Party Relationships: Risk Management from the Federal Reserve, FDIC and OCC (checked 2026-09-17) says ongoing monitoring “may be conducted on a periodic or continuous basis,” with more comprehensive or frequent monitoring when a relationship supports higher-risk or critical activities. It lists the kinds of issues monitoring should let an organization escalate, including “deterioration in financial condition, security breaches, data loss, service interruptions, compliance lapses, or other indicators of increased risk.” In its due diligence section it also points to a third party’s history of customer complaints or litigation and to reviewing its websites and marketing materials.

That guidance applies to US banking organizations, and your obligations depend on your sector and jurisdiction. The operational point generalises, though: several of the listed signals often become public before a vendor tells you about them, and some never reach you through the contract at all.

What public data can and cannot show

Two consequences follow. First, public monitoring is strongest for vendors large enough to be covered by the press and weakest for small niche suppliers, where the absence of news means nothing. Second, anything list-based, such as sanctions, belongs to a list-screening process, not a news query.

The data you get back

Two endpoints do most of the work.

Google News (POST /v1/monitor/google/news) returns newsResults[], each with position, title, link, snippet, source (the publisher), date as displayed, page and thumbnail. Request fields are on the Google News engine page.

Google Search (POST /v1/monitor/google) returns organicResults[] (position, title, link, snippet, date), plus page features. For vendor monitoring the useful ones are knowledgeGraph (entity type, website, attributes), peopleAlsoAsk (questions people ask about the company, which sometimes surface “is X going out of business” style concerns) and, when you request it, the AI Overview in aioverview with its text and cited sources.

Google interprets its own search operators in the query text, so a query such as "Acme Payments" breach requires the exact company name as a phrase. Google documents the quote, minus, site:, before:/after: and filetype: operators on its Refine Google searches help page (checked 2026-09-17).

For the underlying screening mechanics that this builds on, see the adverse media screening use case; for the news collection pattern, see news monitoring.

Step 1: build the vendor register the monitor reads

The monitor is only as good as its subject records. For each third party, store:

Aliases matter more than people expect. Incidents are often reported under a product or brand name rather than the legal entity, and acquisitions change names mid-relationship.

Step 2: write query templates per signal family

Generic queries like Acme risk return marketing pages. Precise wrongdoing or event terms return events. Group terms into signal families so every alert carries a category.

A template combines the quoted name with one family’s terms:

"{name}" (breach OR ransomware OR "data leak" OR outage)
"{name}" (fine OR penalty OR "consent order" OR "enforcement action")
"{name}" (lawsuit OR "class action" OR settlement)
"{name}" (bankruptcy OR layoffs OR restructuring OR "going concern")
"{name}" (acquired OR acquisition OR merger)

Start with one query per family per name per market, then measure which templates produce confirmed findings and prune the rest. If a company name is also a common word, add a disambiguator or exclude the known false match with the minus operator.

For search results rather than news, a narrower set usually suffices: the bare quoted name (to watch the knowledge panel, People Also Ask and AI Overview) and one combined risk query per month.

Step 3: tier the cadence

Cadence is a risk decision. A workable default:

Event triggers cost almost nothing to add: a contract renewal, a scope expansion or a new data-sharing agreement should queue a fresh check of that vendor regardless of the calendar.

Step 4: submit checks as async batches

Scheduled monitoring should not hold open connections. Create async tasks in batches of up to 500 with a webhook, and derive a deterministic idempotency key from vendor, query and time slot so a retried cron cannot double-submit.

import datetime as dt, os, requests

API = "https://api.answerline.dev"
HEADERS = {"Authorization": f"Bearer {os.environ['API_KEY']}"}
HOOK = {"url": "https://hooks.example.com/tprm"}

TEMPLATES = {
    "cyber": '"{n}" (breach OR ransomware OR "data leak" OR outage)',
    "regulatory": '"{n}" (fine OR penalty OR "consent order" OR "enforcement action")',
    "legal": '"{n}" (lawsuit OR "class action" OR settlement)',
    "financial": '"{n}" (bankruptcy OR layoffs OR restructuring OR "going concern")',
    "corporate": '"{n}" (acquired OR acquisition OR merger)',
}

def tasks_for(vendor, families, slot):
    stamp = slot.strftime("%Y%m%d")
    for name in [vendor["legal_name"], *vendor["aliases"]]:
        for market in vendor["markets"]:
            for fam in families:
                yield {
                    "taskType": "GOOGLE_NEWS",
                    "payload": {"query": TEMPLATES[fam].format(n=name), "country": market},
                    "priority": 8 if vendor["tier"] == "critical" else 3,
                    "idempotencyKey": f"tprm:{vendor['vendor_id']}:{fam}:{market}:{abs(hash(name))}:{stamp}",
                    "webhook": HOOK,
                }

def submit(vendors_due, families_by_tier):
    slot = dt.datetime.now(dt.timezone.utc)
    tasks = [t for v in vendors_due for t in tasks_for(v, families_by_tier[v["tier"]], slot)]
    created = []
    for i in range(0, len(tasks), 500):
        res = requests.post(f"{API}/v1/async/task/batch", json=tasks[i:i + 500], headers=HEADERS, timeout=60)
        res.raise_for_status()
        created += [r for r in res.json()["results"] if r["success"]]
    return created

Python’s built-in hash() is salted per process, so in production replace it with a stable digest such as hashlib.sha1(name.encode()).hexdigest()[:8]; it is shown here only to keep the example short. Idempotency keys must be unique across your account, which is why the slot date is part of the key. See idempotency keys explained and async tasks.

Step 5: match, deduplicate and triage

When the webhook arrives, the body carries the task summary and, for a completed task, the full response object. Verify the signature first (webhooks, verifying signatures), then process each newsResults[] item:

1. Normalise the URL. Strip tracking parameters and fragments, lowercase the host. Use it as the dedup key per vendor.
2. Suppress known items. If this vendor already has a decision recorded for this URL, drop it. Re-alerting on the same article is the fastest way to lose reviewer trust.
3. Confirm the entity. Require the name or an alias in title or snippet, and prefer items that also contain a disambiguator. A quoted query is a strong filter, but Google can still match on text outside the snippet.
4. Classify. Attach the family from the query, and optionally re-score with keyword rules on the snippet.
5. Score severity. Combine vendor tier, family, and publisher. A breach report in a major outlet about a critical payments processor is a page to the relationship owner; a layoffs rumour about a low-tier supplier is a weekly digest line.
6. Route. Open a review item with vendor, family, title, snippet, publisher, displayed date, link and the task id that produced it, so any finding can be traced back to the exact check.

The date field is the relative or absolute date Google displayed, such as “3 hours ago”, so convert it relative to the task’s completion time and keep the raw string.

Step 6: watch what search and AI answers say about the vendor

News catches events. Search results and AI answers show the reputation layer a procurement team or a customer sees when they look the vendor up.

A weekly Google Search task on the bare quoted name, with the AI Overview requested, gives you three things to diff:

• knowledgeGraph.website and knowledgeGraph.type, which change after rebrands and acquisitions.
• peopleAlsoAsk[].question, where questions about lawsuits, security or shutdowns appear when enough people ask them.
• aioverview.text and aioverview.sources[], which summarise what Google’s AI Overview says and which pages it relies on.

curl -X POST https://api.answerline.dev/v1/monitor/google \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "\"Acme Payments\"",
    "country": "US",
    "include": { "aioverview": { "markdown": false } }
  }'

Treat AI answers as pointers, never findings. An assistant can conflate two companies with similar names or repeat an old story as current; follow its sources to the underlying articles before anyone acts.

Step 7: close the loop with decisions

Every reviewer decision should be stored: relevant, not relevant, duplicate, or escalated, with a reason. Those decisions do three jobs:

• Suppression. Dismissed URLs never alert again for that vendor.
• Template pruning. Precision per template and per family tells you which queries to rewrite or drop.
• Audit trail. For any vendor you can show what was checked, when, what was found and what was decided.

Metrics worth tracking monthly:

Cost planning

Credits per async task: Google News 3, Google Search 3 (plus 2 when you request the AI Overview), each additional results page 2. Synchronous calls cost 2 more, which is why a scheduled monitor should use async tasks.

A worked example, one market per vendor and one name per vendor:

Aliases and extra markets multiply the news rows, so count them before choosing a plan on the pricing page. The free tier’s 500 credits a month is enough to prototype the templates on a handful of critical vendors and measure precision before you scale. Planning detail is in AI monitoring cost planning.

Pitfalls

• Treating silence as safety. No news about a small supplier is not evidence of anything.
• Monitoring the legal name only. Incidents are reported under brands and products.
• One query for everything. A single "Acme" (breach OR lawsuit OR bankruptcy OR ...) query mixes categories and hides which terms produce noise.
• No suppression. Without stored decisions, the same article alerts every day it stays in the results.
• Acting on an AI summary. Always read the source article.
• Confusing monitoring with assurance. Public data raises questions for the vendor; it does not answer them. The follow-up is a conversation, a contractual notice or an audit request.

Pair public-data monitoring with contractual incident-notification clauses, security attestations, financial reviews and list screening; your risk and compliance teams decide what each finding means.

Related reading: perpetual KYC and adverse media for the customer-side equivalent, OSINT tools for defenders, and media monitoring tools.

To run your first vendor check, start with the quickstart.

Keep reading