Skip to content
Use case

Continuous monitoring

You know your vendors. You do not know theirs, and the chain moves between annual reviews.

Security and third-party riskProblems P1, P2, P3Available now
What changes

The problem, what happens today, and what we do instead.

You have no visibility below depth 1.

Today Nothing. The gap is accepted, because reading one subprocessor page per vendor is already the whole budget.

With Subprocessor monitoring We traverse the whole chain — your vendor's subprocessors, and theirs, until it terminates — over a visited set, with cycles detected and depth stored as the shortest path from your root.

Changes are discovered at annual review, or never.

Today A calendar reminder and a quarterly spot check of the pages someone remembered to bookmark.

With Subprocessor monitoring Every watched page is checked daily. A change is typed, summarised and matched against your rules the same day we see it.

Manual checking stops scaling at about ten vendors.

Today A spreadsheet, a folder of browser tabs, and good intentions.

With Subprocessor monitoring The graph is maintained for you. Adding the eleventh vendor costs you one search and nothing else.

The gap this closes is specific. Your inventory lists the companies you signed contracts with. Your exposure includes every company they signed contracts with, and every company those companies signed contracts with. The second and third rings are where the providers you would have objected to actually sit.

What a day looks like

We refetch every subprocessor page in your graph, hash the disclosed edge set, and compare it to yesterday's. An unchanged hash ends the work there, which is why copyright years and layout churn cost you nothing. A moved hash produces a typed diff — entity added, entity removed, terms changed, or an announced addition or announced removal that has not taken effect yet — carrying the source URL, the detection timestamp and the full path from your root. A change to a company's own facts is typed the same way — a jurisdiction shift, a category shift, or an ownership shift when it is acquired or changes parent.

Your rules decide who hears about it. A rule matches on change type, country, region, category, depth and entity ID, and carries its own severity, channels and immediate-or-digest setting. You can dry-run it against your current graph before you save it, so you know what it would have caught.

Coverage is part of the answer

Below depth 3, published lists thin out fast. Unbounded traversal usually means three or four useful levels, and every watched vendor carries a coverage percentage that says how much of its graph we actually resolved. A tool that hid that number would be reporting confidence it has not earned.

Three termination states, never collapsed into two. resolved means we found and parsed the entity's own list. publishes_nothing means it discloses none, which is a fact. not_yet_crawled means we have not reached it, which is a gap. Conflating the last two understates your risk.

What you get out of it

  • A daily-maintained graph per watched vendor, deduplicated and depth-annotated
  • Typed change events with the source URL and the path from your root
  • Rules that evaluate the same way whoever wrote them, in whatever language
  • A coverage number per vendor, and the three states behind it
  • An exportable change artifact you can paste into a risk report
Also

The other two jobs this dataset answers.

Incident exposure

A provider is in the news. The question is whether you are exposed to it, and through which vendor.

Procurement due diligence

Compare two vendors' chains before you sign one of them, rather than discovering the difference at renewal.

Start with one vendor. Free, and no card.

Search a company, follow it, and see the chain beneath it. Upgrade when one vendor stops being enough.