DataResidencyMap — Per-Customer Residency Commitments vs Actual Storage
22 customer contracts × residency commitments (EU-only / US-only / no-restriction / China-only / KSA-only / UK-only / FedRAMP) vs actual storage location across our 12 data services. Surfaces 4 customers with data leaking to non-contracted regions + 2 ambiguous contracts (no residency clause negotiated).
What it is
The artifact that catches residency drift between contract negotiations + production reality. Sales promises EU-only at signing; engineering deploys ML training to a US warehouse; nobody reconciles.
What’s in it
- 22 customers × 12 data services
- Per customer: contracted region, actual storage per service, gap detection
- Worst-offender: Initech EU-only contract with ml-training data leaking to US (DataLineage DL-024 cross-ref); Stark Industries with Sentry errors flowing to US; UK FS customer with ml-training in EU (post-Brexit clause); Stark + 1 more with Sentry-EU misconfiguration; ambiguous contracts (LegacyCorp, LongTail Inc) with no residency clause negotiated
- Region coverage: EU-only / US-only / UK-only (Brexit) / China-only (CSL/DSL/PIPL separate-tenant) / KSA-only (PDPL → Bahrain ME region) / GovCloud / no-restriction
Why this shape
GDPR Art 44-49 + US CLOUD Act + China CSL/DSL/PIPL + Russia FZ-152 + Saudi PDPL all impose data-residency obligations. The killer audit finding: a customer’s data flowing to a region their contract prohibits. DataResidencyMap surfaces it before the customer’s compliance review does.
How it ships
Single HTML file, ~14KB. Zero dependencies. 22 customers × 12 services × per-cell residency in 130 lines of vanilla JavaScript.