How to build a subprocessor inventory that survives an audit

A subprocessor inventory is a living list of every third party that stores, processes or can reach your customer data, with a named owner, a review date, the data involved and the access it holds. To build one, pull from your expense records and identity provider rather than from memory, then confirm each entry with the team that actually uses the tool. Auditors will ask for it under the vendor management criteria, and enterprise buyers will ask for it during security review, so it needs to be accurate between audits, not just during them.

Why the list is usually wrong

In most readiness engagements we run, the subprocessor inventory is the weakest document in the folder. It gets assembled the week before fieldwork from someone's recollection of which contracts were signed, and it tends to capture infrastructure vendors while missing everything in marketing, support and sales operations. Those are often the tools with the broadest reach into customer records and the loosest permission model.

The recent ASOS breach is a plain illustration. Attackers used stolen employee credentials tied to a third-party communication platform and pushed rogue notifications to customers through the ASOS mobile app. The tool was not built by ASOS, and that distinction did nothing for them with customers or regulators. If a platform can speak to your users in your name, it is part of your attack surface whether or not your engineering team deployed it.

Where to find the vendors you forgot

Memory is the wrong source. Use records that are hard to argue with:

• Finance exports. Twelve months of corporate card and accounts payable lines, filtered for anything that looks like software. Shadow subscriptions show up here first.
• Identity provider logs. Every SAML and OAuth application connected to your SSO tenant, including ones nobody has signed into in months.
• OAuth grants in Google Workspace or Microsoft 365. Third-party apps users approved themselves, often with mailbox or drive scopes.
• API keys and webhooks in your product. Outbound integrations that move customer data to analytics, messaging or CRM platforms.
• DNS and email records. Sending domains and subdomains delegated to external platforms indicate who can mail or notify in your name.

What each row needs to contain

A list of vendor names is not an inventory. Each entry should carry the business owner by name, the data categories the vendor touches, whether that data includes personal information, the access method and scope, the region where data is stored, the date of the last security review, the next review date, and a link to the signed data processing agreement. Add a field for whether the vendor can send communications to your end users, because that group deserves tighter controls and shorter review cycles.

Tie the inventory to onboarding and offboarding. A new vendor gets added before the first payment clears, not at renewal. A departing employee triggers a check of any vendor console where they held a local account outside SSO, since credential theft of that kind is exactly what turned a marketing tool into a customer-facing incident at ASOS.

Keeping it current between audits

Set a quarterly reconciliation: re-pull the finance export and the SSO application list, diff them against the inventory, and assign any new rows an owner within a week. Review high-risk vendors annually and anything with customer-facing reach twice a year. Treat the review as a short evidence check, confirming the SOC 2 report or ISO certificate is current, permissions are still scoped to what the team needs, and no dormant admin accounts remain. Our SOC 2 readiness work usually starts here because the gaps found in this exercise predict the gaps found everywhere else.