Руководство EU-разработчика по соответствию API карт требованиям GDPR

You have chosen a EU-based data centre for your map API. The servers are in Frankfurt. The contract says "EU data residency." You close the GDPR compliance checklist confident that you are covered.

You are not covered.

This is the compliance gap that catches EU developers and CTOs off guard every year, and it has gotten more consequential since the Schrems II ruling invalidated Privacy Shield and placed heightened scrutiny on transatlantic data flows. If your map API is provided by a US company, regardless of where their servers sit, your users' location data may be accessible to the US government under the CLOUD Act. Under GDPR, that is a potential breach. Under a DPA audit, it is a finding.

This guide explains the actual GDPR requirements for map API usage, why data residency alone is not enough, what the CLOUD Act risk means in practice, and how to evaluate any map API vendor against a rigorous compliance checklist. It is the guide US-based mapping companies cannot credibly write, because they cannot pass their own checklist.

Why Location Data Requires Serious GDPR Attention

Location data sits at the intersection of personal data and sensitive data under GDPR, depending on context. Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. An IP address, which every map tile request sends to the API provider, is personal data. A geocoding query containing a home address is personal data. GPS coordinates, if collected, can be used to infer home address, workplace, religious attendance, medical appointments, and political activity, potentially qualifying as sensitive data under Article 9.

When your web application or mobile app loads a map, fires a geocoding search, or calculates a route, it sends these data points to your map API provider. Your users did not consent to sharing their location with a company in San Francisco. They consented to using your product. You, as the data controller, are responsible for ensuring that every sub-processor handling that data meets GDPR requirements.

If your map API provider fails the compliance test, you fail it too.

The CLOUD Act Problem: Why US Providers Cannot Claim Full GDPR Compliance

The Clarifying Lawful Overseas Use of Data (CLOUD) Act, passed by the US Congress in 2018, requires US technology companies to comply with lawful US government orders to produce data, regardless of where that data is physically stored. A US company with a server in Frankfurt is still a US company. If a US court or federal agency issues a valid CLOUD Act demand, the company must comply.

This creates a direct conflict with GDPR. Article 48 of GDPR prohibits transferring personal data to foreign authorities or courts without an appropriate legal basis under EU law. The European Data Protection Board has been explicit: compliance with a CLOUD Act demand, without a valid EU legal basis, would constitute a GDPR violation.

The practical consequence for EU developers is stark:

• Google Maps Platform, operated by Google LLC (a US company), is subject to CLOUD Act obligations even when serving requests through European data centres.
• Mapbox, incorporated in the United States, faces the same structural exposure.
• No amount of contractual language or EU Standard Contractual Clauses changes the underlying legal jurisdiction of the company providing the service.

This does not mean these companies are recklessly sharing your data. In practice, CLOUD Act demands are targeted at law enforcement use cases, not routine commercial data. But the legal exposure exists, and a serious DPA audit will identify it. Regulated industries, healthcare, finance, legal services, cannot accept this exposure at all.

[Image: A diagram showing two scenarios, "US company, EU servers" (still has CLOUD Act arrow pointing to US government) vs "EU company, EU servers" (arrow blocked, no CLOUD Act exposure)]

Data Residency vs. Data Sovereignty: Understanding the Difference

These terms are often used interchangeably in sales conversations, but they mean different things:

Data residency means your data is stored in a specific geographic location. A US provider offering "EU data residency" stores data on servers in Ireland or Germany. The physical location is EU. The legal jurisdiction is not.

Data sovereignty means your data is subject to the laws of a specific jurisdiction. For EU data to be truly sovereign, it must be controlled by an entity subject to EU law, not just stored on EU soil by a US parent company.

True GDPR compliance for map APIs requires data sovereignty, not just data residency. The distinction matters most when:

• Your application handles data for healthcare patients, financial service users, or other regulated categories
• You operate in a sector that faces formal DPA audits (banking, insurance, public sector)
• Your CISO or legal team reviews sub-processor agreements with actual scrutiny
• You face a data subject access request or a breach notification obligation

For most consumer-facing applications, the practical risk of a CLOUD Act demand is low. But compliance is not a probability calculation. Either you are compliant or you are not.

The Practical GDPR Checklist for Evaluating Map API Vendors

Use this checklist when evaluating any map API provider for GDPR compliance:

Legal Entity and Jurisdiction

• Is the API provider incorporated as a legal entity in the EU or EEA?
• Is the parent company (if any) also within EU jurisdiction, with no US-incorporated parent?
• Does the provider explicitly confirm no CLOUD Act exposure in their DPA?

Data Processing Agreement

• Does the provider offer a comprehensive DPA that references specific GDPR articles?
• Does the DPA identify the categories of personal data processed (IP addresses, query strings, coordinates)?
• Does the DPA specify data retention periods and deletion obligations?
• Are sub-processors listed, and are they also EU-jurisdiction entities?
• Does the DPA address breach notification timelines (GDPR requires 72 hours)?

Data Storage and Processing

• Is all data stored and processed within the EU, with documented no third-country transfers?
• Is data transfer between services (CDN, analytics, support tools) documented and GDPR-compliant?
• Does the provider offer data residency selection at the account level?

Security Certifications

• Is the provider ISO 27001 certified (the international standard for information security management)?
• Does the provider undergo regular third-party security audits?
• Is there a documented vulnerability disclosure and patch management process?

User Rights and Control

• Can you configure the API to minimise data collection (e.g., anonymised IP, no analytics tracking)?
• Does the provider support data subject access requests and deletion requests?
• Are there documented processes for responding to regulatory enquiries from EU DPAs?

MapAtlas: Built for EU Data Sovereignty from Day One

MapAtlas is a European mapping API platform, operated by MapMetrics, an EU-incorporated company. Our infrastructure runs within EU jurisdiction with no US parent company and no CLOUD Act exposure. ISO 27001 certification is in place, and our DPA documents specific data categories, retention policies, and sub-processor commitments.

This is not a US company that has added EU data centre options. It is an EU company where EU compliance is the default architecture, not an add-on.

Our map visualisation and styling API processes tile requests through EU infrastructure. Geocoding queries, route calculations, and every other API call stay within EU jurisdiction from the moment they leave your application. The DPA reflects this, it is not boilerplate adapted from a US legal template.

For developers building applications in regulated sectors, or for any EU business that wants genuine compliance rather than performative compliance, this distinction is material.

Comparing Map API Providers on GDPR Compliance

For a full pricing and feature comparison, see our breakdowns of MapAtlas vs. Google Maps and Mapbox vs. MapAtlas. If cost is also a concern, see Google Maps API pricing in 2026, the compliance gap comes on top of significant price differences.

[Image: A stylised view of a Data Processing Agreement document with key sections, data categories, retention periods, sub-processors, annotated with GDPR article references]

Practical Steps for EU Developers Right Now

If you are currently using a US map API provider and cannot immediately switch, here are interim steps to reduce your exposure:

1. Anonymise IP addresses before they leave your origin. Some map APIs allow you to pass requests through your own server, stripping or hashing IP addresses before they reach the third-party API. This does not fully resolve the CLOUD Act issue, but it reduces the personal data surface.

2. Audit what your map API actually collects. Read the provider's privacy policy and DPA carefully. Identify every category of personal data they receive from your users. Document this in your own data mapping register.

3. Update your privacy notice. Your privacy notice must disclose sub-processors who receive personal data. If you use Google Maps, Google LLC is a sub-processor. Your users are entitled to know this.

4. Assess the risk level of your use case. A marketing website displaying a static office location map has a very different risk profile from a healthcare application routing patients to clinics. Calibrate your urgency accordingly.

5. Evaluate migration costs realistically. Switching map APIs is a technical task, not a business-transforming project. Most migrations complete in a sprint or two. Our pricing page shows the cost comparison, and our documentation covers the technical migration path from Google Maps and Mapbox.

The EU's data protection framework is the most comprehensive in the world, and it is being actively enforced, €1.3 billion in GDPR fines were issued in 2023 alone. Location data is personal data. Map APIs process location data. The compliance chain runs directly from your users to your API provider. Verify every link in that chain. And if a link cannot pass the checklist above, replace it with one that can.