Vendor lists & piggyback

Two pages answer the governance questions auditors actually ask: which vendors touch our data, and who approved them? (Vendor lists) and who put that vendor on our site? (Piggyback).

Vendor lists

Vendor lists (app.monita.ai/compliance/vendors) is your data-governance register: every vendor observed in your traffic gets an explicit verdict.

Verdict	What it means
Approved	Documented as sanctioned. Appears as expected in digests and reviews — your clean audit trail.
Blocked	Must not fire. If it does, the compliance monitor files a HIGH issue and it leads the digest — this is how you catch a rogue tag someone re-enabled.
Unreviewed	Observed in traffic but nobody has made a call. The goal is zero unreviewed vendors.

The feature is enforcement, not bookkeeping: a blocked vendor that keeps firing is a violation — it’s flagged on the list, files compliance issues automatically, and marks the property’s standing on the Command center.

Each row also shows where the vendor was seen — two independent sources with their own last-seen times, because they legitimately disagree:

• Live — the vendor fired in real monitored traffic.
• Audit — the vendor executed when real browsers loaded your pages during an audit.

Consent expectation

Alongside the allow/block verdict, each row carries a consent expectation — how the compliance suite should read this vendor’s fires when consent is absent:

Expectation	When to use it
Consent required (default)	The vendor must not fire without affirmative consent — a no-consent fire is flagged as a breach
Consent mode	The vendor fires anonymized without consent by design — e.g. Google Advanced Consent Mode, where pings are cookieless until consent is granted. Its fires get a consent mode badge instead of a breach flag
Exempt	Your organization accepts this vendor’s fires regardless of consent — e.g. an essential business partner. Its fires get a grey exempt badge

Pick it from the dropdown on the vendor’s row. The setting drives how the vendor reads on the Command center consent-by-vendor table — counts stay visible in every case, only the labelling changes. Full detail, including how to set it via the API or MCP, is in Consent settings.

Policy scope

Policies are set org-wide by default, with overrides per project or per property — most specific wins. In a scoped view, an inherited policy is labelled with its origin; changing it there writes an override at that scope. Useful when one client allows a vendor another client bans.

A bulk Approve all unreviewed action clears the backlog on first setup, and Export report produces the vendor register as CSV — the document privacy reviews ask for.

Piggyback

Piggyback (app.monita.ai/compliance/piggyback) answers one question: who put that vendor on your site?

Real browsers load each of your pages and record the complete load chain — page → tag manager → vendor → sub-vendor — so when an unfamiliar vendor appears, you can see exactly which script introduced it. Vendors loaded by another vendor rather than by your page are tagged piggybacked.

Every vendor in the chain carries its policy standing from Vendor lists — in policy, BLOCKED or unreviewed — so an out-of-policy tag stands out in the tree, and out-of-policy findings file compliance issues automatically.

Two readings of the same data:

• Folders — indented rows, dense, scan-down-the-page.
• Tree — a left-to-right cascade that draws the load chain as a picture.

Tip

Import your sitemap under Coverage before the first run so the audit knows which pages matter. The cookies each page leaves behind land on the Cookies page from the same audit run.

How the two work together

1. Traffic flows; vendors appear on Vendor lists as unreviewed.
2. You (or the team that owns the tag) mark each one approved or blocked.
3. From then on, a blocked vendor firing anywhere — live traffic or an audit — is flagged, filed and routed through your alert rules.
4. When something unexpected shows up, Piggyback tells you which script to remove, and from which container.