TL;DR
- A "shadow subcontractor" is any vendor embedded inside a SaaS tool you already use — the analytics platform, AI API, CDN, or identity provider that your approved tool calls without telling you.
- These fourth-party vendors process your data, but they sit outside every vendor questionnaire and contract review your security team runs.
- GDPR Article 28 makes you accountable for the whole processor chain, including layers you never contracted with. DORA's subcontracting RTS (in force July 2025) adds a mandatory subcontractor register for financial entities.
- The Ethira browser extension passively captures every third-party domain your SaaS tools call during real employee sessions — no vendor cooperation required.
- The result is a continuously updated fourth-party map that turns a compliance blind spot into an auditable register.
What is a shadow subcontractor?
Most third-party risk conversations stop at the direct vendor. You evaluate the project management tool your product team uses, sign a Data Processing Agreement, run an annual questionnaire, and mark it as assessed. Job done — or so the audit trail says.
What the questionnaire does not capture is everything that tool calls on your behalf.
When an employee opens that project management tool in their browser, the page does not talk to a single server. It talks to many. A typical SaaS product in 2025 uses an average of 3.9 fourth-party dependencies for analytics, CDN delivery, error tracking, identity services, and — increasingly — external AI model APIs. Each of those services receives a copy of whatever data flows through the original tool. None of them appear in the DPA you signed. None of them have been risk-assessed. None of them are in your vendor register.
These are shadow subcontractors: the processors-behind-processors that handle your data one layer deeper than your contracts reach.
The critical distinction from other "shadow" risk categories: shadow subcontractors live inside tools you have already approved. You cannot eliminate them by banning unsanctioned applications. They hide in your sanctioned stack.
Why this matters more than you think
The regulatory exposure
GDPR Article 28 requires controllers to enter into binding contracts with every processor — and Article 28(2) makes processors responsible for obtaining the controller's authorisation before engaging subprocessors. The controller is not absolved if a subprocessor causes a breach. The EDPB's Opinion 22/2024, published in October 2024, clarified this explicitly: complexity in a processing chain does not relieve controllers of accountability, regardless of how many layers deep the processing occurs.
In practice, this means that when your approved SaaS vendor's analytics subprocessor suffers a breach that exposes your customer records, you are accountable to regulators — even if you never knew that analytics platform existed.
DORA's subcontracting RTS (Commission Delegated Regulation (EU) 2025/532, entered into force 22 July 2025) goes further for financial entities. It requires organisations to assess whether an ICT service provider can identify all subcontractors supporting critical or important functions — before signing a contract. Post-signature, ICT providers must notify financial entities of any material changes to subcontracting arrangements. A register of those subcontractors must be maintained and made available to competent authorities on request. The obligation to map the chain is no longer theoretical; it is a named legal deliverable.
The breach reality
The supply chain attack surface is expanding faster than most TPRM programmes can track.
- 35.5 % of all verified breaches in 2024 originated at a third-party provider, up from 29 % the year before (SecurityScorecard, 2025).
- For every named vendor breach in 2025, an average of 5.28 downstream organisations were publicly compromised — and approximately 26,000 additional "shadow victims" were notified privately but never publicly named (Black Kite, 2026 Third-Party Breach Report).
- Fewer than 50 % of organisations monitor cybersecurity hygiene across 50 % or more of their nth-party supply chain (SecurityScorecard, 2025 Supply Chain Trends Report).
- Only 36 % of an average organisation's 2,643 third-party vendors are formally assessed at all — meaning most portfolios leave the fourth-party layer entirely unmapped (Ponemon–Sullivan, 2026 State of Third-Party Risk Assessments).
Supply chain attacks are particularly effective because a single compromised fourth-party provider — a shared CDN, a popular analytics SDK, an AI inference API — can affect dozens of upstream vendors simultaneously. The 2020 SolarWinds compromise and the 2024 Snowflake credential-stuffing campaign both illustrated how deeply a single fourth-party exposure ripples through an enterprise's vendor ecosystem.
Why traditional TPRM cannot see this layer
Standard third-party risk management is designed to evaluate direct vendors. It has no mechanism to reach fourth parties.
| Discovery method | What it reaches | What it cannot see |
|---|---|---|
| Vendor questionnaires | Direct vendor's declared architecture | Subprocessors not voluntarily disclosed |
| Contract and DPA review | Named processors in the agreement | Sub-processors added after signing |
| Vendor register | Known, contracted third parties | Any layer below the direct relationship |
| Security ratings (e.g. BitSight) | Direct vendor's external attack surface | Internal service dependencies they call |
| Annual penetration test of vendor | Snapshot of vendor's posture | Dynamic subprocessor additions between tests |
The deeper problem is velocity. A SaaS vendor can add a new AI sub-API to their product overnight. They may update their subprocessor disclosure page once a quarter, or less often. By the time a new entry appears in a vendor's published subprocessor list, it may have been processing your data for months.
NIS2, GDPR, and DORA all require ongoing monitoring of the supply chain, not point-in-time assessments. Traditional questionnaire-based TPRM is structurally unable to deliver ongoing coverage of fourth parties — it depends on vendor cooperation and self-disclosure, and it runs on a cycle measured in months.
How the Ethira browser extension sees what your vendor register cannot
The Ethira browser extension takes a fundamentally different approach. Rather than asking vendors what they call, it observes what they actually call — in real time, during normal employee usage.
The mechanism
When an employee opens any page in their managed browser, the extension's background service worker registers a listener on the browser's webRequest API. For every HTTP request that completes while that tab is active, it extracts the hostname from the request URL and compares it to the hostname of the current page.
Any request that resolves to a different hostname — a CDN, an analytics endpoint, an AI inference API, an identity provider, an error tracking service — is recorded as a third-party domain observation. These observations are deduplicated per tab session, capped to avoid noise, and batched into a browser.subprocessors signal envelope alongside the browser.session record for the SaaS tool itself.
The result is a live, continuously updated map of what every SaaS tool in your employee fleet actually calls — derived from observed network behaviour, not vendor self-disclosure.
What this surfaces in practice
Consider what happens when your team uses a popular AI-assisted writing tool. Your vendor register shows one entry: the writing tool itself, with a signed DPA on file. The browser extension, observing a typical session, records the actual requests that tool fires:
api.openai.com— the AI inference layer processing the content your employees writesegment.io— a customer analytics platform receiving behavioural telemetrysentry.io— an error tracking service receiving application state including user contextfonts.googleapis.com— a CDN loading assets (lower risk, but still a third-party call)auth0.com— an identity provider processing authentication tokens
Of those five, only the writing tool itself had a DPA. The AI inference layer — the most significant from a data processing perspective — was invisible to your TPRM programme until the extension surfaced it.
Privacy and scope
The extension observes at the hostname level only. It does not read page content, capture request bodies, or record the substance of what employees write or search. The data emitted to Ethira is the domain name, the timestamp, and its association with a specific SaaS session — nothing more. This is consistent with the extension's acknowledged data collection scope and Ethira's privacy policy.
The extension covers the browser fleet. It does not observe server-to-server calls that a SaaS vendor's backend makes independently of browser activity. That remaining layer — backend subprocessors not triggered by browser sessions — still requires vendor questionnaire coverage. The two approaches are complementary, not mutually exclusive.
From discovery to action in Ethira
Passively capturing domain observations is only the first step. Ethira turns those signals into an actionable compliance artefact.
Correlation against your vendor register. When a third-party domain is observed, Ethira checks it against your existing vendor register and its internal provider catalog. If the domain resolves to a known vendor — say, AWS, Segment, or OpenAI — that provider is surfaced as a potential subprocessor of the SaaS tool that called it. If the domain is unknown, it is flagged for investigation.
Subprocessor mapping. Each discovered fourth-party relationship is attached to the relevant third-party vendor entry in your register. You can see, for any assessed vendor, which additional providers it calls in practice — not just which ones it disclosed on paper.
Compliance gap identification. For each discovered subprocessor, Ethira checks whether a subprocessor record and appropriate DPA coverage exist. GDPR Article 28 gaps — subprocessors processing personal data without documented authorisation — are surfaced immediately.
Register export. The subprocessor map is exportable in formats suitable for the DORA register of information requirement and for GDPR Article 30 record-of-processing updates.
Policy enforcement. For fourth-party domains that represent an unacceptable risk — unlicensed AI providers, domains on threat intelligence blocklists, services in jurisdictions with inadequate data protection — the extension's policy enforcement layer can block or warn on the SaaS tool itself until the subprocessor relationship is resolved.
Frequently asked questions
Does the extension read what employees write or search?
No. The extension operates at the hostname level in the browser's isolated network layer. It captures domain names and timestamps — not URLs, not page content, not request or response bodies. The substance of what employees do inside any tool is invisible to it.
What about subprocessors the vendor calls server-side, not from the browser?
Those are not observable by a browser extension. Backend-to-backend calls happen entirely within the vendor's infrastructure and produce no browser-level network event. Vendor questionnaires, contract terms requiring subprocessor disclosure, and security assessments are the appropriate coverage mechanism for that layer. Ethira's browser signal and your vendor questionnaire programme are complementary.
Does this cover employees on mobile devices or personal laptops?
The extension covers managed browsers deployed via enterprise browser policy. Employees accessing SaaS tools on personal devices or mobile apps outside the managed fleet are not covered. The extension is one layer in a defence-in-depth approach, not a complete substitute for contractual subprocessor disclosure obligations.
How often is the fourth-party map updated?
Continuously. Every employee session generates fresh observations. If a vendor adds a new AI API to their product tomorrow, the next time any employee in your organisation opens that tool, the new domain is observed and surfaced in Ethira — with no manual action, no questionnaire cycle, and no dependency on the vendor notifying you.
Sources
- GDPR Article 28 — Processor obligations and sub-processor requirements — EUR-Lex
- EDPB Opinion 22/2024 on the use of processors and sub-processors (October 2024) — edpb.europa.eu
- Commission Delegated Regulation (EU) 2025/532 — DORA RTS on subcontracting of ICT services (in force 22 July 2025) — legaltree.nl / EUR-Lex
- SecurityScorecard — 2025 Supply Chain Cybersecurity Trends Report — securityscorecard.com
- Black Kite — 2026 Third-Party Breach Report — blackkite.com
- Ponemon Institute / Sullivan Privacy — 2026 State of Third-Party Risk Assessments — ponemonsullivanreport.com
- Safe Security — Fourth-Party Risk Management: 2026 Best Practices for TPRM — safe.security
- CSO Online — "Cybersecurity in the supply chain: strategies for managing fourth-party risks" — csoonline.com