Vendor Dependency Teardown: Cloud, Region, and Edge to a Fault-Domain Map

This guide is for engineering managers, technical founders, and the risk partners who sign off with them. The job is to work out, from the outside, which cloud region, CDN, DNS, identity, messaging, and LLM providers a SaaS or API vendor actually runs on, before that vendor goes on your critical path. I take one vendor, TrustArc, through every step, wrong turns included. The guide ends with a dated dependency map and an explicit list of the fault domains the vendor shares with your own stack.

What goes into a vendor dependency map?

A vendor dependency map is a dated table with one row per layer: compute region, edge/CDN, DNS, identity, email/SMS, and LLM provider. Each row has a provider, a confidence label, and the evidence behind it. The map exists to answer one question: if a given provider or region fails, do you and the vendor go down together?

Two terms first. A fault domain is any component whose failure takes down everything that depends on it, such as a cloud region, a CDN feature, or a DNS control plane. A fourth party is your vendor's vendor. Fourth-party concentration risk is the risk you carry when you and your vendors depend on the same fourth party, so a single outage hits both ends of an integration at once.

Most maps skip the confidence label. It decides how much weight a row can carry in a risk review.

A map with honest unknowns is more useful than one where every row says "AWS". The unknowns become your question list for the vendor's security review.

Teardown, part one: what does the sub-processor list disclose?

The sub-processor list is the only place a vendor states its own dependencies in writing, so it comes first. TrustArc's list names its hosting region outright, which means the compute row is disclosed from step one.

TrustArc's public sub-processors page has five columns: Entity Name, Location, Purpose, Transfer Mechanism, and Sub-Processor Contact. For the platform, the location reads "US East-1 (N. Virginia, USA) or EU Central-1 (Frankfurt, Germany)". The page also lists two AI sub-processors: Amazon Bedrock AgentCore and Google Gemini.

Here is what I record from that, with the capture date:

• Compute region: AWS, us-east-1 or eu-central-1. Label: disclosed.
• LLM provider: Amazon Bedrock AgentCore and Google Gemini. The provider is disclosed. The region is disclosed only if that row states one.
• Every other row: entity, purpose, and location exactly as written. I don't interpret anything yet.

The first fork: "or" is not "and"

The wrong turn here is reading "US East-1 or EU Central-1" as a multi-region deployment. The word is "or". It says the vendor runs in two locations. It does not say your tenant is served from both, or that it fails over from one to the other. That is my reading of the wording, and the vendor's answer overrides it. Which region holds your data is a contract question, so ask it in writing. Until you get an answer, carry both regions on the map.

The second fork: how granular is the location?

Sub-processor lists don't share a format, and the granularity of the location column caps the label you can give. The same check produces "disclosed" for one vendor and "inferred" for the next.

Suzy's row is worth studying because it discloses a chain: a database service that itself runs on a hyperscaler. Whenever you see "via", put both providers on the map.

When the list sits behind an NDA trust portal

Some vendors gate the list. Trust-portal vendors openly advise teams to "require access requests, optionally gate it behind an NDA, and track every download", and another source notes "Sometimes the list is behind a login or an NDA request." Nobody has published how often this happens. If you hit a portal, request access and put the request date on the map. While you wait, run parts two and three, which need nothing from the vendor. Use the same request to ask the questions the list won't answer.

Subject: Sub-processor list and hosting detail for security review

Hi [name],

I'm reviewing [vendor] as a production dependency for [company]. I requested access to your sub-processor list through the trust portal on [date]. To finish the review, I need:

1. The current sub-processor list and the date it was last updated.
2. The cloud provider and named region that will host the [company] tenant, and whether it fails over to another region.
3. The CDN or edge provider in front of your app, API, and auth hostnames, and which edge features (for example bot management or WAF) sit in the request path.
4. Your authoritative DNS provider.
5. The identity provider behind customer login, and the email and SMS providers used for notifications or one-time codes.
6. The LLM providers that process customer data, and the region those calls run in.
7. How you notify customers of sub-processor changes, and the notice period.

Thanks,
[name]

Teardown, part two: how do you find out which cloud and region a vendor's hostnames run on?

Resolve each public hostname to its full CNAME chain and final IPs, then look those IPs up in the IP range files that the cloud providers publish. A match in a regional prefix gives you an observed region. A match in a global or edge prefix only tells you where the front door is.

A CNAME is a DNS record that makes one hostname an alias for another. The chain of aliases often names the CDN or cloud load balancer before you reach an IP. Resolve four hostnames, not one: the main app, the API, the auth or login host, and the status page. These are often served differently, and the status page in particular is often hosted somewhere else, which is exactly where you want it.

Each of the three hyperscalers publishes a machine-readable range file, and each file has a gap that produces false positives.

How to read a match from each provider:

• AWS. Each prefix has ip_prefix, region, network_border_group, and service. The region is either a named region or "GLOBAL", and AWS says GLOBAL traffic "can be attracted to or originate from multiple (up to all) AWS Regions." Prefixes overlap: the same /21 appears under AMAZON, S3, and EC2, and AWS notes it "may advertise a prefix in more specific ranges." Take the most specific prefix and the most specific service, not the first hit. The awsipranges library from aws-samples does the lookup if you'd rather not parse the JSON yourself.
• Azure. The Service Tags file has properties.region, platform, and systemService. The region is empty on cloud-wide tags such as the bare Storage tag, so a match there gives you the provider but not the region.
• Google. Filter cloud.json by scope (the region) and service. Don't use goog.json for attribution. Google describes it as "All routes (networks) which AS15169 provides reachability to from the Internet", which includes Google's own APIs, not only customer GCP space.

What the TrustArc pass can and cannot tell you

I'm not printing a resolution snapshot for TrustArc. DNS answers and range files change, and a snapshot printed in a reference document would be stale within weeks. Here is what each possible outcome would mean for this vendor:

• App IP in an AWS us-east-1 or eu-central-1 prefix: this corroborates the disclosure. The compute row becomes disclosed and observed.
• App IP in a GLOBAL prefix with service CLOUDFRONT: you have observed the edge, not the origin. The edge row reads AWS CloudFront, observed. It also adds a us-east-1 control-plane dependency, covered in the next section.
• App IP in a third-party CDN range such as Cloudflare: the edge is observed and the origin is hidden. The compute row rests on the disclosed value alone.
• API or auth host resolving straight to a regional prefix while the app sits behind a CDN: this is a commonly reported pattern, but it isn't verified as a rule. When it does happen, it is your best observed evidence for the origin.

One more limit: I found no primary-source write-up on identifying providers from CNAME naming patterns. A CNAME that "looks like" a provider is a lead to confirm with an IP match. It is never evidence by itself.

Why does a multi-region vendor still depend on us-east-1?

Several AWS services that look global run their control plane in a single region, and for most of them that region is us-east-1. A vendor can serve traffic from many regions and still be unable to change DNS, certificates, or CDN configuration while us-east-1 is impaired.

AWS documents this in its Fault Isolation Boundaries whitepaper: "Partitional services provide their control plane in a single AWS Region." The control plane is the part of a service that accepts configuration changes. The data plane is the part that serves traffic.

S3 has a similar dependency: "all calls to the CreateBucket and DeleteBucket APIs depend on us-east-1."

The data planes are built to survive. Route 53's data plane "runs across over 200 PoP locations as well as in each AWS Region," and its health checks run from eight AWS Regions, so existing DNS answers keep resolving. What breaks is the ability to change them, and changing DNS is exactly what a DNS-based failover runbook needs to do. During the 20 October us-east-1 outage, DynamoDB global table replicas in other regions stayed reachable, "though replication to and from the us-east-1 replica lagged." Data in many regions with a change path in one region is still a single-region dependency during incident response.

Now apply it to TrustArc. Say your tenant sits in eu-central-1. If part two observed CloudFront IPs or Route 53 nameservers on the vendor's hostnames, add an inferred us-east-1 dependency to the edge or DNS row and cite the whitepaper. If part two observed nothing from AWS at the edge, you have no grounds to add it.

I have not checked equivalent single-region control-plane documentation for Azure or GCP. If the vendor runs on either, read that provider's own fault-isolation guidance before assuming anything.

Who has the skills to run this trace?

Usually not the person whose title says vendor risk. The method needs someone who can read DNS output and range files, and in Refolk's index, people with third-party risk titles almost never list cloud skills.

In Refolk's index of professional profiles, 458 people in the US hold third-party or vendor risk analyst or manager titles, against 72 in the UK, a ratio of about 6.4 to 1. The role looks different in each country, and so do the employers.

The US sample is also concentrated. Bank of America (7) and Wells Fargo (6) account for 52% of the 25 profiles sampled. In other words, the title mostly sits in large-bank risk functions built around questionnaires and contracts.

These numbers have two limits. Profile skills are self-reported, so a missing tag doesn't prove a missing skill. And the shares come from samples of 25 per country, so they show the general picture, not precise proportions. The practical conclusion holds either way: pair the vendor-risk owner with an SRE or platform engineer for parts two through four, or hire someone who has both skills. Refolk lets you ask for that combination in plain English instead of stacking title and skill filters. The same kind of search can find a vendor's own infrastructure engineers, such as site reliability engineers at TrustArc with AWS experience, when you need to know who to ask about region placement during a security review.

Reading outage history: what does the vendor's status page admit?

Check the vendor's status-page history for the largest hyperscaler and CDN outages on record. A component that failed during a provider's outage is observed evidence of a dependency. A status page that stayed green tells you nothing either way, so record it as unknown.

Two well-documented reference events:

• AWS us-east-1, 20 October. AWS's post-event summary puts the start at 11:48 PM PDT on 19 October and the end at 2:20 PM PDT on 20 October. One status aggregator recorded disruption in 76 AWS components in N. Virginia alone, and outages in more than 2,000 of the 6,000 services it monitors, about a third. Another report counted only SaaS vendors that named AWS as the cause on their status pages. It found hundreds but published no exact count.
• Cloudflare, 18 November. Cloudflare began failing to deliver core traffic at 11:20 UTC, after a bot-management feature file grew from around 60 features to more than 200. One network-monitoring analysis found: "Not every service using Cloudflare experienced the outage. Failures appeared to be concentrated among services using Cloudflare's bot management feature." Nobody has published a count of status pages that confirmed Cloudflare impact.

What to record for each event:

1. Which components the vendor marked degraded, with timestamps compared against the provider's timeline.
2. Whether the vendor named the provider as the cause.
3. Whether the failed components match the layer you mapped. Login failures point at identity or edge. API failures point at compute.

The Cloudflare event should make your map more precise. "Uses Cloudflare" was not the fault domain that day. "Uses Cloudflare Bot Management" was. Wherever you can, record the CDN features in use, not just the CDN's name.

Nobody has studied publicly which status-page wordings reliably reveal a dependency. Treat a named cause as observed, a timing match without a named cause as inferred, and silence as unknown.

The procedure, step by step

These steps turn the TrustArc teardown into a procedure for any vendor. The time figures are rough desk estimates, not measurements: about 30 minutes each to pull the list, resolve DNS, and match IPs, and about 15 minutes to classify granularity.

Sources disagree on the order. Trust-centre vendors put the list first, while network-enrichment documentation starts from the IPs. I start with the list because it's quick and tells you which hostnames and providers to look for. If the list is gated, start at step 3 and come back to it.

How this goes wrong: failure modes and false positives

Most bad dependency maps fail the same way: evidence that proves one layer gets read as proof of another. For each failure below, I give what you see, why it misleads, and the check.

1. "GLOBAL" read as multi-region. A CloudFront IP resolves to region GLOBAL, and you conclude the vendor has no regional dependency. The data plane is global, but the control plane is in us-east-1. Check: compare the service against the whitepaper's control-plane list and add the anchor region as inferred.
2. The CDN hides the origin. A Cloudflare IP tells you about the edge and nothing about compute. Check: read the disclosed hosting row, and resolve the API and auth subdomains, which are often not proxied. That pattern is commonly reported but unverified, so only call an origin observed when its IP matches a regional prefix.
3. Overlapping prefixes. The same /21 appears under AMAZON, EC2, and S3. If you take the first match, compute gets labeled as generic AMAZON or as storage. Check: pick the most specific prefix and the most specific service tag.
4. A list that names entities, not regions. "Amazon Web Services Inc., Seattle" is a company address. Atlassian-style country lists are better but still aren't regions. Check: label these inferred or unknown, never disclosed.
5. A silent status page. Ring showed "No incidents reported today" during the AWS outage. Check: look at aggregator histories and the timing of any degraded components before writing "unaffected".
6. A goog.json false positive. An IP inside AS15169 may be a Google API the vendor calls, or a Google service, rather than the vendor's own GCP project. Check: attribute GCP only from cloud.json and its scope field.
7. Feature-scoped CDN impact. "Uses Cloudflare" does not mean "was down on 18 November", because failures clustered among Bot Management users. It also works the other way: a vendor that was fine that day may still run on Cloudflare. Check: record which edge features are in the request path.
8. Stale snapshot. Azure's Service Tags file is updated weekly, and AWS stamps each publication with a syncToken and createDate. A map without file versions can't be audited. Check: record the version with every match and re-run on a schedule.

Evidence that proves one layer is not evidence for the layer underneath it.

Writing the verdict and keeping the map current

The verdict lists the fault domains you share with the vendor, each with a label, plus the unknowns someone still owes you an answer on. Build a map of your own stack with the same layers first, then compare the two row by row.

Here is a worked verdict for TrustArc, for a reader whose own production runs in AWS us-east-1:

• Compute region: shared if your tenant is in US East-1 (disclosed). If the tenant is in eu-central-1, compute is not shared.
• LLM provider: Amazon Bedrock AgentCore puts AWS on the vendor's AI path. The provider is disclosed. The region isn't established unless the row states it.
• Edge and DNS: shared through the us-east-1 control plane only if step 4 observed CloudFront or Route 53 (inferred).
• Identity and email/SMS: unknown until the list or your own observation names a provider. These go on the question list.
• Google Gemini: a shared domain only if your own stack also depends on Google.

Vendor:
Captured on:
Captured by:
Range-file versions: AWS syncToken ___ createDate ___ | Azure changeNumber ___ | Google cloud.json fetched ___
Sub-processor list: public / gated (access requested on ___)

Layer | Provider | Region | Label | Evidence (source, date)
Compute region | | | disclosed / observed / inferred / unknown |
Edge / CDN (features in path) | | | |
DNS (provider, control-plane region) | | | |
Identity / auth | | | |
Email / SMS | | | |
LLM provider | | | |

Reference outages checked:
AWS us-east-1, 20 October: status page said ___ | aggregator said ___
Cloudflare, 18 November: status page said ___ | aggregator said ___

Shared fault domains with our stack:
1.
2.

Open unknowns and who owes the answer:
Next re-check date:

Keeping the map current

A dependency map starts going out of date the day you write it, so set up a way to hear about changes. GDPR sets no notice period for sub-processor changes and says nothing about what happens after an objection. In practice, 30 days is the usual contract term, and Common Paper's standard DPA sets a minimum of 10 business days. Read your own DPA for the actual number. Also, a vendor posting an updated list on its website is not the same as notifying you under Article 28(2). Subscribe to the change emails, and have a named person own them.

There is no published tooling standard for drift monitoring beyond those emails. Re-run steps 3 and 4 when a change notice arrives, at renewal, and after any major hyperscaler or CDN outage. Re-match against fresh range files each time, because Azure's file alone changes weekly.