When a scheduling vendor consolidates its regional environments, every customer built on that region inherits a decision they did not make. Booking data that lived in one jurisdiction moves to another, the sub-processor terms change, and the engineering team finds out through a migration email.
That situation is common enough to plan for. Scheduling and calendar features touch some of the most sensitive personal data in a product, and where that data sits is usually written into a contract someone signed two years ago. This is a guide to what European data residency actually requires, what it does not, and what to confirm before you build a scheduling feature or move one.
European data residency generally refers to storing personal data in a designated European hosting region. It is not the same as GDPR compliance, and GDPR does not require it. What creates a genuine EU or EEA storage requirement is usually a customer contract, a public sector tender, or sector regulation, not the regulation itself.
What is data residency, and how is it different from compliance?
Data residency is a statement about geography. It answers one question: in which country do the servers storing this data physically sit?
Compliance is a separate question. It answers whether the processing of that data meets a legal standard, wherever the servers are.
The two get treated as one thing, and that causes bad architecture decisions in both directions. Teams assume a vendor with the right certifications satisfies a residency requirement. Teams also assume a vendor storing data outside the EU cannot support their compliance obligations. Neither follows.
Does GDPR require storing personal data in the EU?
No. GDPR does not mandate that personal data be stored inside the EU or EEA.
What it regulates is transfer. Under Chapter V, personal data can move to a country outside the EEA when an appropriate legal mechanism exists. The most straightforward is an adequacy decision, where the European Commission determines that a country’s protections are essentially equivalent to the EU’s. Where no adequacy decision applies, transfers rely on Standard Contractual Clauses, binding corporate rules, or another Article 46 safeguard, usually paired with a transfer impact assessment.
A vendor storing EEA personal data in a country covered by an adequacy decision can support a GDPR-compliant transfer framework, provided the broader processing arrangement also meets applicable GDPR requirements. A vendor storing data inside Germany can still leave you exposed if its processing basis, retention, or sub-processor chain is wrong.
What creates an EU or EEA data storage requirement?
If GDPR does not create the requirement, something else usually does. In practice it comes from one of five places:
- Customer contracts. An enterprise DPA specifying EU or EEA storage. This is the most common source and the one most often forgotten until renewal.
- Public sector procurement. National and municipal tenders across Germany, France, the Netherlands, and the Nordics frequently specify in-country or in-EU hosting as a threshold requirement rather than a preference.
- Sector regulation. Financial services subject to DORA and related national regulatory or supervisory requirements, health data under member state rules that sit on top of GDPR, and legal or defense work with their own constraints.
- Works council and employee data agreements. In Germany in particular, a Betriebsrat agreement covering employee calendar data can specify storage location independently of what GDPR requires.
- Internal policy. Security teams that set a residency standard as a simplifying rule so they do not have to run a transfer assessment on every vendor.
The distinction matters when you are evaluating options. A requirement sourced from a signed DPA is a hard constraint. A requirement sourced from internal policy can sometimes be satisfied with documentation instead of a migration.
What personal data does a scheduling feature store?
A scheduling or calendar feature typically stores attendee names and email addresses, meeting titles and descriptions, free/busy windows, booking form responses, and conferencing links. Residency conversations tend to get abstract, so it helps to be specific:
- Attendee names and email addresses, including external attendees who never agreed to your terms
- Meeting titles and descriptions, which routinely carry deal names, candidate names, patient references, and case numbers
- Free/busy windows, which reveal working patterns and location
- Booking form responses, which can include phone numbers, addresses, and free-text notes
- Conferencing links and, where recording is enabled, transcripts
Meeting titles are the field that surprises security reviewers. A calendar full of entries like “Interview: [candidate name]” or “[Client] settlement discussion” is a personal data store with a low-friction interface, and it usually has not been classified as one.
Does your vendor’s support team location matter for data residency?
Storage location gets the attention, and support access rarely does. Depending on the issue and the support procedures involved, a support investigation may require access to affected customer data or related diagnostic information. If that engineer sits outside the EEA, the investigation itself can constitute a transfer, regardless of where the data is stored at rest.
This is the gap most vendor evaluations miss. A regional data center paired with a follow-the-sun support model routing tickets through three continents does not deliver what the residency clause was written to protect. It also shows up practically: a team operating in a distant time zone means incident response that starts the next morning, not the same afternoon.
Nylas maintains support capabilities for customers using its European region. Customers with specific requirements concerning support access locations should confirm those requirements with their Nylas representative.
Questions to ask a scheduling or calendar vendor
Ask these before you build, and again before you accept a migration:
- In which specific country are the servers storing end user data located? Not the region name, the country.
- Are regions isolated, or can data move between them under failover, backup, or support access?
- Where does account metadata, authentication, and logging live, separately from end user data?
- Which sub-processors touch the data, in which countries, and how much notice is given before that list changes?
- In which countries are your support and engineering staff located, and can they access production data during an investigation?
- What is the notice period and process if you consolidate or retire a region?
- Can data be exported in a usable format, and what is the retention period after termination?
- Does regional choice carry a price premium or a plan gate?
Question three catches more issues than the rest combined. Plenty of platforms store end user data regionally while routing dashboard authentication, audit logs, or support tooling through a single global environment.
What happens when a vendor consolidates data regions?
Region migrations require re-authentication and remapping, because isolated regions use isolated identifiers. Expect most or all of the following:
- New object and account identifiers, so any ID your application stores directly must be remapped
- End user re-authentication, since access grants generally do not transfer across isolated environments
- Webhook and SDK reconfiguration against new regional endpoints
- An updated DPA and sub-processor list, which may need to go back through your customers’ review
- A window where duplicate records exist in both environments until the old ones are deleted
The engineering work is manageable. The part that takes longer is the contractual work, because if your own customers hold you to a residency term, your vendor’s move becomes your notification obligation. Budget for that conversation earlier than feels necessary.
Where Nylas fits
Nylas offers data residency in two isolated application-data regions: the United States and Europe, with the European region hosted in London. Applications are created per region against a regional API endpoint, and using multiple data centers carries no additional platform fee. Application data, connector data, and grant information are stored in the region selected for the applicable Nylas application. Nylas organization and Dashboard-user information is stored in London, including authorization processing for U.S. Dashboard users.
The London point deserves a direct answer rather than a vague one. Because the UK is outside the EEA, transferring EEA personal data to the London region constitutes an international transfer under GDPR. That transfer is covered by adequacy: the European Commission renewed its UK adequacy decisions on 19 December 2025 for a further six-year period. For customers relying on GDPR transfer rules, the UK adequacy decision provides a recognized transfer mechanism. It does not, however, satisfy a contractual or procurement requirement that specifically mandates storage within the EU or EEA. For buyers whose contract or tender specifies EU or EEA storage as a literal term, London does not satisfy it, and the honest answer is to check the wording of the clause before assuming either way. Nylas previously hosted its European region in Ireland and migrated its European application hosting to London as part of a broader platform migration to Google Cloud.
The second consideration is architectural. Scheduling is rarely the only communications surface in a product. Teams that separate scheduling, email sync, and contacts across different vendors end up with residency decisions in three places, three DPAs, and three sets of sub-processors to track. Nylas covers email, calendar, contacts, and scheduling through one integration across 250+ providers, which can reduce the number of separate residency, subprocessor, and contractual assessments customers need to manage.
Nylas has successfully completed a SOC 2 Type II examination, maintains ISO 27001 and ISO 27701 certifications, and undergoes independent HIPAA assessments. The Nylas Platform is designed with security and privacy controls that help customers support their obligations under applicable privacy laws, including GDPR and the CCPA/CPRA.
If you are evaluating where your scheduling data should live, talk to our team about your specific residency requirements before you commit to an architecture.
Frequently asked questions
Does GDPR require storing personal data in the EU?
No. GDPR regulates the legal basis for processing and the mechanism for international transfers, not the physical storage location. Data can be stored outside the EEA under an adequacy decision or an Article 46 safeguard such as Standard Contractual Clauses.
Is the UK still adequate for EU personal data transfers?
Yes. The European Commission renewed the UK adequacy decisions under the GDPR and the Law Enforcement Directive on 19 December 2025. The renewed decisions carry a six year sunset clause running to 27 December 2031.
Does my vendor’s support team location matter for GDPR?
Potentially. Remote access to EEA personal data from outside the EEA may constitute an international transfer and should be covered by an appropriate transfer mechanism and contractual safeguards. Ask where support and engineering personnel may access production data and what controls apply.
What happens to my scheduling data if my vendor shuts down its EU instance?
Migration paths vary by vendor. Cal.com has announced that Cal.eu will shut down on 1 November 2026, with enterprise customers retaining access for their contracted period, and has stated that migration is opt-in and that users who decline can export their data. If you are affected by any regional consolidation, confirm the export format, the retention window, and whether your own customer contracts require you to give notice.
Can I keep some users in Europe and some in the US?
Yes, if your vendor supports isolated regional applications. Your application needs to know which region each user belongs to and query the matching regional endpoint. Plan for this in your data model early, because retrofitting region awareness after launch is significantly more work.
Does regional data residency cost more?
It depends on the vendor. Some gate multi-region storage behind higher tiers. With Nylas, using multiple data centers carries no additional platform fee.
Sources
Email and Contacts API 
Calendar API & Scheduler 
Notetaker API 
Agent Accounts 
Sales & CRM 
Recruiting & ATS 
Healthcare
Financial
Legal
Real Estate
Education
Field Services
Docs
SDKs
Guides
Integrations
API status
Changelog
Support
Enterprise
