Data Residency and GDPR - What Document Processing Vendors Must Tell You

Data residency affects how businesses assess GDPR obligations, but EU-only storage is not a GDPR requirement. This article explains what data residency means, how international transfers work under the GDPR, what to verify with document processing vendors, and why storage location is only one part of the data journey.

Key Takeaways

• GDPR does not require EU-only data storage. Transfers outside the EEA are permitted when GDPR requirements are met.
• Data residency goes beyond storage. Check processing locations, subprocessors, backups, retention, and international transfers.
• Parseur processes and stores customer data in the EU and publishes information on subprocessors, retention, encryption, and data processing terms.

The GDPR does not require personal data to stay inside the EU. It restricts transfers of personal data outside the European Economic Area (EEA) unless the GDPR's international-transfer rules are met, such as through an adequacy decision, appropriate safeguards like Standard Contractual Clauses (SCCs), or a specific derogation under Articles 44-49.

The location of business data matters increasingly as more organizations rely on third-party cloud infrastructure. In 2025, 52.7% of EU enterprises used paid cloud computing services, and 71.5% of those cloud users used them for file storage, according to Eurostat.

For businesses sending invoices, identity documents, contracts, emails, and other files to document processing providers, the relevant question goes beyond server location. They also need to know where documents are processed, whether other providers receive the data, where copies are retained, and whether personal data crosses an EEA boundary.

Data residency may simplify some compliance questions, but it is not a substitute for GDPR compliance. Keeping document processing and storage within the EEA may reduce international-transfer considerations, but organizations still need to assess the rest of the data lifecycle.

What Data Residency Actually Means

Data residency means the physical location where an organization stores and processes its data. For document workflows, checking storage location alone is not enough. A document may be stored on a server in one country while being accessed, processed, or transferred through infrastructure elsewhere, so residency claims need to cover the full data flow.

Under Article 4(2) of the GDPR, processing covers far more than saving information to disk. It includes operations such as collecting, retrieving, consulting, using, transmitting, and erasing personal data.

Consider a company that uploads an invoice to infrastructure located in the EU. The server location tells the company where it stores the document. It does not necessarily reveal whether another OCR, AI, backup, or integration service receives its contents during processing.

This is why a statement such as "your data is stored in the EU" does not answer the entire data residency question.

Businesses evaluating a vendor should establish at least:

• where uploaded documents are stored
• where document data is processed
• whether data moves to other locations during processing
• which subprocessors receive or process the data
• what happens to the documents and extracted data after processing

For document automation, the useful question is not simply "Where is my data stored?" It is "Where does my data go from upload to processing, storage, transfer, and deletion?"

That full path determines what your organization needs to examine when assessing a vendor's data residency claims and their implications under the GDPR.

Data Residency vs. Data Sovereignty vs. Data Localization

Data residency describes where data is physically stored or processed. Data sovereignty concerns which country's laws and legal authorities apply to that data. Data localization goes further by legally requiring certain data to remain within a specific country or jurisdiction. The terms overlap, but they are not interchangeable.

The difference matters when assessing GDPR compliance. Choosing EU or EEA data residency does not automatically settle every question about applicable law, access, subprocessors, or international transfers. Likewise, the GDPR should not be described as a general data localization law that requires all personal data to remain inside the EU.

For a business evaluating a document processing vendor, "Where are your servers?" is therefore only the starting point. The business also needs to understand where it processes documents, whether personal data moves to other jurisdictions, which subprocessors participate in that processing, and what safeguards apply when an international transfer occurs.

Keeping these three concepts separate makes vendor claims easier to evaluate. Residency tells you where the data is handled. Sovereignty concerns the legal jurisdictions that may reach it. Localization tells you whether applicable law requires the data to stay in a specific place.

What GDPR Actually Requires About Location

The GDPR does not require organizations to keep personal data inside the EU or EEA. Chapter V permits transfers to third countries when the required protections are in place. Depending on the destination and circumstances, those protections may include an adequacy decision, Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), or a limited Article 49 derogation.

Articles 44-49 of the GDPR set the rules for international transfers of personal data. Article 44 establishes the basic principle: transferring personal data to a third country must not undermine the level of protection guaranteed by the GDPR.

In practical terms, organizations have several routes for transferring personal data outside the EEA. Under Article 45, the European Commission may decide that a country, territory, sector, or international organization offers an adequate level of data protection, and transfers covered by that decision do not require a separate authorization. In the absence of an adequacy decision, organizations may use Commission-approved Standard Contractual Clauses (SCCs) as an appropriate safeguard under Article 46. Article 47 allows multinational groups to establish Binding Corporate Rules (BCRs) for transfers within the group. Article 49 permits certain transfers in specific circumstances when the relevant conditions are satisfied, though these derogations are not a general replacement for a regular transfer mechanism.

The important distinction is that GDPR regulates transfers rather than imposing a blanket EU data localization rule. An organization may process personal data outside the EEA, but it must determine whether Chapter V applies and, if so, establish an appropriate transfer basis.

Why the EU-US Data Privacy Framework deserves attention in 2026

The EU-US Data Privacy Framework (DPF) illustrates why businesses should understand the transfer mechanisms their vendors rely on.

The European Commission adopted its adequacy decision for the DPF on 10 July 2023. It permits personal data to flow from the EU to participating US organizations certified under the framework without another transfer mechanism being required for those covered transfers.

The framework has since faced legal scrutiny. In September 2025, the EU General Court dismissed Philippe Latombe's action seeking annulment of the adequacy decision. Latombe appealed that judgment on 31 October 2025. The appeal, Case C-703/25 P, Latombe v Commission, remains listed as pending before the Court of Justice of the European Union as of September 2026.

A separate US development has also attracted attention from European regulators. Following the US Supreme Court's 2026 decision in Trump v. Slaughter, the European Data Protection Board (EDPB) asked the European Commission to assess the judgment's implications for the EU-US Data Privacy Framework, particularly questions concerning independent supervision.

The DPF has not been suspended, revoked, or invalidated. The EU-US adequacy decision remains in force as of September 2026.

For procurement teams, the practical lesson is not to predict the outcome of pending proceedings. Instead, understand which transfer mechanisms a vendor relies on and what alternative arrangements would apply if the legal position changed.

Keeping document processing and storage within the EEA removes that particular DPF dependency from the workflow. It does not remove an organization's other GDPR obligations, including legal basis, processor contracts, security, retention, data subject rights, and appropriate oversight of subprocessors.

Where Document Processing Gets Complicated

Document processing creates data residency questions that are easy to miss because a single file may contain far more personal data than the workflow intends to extract. OCR, AI services, email ingestion, integrations, backups, and recovery systems may also introduce additional processing locations. Businesses therefore need to map the document's full path, not only its primary storage location.

A database makes it relatively easy to identify which fields contain personal data. Documents are less predictable. An accounts payable team may only want an invoice number, total, and due date, while the source PDF contains names, addresses, account information, signatures, and other personal data.

The entire document may still enter the processing workflow.

Documents carry more personal data than you asked for

An invoice is not simply a collection of the fields your accounting system needs. The PDF may contain a contact person's name, billing and delivery addresses, bank details, email addresses, telephone numbers, signatures, customer references, and, depending on the document, identification numbers.

The same problem appears across other document types. An identity document may contain information irrelevant to the intended extraction. A contract may include personal details buried several pages away from the clauses or fields a business wants to capture.

This matters because GDPR obligations concern the personal data being processed, not only the fields eventually returned as structured output.

When assessing a document processing vendor, identify what enters the system and what comes out. If you upload a complete document, the data flow assessment should account for the complete document wherever it is processed.

OCR and AI extraction may add another processing location

OCR and AI-based extraction may involve infrastructure beyond a vendor's primary application or storage environment.

Some document processing providers use third-party OCR, cloud, or AI services. When they do, another processor, subprocessor, or processing location may become part of the data flow.

Procurement teams should establish:

• where AI and OCR processing occurs
• what document data a third party receives
• whether that provider retains the data
• whether customer content may be used for model training or improvement
• which transfer mechanism applies if personal data leaves the EEA

For AI document processing, inference location deserves the same scrutiny as storage location.

Attachments, email ingestion, and webhooks each create a hop

Document automation rarely consists of one upload followed by one download. A production workflow may begin with an email attachment, pass through a document processing platform, and send structured results to an accounting system, CRM, spreadsheet, API, automation platform, or another application.

Each step deserves attention.

Consider a simple invoice automation workflow: incoming email, then attachment ingestion, then document processing, then structured data, then webhook or integration, then the destination system.

The important compliance question is where personal data travels at every stage. The processing vendor's infrastructure is only one part of that chain.

Email providers may already process the original attachment. A document processing service receives and processes it. A webhook then sends extracted data to another system. That destination may have its own hosting locations, subprocessors, retention policies, and international transfer arrangements.

Mapping the complete path gives compliance and security teams a more useful picture than checking a single server region.

Backups and disaster recovery replicas matter too

A vendor's primary hosting region does not necessarily tell you where every copy of the data exists. Backup systems, disaster recovery infrastructure, replicas, logs, and other supporting systems may be in different locations than the primary application.

For example, imagine a provider stores its primary document data on servers in Frankfurt but replicates the same personal data to a backup environment in a US data center. The EU location of the primary server does not remove the need to examine the transfer of personal data to the US backup environment.

This is why residency reviews should cover more than production servers.

Ask vendors where relevant backups and replicas are located, whether those copies contain document content or personal data, how long they are retained, and whether recovery processes could move data into another jurisdiction.

The practical goal is a complete data-flow map: where the original document enters, every location where its data is processed, every third party that receives it, where copies are stored, where structured output goes, and when each copy is deleted.

For document automation, that map tells you considerably more than a checkbox marked "EU hosting."

Does Your Vendor Train AI on Your Documents?

Data residency does not tell you whether a vendor uses your documents to train AI models. A service may process and store data entirely within the EEA while still having contractual rights to reuse customer content for model training or improvement. Check the vendor's AI data policy and contract separately from its hosting location.

This distinction matters as more document processing platforms add AI-based extraction. Where AI inference happens and what happens to the data afterward are separate questions.

For example, a vendor might process an invoice on EU-hosted infrastructure. That answers part of the residency question. It does not tell you whether the invoice, extracted fields, prompts, or other customer data are retained for model improvement or used to train a vendor's or third party's models.

The reverse is also possible. A provider may contractually prohibit using customer documents for AI training while processing some data outside the EEA under an applicable GDPR transfer mechanism.

When evaluating an AI document processing vendor, ask:

• Does the vendor use customer documents or extracted data to train its own AI models?
• Does it use customer data to improve, evaluate, or fine-tune models?
• Do third-party AI or OCR providers receive document content?
• Can those third parties retain or use the data to train their models?
• What do the contract, DPA, privacy terms, and subprocessor disclosures say about these uses?
• Is any opt-out available, and is the restriction contractual or merely a configurable setting?

Do not rely on phrases such as "EU hosted," "GDPR compliant," or "your data is private" to answer these questions. Look for explicit terms governing the use of customer content.

For businesses processing invoices, identity documents, contracts, emails, or other files containing personal or confidential information, the distinction is straightforward: data residency tells you where the data goes. The vendor's AI data policy tells you what the vendor and its providers may do with it.

Both need to be verified independently.

How to Verify a Vendor's Data Residency Claims

To verify a vendor's data residency claims, ask for evidence covering the entire document lifecycle: processing locations, subprocessors, AI and OCR services, backups, retention, deletion, security, and international transfers. A statement such as "EU hosted" is not enough. The vendor should document where personal data goes and what protections apply at each stage.

Use this checklist when evaluating a document processing vendor.

1. Get the data center country in writing. Ask where your documents and extracted data are stored and processed. "EU region" is not specific enough because storage and processing may happen in different countries.

2. Check the subprocessor list. Review which subprocessors handle personal data, what they do, and where they operate. Under Article 28(2) of the GDPR, processors must also meet requirements around changes to subprocessors.

3. Read the DPA and transfer terms. Ask for a Data Processing Agreement (DPA), not just a privacy policy. If data leaves the EEA, check which transfer mechanism applies, such as an adequacy decision or Standard Contractual Clauses (SCCs).

4. Ask where AI and OCR processing happens. Find out where AI and OCR providers process your documents. EU storage does not necessarily mean EU-only processing. Also check whether the vendor or its providers use customer content for AI training or model improvement.

5. Identify backup and replica locations. Ask where backups, disaster recovery copies, and replicas are stored. If personal data is copied from an EEA server to infrastructure outside the EEA, assess that transfer as well.

6. Verify retention and deletion controls. Check how long the vendor keeps documents, extracted data, logs, and backups. Ask whether you can configure retention and how long deletion takes across both active systems and backups.

7. Check breach notification terms. Review how quickly the vendor must tell you about a personal data breach. Under GDPR Article 33(2), processors must notify controllers without undue delay. The separate 72-hour requirement generally applies to qualifying notifications from controllers to supervisory authorities.

8. Identify the relevant supervisory authority. Ask which data protection supervisory authority is relevant to the vendor. Do not assume the server location alone determines the answer.

9. Verify security certifications and testing. Check the vendor's current certifications, such as ISO 27001 or SOC 2, including their scope and status. Also review encryption, penetration testing, access controls, vulnerability management, and how the vendor addresses security findings.

10. Ask what happens when the contract ends. Find out whether your documents, extracted data, backups, and account data are returned or deleted after termination. The DPA should clearly explain the process and relevant deletion timelines.

A credible residency review should leave your team with a map rather than a marketing claim: where documents enter the service, where they are processed, who else receives them, where copies exist, how international transfers are protected, and when the data disappears.

If a vendor cannot answer those questions clearly and in writing, your organization does not yet have enough information to verify its data residency requirements.

How Parseur Handles GDPR-Compliant Document Storage

Parseur processes and stores customer data in the European Union, encrypts data at rest using AES-256, and publishes its subprocessor list. Customers control document retention at the mailbox level, and Parseur removes deleted personal data from active systems immediately and from backups within 45 days. Parseur identifies the Irish Data Protection Commission as its lead EU supervisory authority. Parseur is also SOC 2 Type II compliant.

Parseur's hosting data center complies with ISO 27001, and it encrypts data at rest with AES-256 and in transit with TLS 1.2 or above. Parseur also publishes a subprocessor list showing each provider's purpose, data involved, processing and storage location, and transfer mechanism where relevant.

Retention is configurable for each mailbox. The default is 90 days, and customers can set retention as low as one day. Parseur also offers a Process Then Delete option that deletes a document after it has been parsed and its extracted data sent to the customer's systems.

Customers may also delete their data directly. Parseur states that it immediately and irrevocably removes deleted personal data from active systems and removes it from backups within a maximum of 45 days. Its DPA names the Irish Data Protection Commission (DPC) as the competent supervisory authority where the EU GDPR applies.

Parseur lets customers define the fields they want returned as structured data, such as InvoiceNumber, Total, or DueDate. That lets teams limit their structured output to the information required by the downstream workflow.

For teams comparing GDPR-compliant document storage options, these controls make the earlier checklist concrete: verify the processing locations, subprocessors, encryption, retention and deletion terms, and contractual documentation rather than relying on a GDPR badge alone.

This article is general information about data residency and GDPR concepts. It is not legal advice. Organizations should consult qualified counsel about their specific compliance obligations.

Conclusion

Data residency matters under the GDPR, but the important question is not simply whether a vendor stores data in the EU. Businesses need to understand the complete journey of their documents, including where data is processed, which subprocessors receive it, where backups are kept, how international transfers are protected, and when copies are deleted.

That is particularly important for document automation because a single invoice, contract, email, or identity document may contain personal data beyond the fields a business intends to extract.

A clear data-flow map makes those questions easier to answer. Before choosing a document processing provider, verify its residency claims against its contractual and technical documentation rather than relying on an "EU hosted" or "GDPR compliant" label.

For businesses automating document workflows, that visibility matters because sensitive source files remain a compliance consideration even after their contents become structured data.

Last updated on September 21st, 2026