To know who receives your users' personal data, inventory third party SDKs and services from three angles: your dependency manifests, your outbound network traffic and your vendor accounts. Then record each as a recipient, check the contract, and review again whenever a dependency or integration changes.
Why dependencies matter for privacy
A privacy notice that says "we share data with our service providers" is only as good as your list of them. Developers add SDKs for analytics, crash reports, payments, chat widgets and maps. Each can send device identifiers, IP addresses or user fields to its owner's servers, sometimes without anyone reading the defaults.
Under GDPR Article 28(2), a processor must not engage another processor without the controller's prior specific or general written authorisation, and under 28(4) it stays fully liable to the controller for a sub-processor's failures. You cannot authorise what you do not know about.
Angle 1: dependencies
Read lockfiles and manifests for web, mobile and backend. Flag packages whose purpose is to talk to a service: analytics, ads, error tracking, messaging, payments, auth, feature flags. List the version too, since a new release can add new data collection.
Mobile apps deserve extra attention. SDKs are bundled into the binary, and their data collection can change with an update.
Angle 2: network traffic
Run the app and watch outbound requests, in a browser developer tool for web or a proxy for mobile. Note each destination domain and the fields in the requests. This catches calls made by scripts loaded at runtime, such as tag managers, which a manifest scan will not show.
Angle 3: vendor accounts
Ask finance and procurement for the list of SaaS tools paid for, and ask each team which ones receive customer data. Cross check this against the first two lists. Shadow tools show up here.
What to record per recipient
- Vendor and product name.
- Data categories sent.
- Purpose and the activity it supports.
- Role: processor, or separate controller.
- Location of processing and transfer mechanism for data leaving the EU.
- Contract and data processing terms status.
- Deletion path when you stop using it.
- Owner and last review date.
Make it a gate
New SDKs should not ship without an entry. Put a check in code review: any new dependency that sends data off device requires a record. Review the list every quarter and remove vendors you no longer use, including revoking keys and requesting deletion.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the dependency list is built, and consider which of those packages talk to outside services.
Safeguard's SBOM and dependency scanning produces this kind of dependency inventory automatically. Deciding which entries are data recipients and what their contracts say still takes a person.
Quick check
Is every SDK a subprocessor?
No. Only those that process personal data on your behalf. Some act as their own controllers. Classify each one with your privacy lead.
How often should I review the list?
At least quarterly, and on every new integration or major SDK update.
Sources
Last reviewed: 19 October 2026.
