Start from what your software actually calls, not from the vendor spreadsheet. List dependencies, SDKs, cloud accounts and SaaS tools, mark which touch personal data, then record country, access paths and transfer mechanism for each. The EDPB says knowing your transfers is the essential first step.
Why start from code
Procurement lists miss tools a developer added with a credit card or an SDK that phones home. The EDPB suggests building on your Article 30 records, and notes you must include onward transfers by processors to sub-processors. Your dependency inventory shows the real set of third parties your code talks to.
Step by step
- Export the dependency list. Use an SBOM or a dependency scan for each service. Mark packages that are clients for external services, such as analytics, error tracking, payments, email, maps and AI APIs.
- List cloud and SaaS accounts. Pull the account list from finance and identity provider app lists. Compare with step one.
- Mark personal data. For each service, note whether personal data goes in, and which fields.
- Record location. Where is data stored and processed? Where do the vendor's staff and sub-processors sit?
- Record access paths. Include support access, since remote access from a third country counts as a transfer.
- Record the mechanism. Adequacy decision, standard clauses, binding corporate rules or other, with the date verified.
- Record supplementary measures. Encryption, minimisation, key custody.
- Set a review date. The EDPB expects re-evaluation at appropriate intervals.
A minimal record
Example entry for an error tracking SDK:
- Data: user ID, and email inside breadcrumbs.
- Storage location: as stated by the vendor, to be verified.
- Access paths: vendor support.
- Mechanism: to be confirmed with counsel.
- Measures: scrub email before sending.
- Next review: a dated reminder.
Keep it alive
A map that is correct in October is wrong by March. Tie it to change: a new dependency that talks to the network, a new SaaS account or a new region should trigger a review. A policy gate on new network dependencies in pull requests can help. See gate pull requests with policies.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into the inventory and look for packages that are clients for outside services. Those are your first transfer candidates.
Safeguard's SBOM and dependency scanning and asset discovery produce that kind of inventory. You can try a free scan at gold.safeguard.sh/scan.
Common surprises
Teams that build the map for the first time tend to find the same things. A marketing script that was added to the web app years ago. A mobile SDK that sends device identifiers to a vendor nobody reviewed. A webhook sending full customer records to a partner. A logging agent shipping to a default region. None of these were hidden on purpose. They just were never on a list.
Who owns it
Give the map one owner, usually in privacy or security, and make each product team responsible for its rows. The owner chases updates quarterly and after launches. Without an owner the map decays.
Quick check
Is a spreadsheet enough?
It can be, if it is complete and dated. The weak point is keeping it current, so tie updates to changes in code and vendors.
Sources
This is educational content, not legal advice.
Last reviewed: 19 October 2026.
