Contents
Key takeaways
- GDPR compliance is a selection criterion, not a box to tick later: a BI solution consolidates personal data in one place.
- You remain the controller and the provider is the processor. A data processing agreement under Article 28 GDPR is required.
- There are three paths for the storage location: processing in the EU, a DPF-certified US provider, or standard contractual clauses with a risk assessment.
- A compliant tool does not replace your own processes: legal basis, records of processing activities, deletion periods, and roles remain your responsibility.
Choosing BI software also determines where your company's data is stored and who can access it. For companies in the EU, GDPR compliance should be a central factor in the decision. High data protection standards are also valuable outside the EU because they protect both company and customer data.
A BI solution brings data from across the company together. This includes sensitive business and customer data: revenue figures, payment details, campaign data, and sometimes employee data. As soon as this data relates to an identifiable person, the GDPR applies.
Compliance is not the only concern. A data protection incident can have legal consequences and damage customer trust. Both can harm a company over the long term. It is therefore worth resolving the issue before selecting a solution and making it part of the evaluation.
Typical data consolidated in a BI solution includes:
- Web analytics: Visitors, sources, and conversions, for example from GA4 or Search Console
- Advertising data: Costs, clicks, and results from advertising accounts
- CRM and sales: Contacts, deals, and pipeline
- Finance: Revenue, costs, and contribution margins
- People: Depending on the setup, utilization or performance data
Mark manages an e-commerce company with 25 employees and chooses an inexpensive BI solution whose servers are located in the United States. Months later, a major B2B customer asks during an audit for evidence of where the data is stored and whether a data processing agreement exists. Mark cannot provide either clearly and must choose between migrating to a compliant solution or turning away customers with these requirements.
This article explains what the GDPR requires when choosing software, where your data may be processed, what the available options mean, what to check during selection, and which responsibilities remain after the decision. Define requirements for BI solutions and Evaluate BI solutions and decide cover the general selection process.
What the GDPR requires: your role and the data processing agreement
Even when a provider stores and processes your data, you remain responsible for it. The GDPR distinguishes between two roles: you are the controller, and the provider acts as the processor. You cannot transfer your responsibility to the software.
| Controller | Processor | |
|---|---|---|
| Who | Your company | The BI provider |
| Decides | Purpose and means of processing | Does not decide independently; follows instructions |
| Liability | Bears primary responsibility | Is liable for its own violations |
| Basis | Legal basis for each processing activity | Data processing agreement |
To use a solution lawfully in this setup, you and the provider need a data processing agreement under Article 28 GDPR. It defines what the provider may and may not do with the data.
At minimum, the agreement covers the provider's obligation to follow instructions, technical safeguards, subprocessors, deletion after the contract ends, and support for data subject requests. Most providers supply such an agreement, though you may need to accept it actively. Before signing, check whether it is available and which measures it covers. Without one, this processor setup is not compliant.
The agreement only governs processing on your behalf. You also need a legal basis for the processing itself, for example under Article 6 GDPR. The final section returns to this point.
Where your data is processed: three paths and what they mean
The storage location determines which rules apply. When data remains in the EU or European Economic Area, the GDPR applies directly. When it leaves that area, it is transferred to a third country and requires an appropriate transfer basis.
In practice, BI solutions offer three paths. They differ mainly in effort and residual risk.
1. Processing in the EU or EEA
When the server is in the EU, there is no third-country transfer. This removes the additional assessment and documentation required for an international transfer. You still need a data processing agreement. The main check is whether the provider contractually guarantees the EU location.
2. US provider certified under the DPF
Since July 2023, a European Commission adequacy decision has permitted transfers to the United States—but only to providers that participate in the EU-US Data Privacy Framework. Verify a provider in the public list on dataprivacyframework.gov. Check that its certification is active and covers the relevant data category, such as “Non-HR” for customer data. If both conditions are met, additional Standard Contractual Clauses are not required for that transfer. You still need the appropriate processing agreement and should record the transfer basis in your documentation.
This path has a relevant history. Its predecessors, Safe Harbor and Privacy Shield, were invalidated by the Court of Justice of the European Union. The General Court upheld the DPF adequacy decision in 2025, and an appeal remains pending. The framework currently applies, but another legal change cannot be ruled out and remains a planning risk.
3. US or other third-country provider without an adequacy decision
If the recipient is not covered by an adequacy decision or active DPF certification, Standard Contractual Clauses and a transfer risk assessment can provide another path. You assess whether an essentially equivalent level of protection exists in the destination and add supplementary measures where necessary. This path requires the most effort.
| What is required | Effort | Residual risk | |
|---|---|---|---|
| EU / EEA | Processing agreement, contractually guaranteed EU location | Low | Low |
| US with DPF | Processing agreement, verified active DPF certification and scope | Medium | Framework may change |
| US / third country without adequacy | Processing agreement, SCCs, transfer risk assessment | High | Ongoing assessment required |
A marketing manager wants to use a US tool. She finds the provider on dataprivacyframework.gov, confirms that the status is active, and sees “Non-HR” under the covered data. The DPF can therefore provide the transfer basis for the customer data in scope. She also signs the processing agreement and records both items in the company's data protection documentation.
Three misconceptions about US providers repeatedly create gaps:
- A US provider is automatically not GDPR-compliant. The DPF transfer basis applies only to organizations with active certification for the relevant data.
- The DPF replaces the processing agreement. The DPF governs where data may be transferred; the processing agreement governs processing on your behalf. Both are needed in a processor setup.
- A marketing claim is evidence. Verify certification yourself in the official list rather than relying on provider marketing.
The appropriate path depends on your requirements, goals, and preferred balance of effort and risk. An EU location avoids the transfer assessment and is frequently required in tenders and B2B contracts. A certified US provider can be appropriate when that provider is already selected. The third path is available when neither of the first two options works. BI for agencies explores this trade-off for multi-client environments.
What to check when choosing
Storage location and the processing agreement are only part of the decision. Technical and organizational factors determine whether a solution supports GDPR-compliant operation in practice. You do not need to be a lawyer to check them; ask targeted questions and request written evidence.
- Encryption: Data should be encrypted in transit and at rest. This is part of the technical safeguards expected under the GDPR.
- Roles and permissions: Define who can view which data. Granular controls help restrict access to what is necessary.
- Deletion model: Data should be deletable after defined periods and on request. This supports storage limitation and data subject rights.
- Subprocessors: The provider should disclose which service providers can access the data. The same international-transfer questions apply to subprocessors.
- Data subject rights: Check whether the solution helps you respond to access, deletion, and export requests.
- Evidence: Certifications such as ISO 27001 make security claims verifiable. A marketing statement alone is not evidence.
- Data export: You should be able to export your data and models completely. This reduces provider dependence.
A compact checklist for a vendor conversation:
| What to check | Evidence to request | |
|---|---|---|
| Storage location | Processing in the EU / EEA | Contractual location commitment |
| Processing on behalf | Article 28 agreement available | Signed processing agreement |
| Encryption | In transit and at rest | Technical documentation |
| Roles and permissions | Access controlled by need | Roles and permissions model |
| Deletion model | Defined periods and deletion on request | Documented deletion process |
| Subprocessors | Service providers disclosed | Current subprocessor list |
| Data subject rights | Support for requests | Feature documentation |
| Evidence | Independent security assessment | Certification, such as ISO 27001 |
| Data export | Complete export possible | Documented export function |
Treat anything a provider cannot document in writing as unavailable until proven otherwise. Marketing language or a badge does not replace evidence.
These points complement the general criteria catalog. Define requirements for BI solutions and Evaluate BI solutions and decide explain how to compare and weight vendors systematically.
What remains your responsibility after selection
A GDPR-ready tool does not automatically make your company compliant. The software provides components such as an EU location, a processing agreement, encryption, and roles. The surrounding processes remain your responsibility.
- Legal basis for each processing activity: Every activity needs a legal basis under Article 6 GDPR. Neither the DPF nor the processing agreement replaces it.
- Records of processing activities: Document which data you process and for what purpose. Do not assume that company size alone provides an exemption.
- Purpose limitation and deletion periods: Decide how data may be used and when it must be deleted. The tool may implement the rule, but you define it.
- Roles applied in practice: A role model protects data only when it is used. Grant access by need and do not share dashboards containing personal data openly.
- Data subject requests: Be able to respond to access and deletion requests within the applicable deadlines.
A team uses a solution with an EU location and a valid processing agreement but shares open dashboard links containing customer data in a group chat. The tool supports compliant operation; the practice does not. The weakness lies in the process, not the software.
The final point matters especially in self-service BI. More people work directly with data, so clear rules are needed for who may view and share it. Self-Service BI describes useful guardrails.
Frequently asked questions about BI software and GDPR
Is an EU server location enough for GDPR compliance?
It resolves the third-country transfer question, but not the rest. You still need an appropriate processing agreement, a legal basis, and compliant internal processes. An EU location is an important condition, not a guarantee.
May I use a US tool at all?
Yes. The provider may be actively certified under the DPF for the relevant data, which you verify in the official list. Otherwise, appropriate safeguards such as Standard Contractual Clauses and a transfer risk assessment may provide a transfer basis. A processing agreement is also required when the provider processes data on your behalf.
How do I tell whether a provider really supports GDPR compliance?
Do not rely on advertising. Verifiable evidence includes the storage location or active DPF certification, a processing agreement, the subprocessor list, security certifications, and export functionality. Request these items in writing.
What happens if the DPF is invalidated?
Transfers relying on it would lose that basis. You would need to establish another valid transfer mechanism, such as Standard Contractual Clauses with the required assessment, or move to an EU provider. Processing that remains in the EU is not affected by this transfer question.
Does a small company need records of processing activities?
Often, yes. The exemption for organizations with fewer than 250 employees is limited and does not apply, among other cases, when processing is not occasional. Recurring business processing will commonly fall outside that exemption.
Conclusion
For companies based in the EU, data protection is an important criterion when choosing BI software. Addressing it before comparing features helps avoid expensive corrections and provides clear answers to customers.
The process can be summarized in four steps:
- Clarify roles: You are the controller and the provider is the processor in the described setup, supported by an Article 28 agreement.
- Choose the transfer path: Processing in the EU, an actively DPF-certified US provider, or appropriate safeguards such as Standard Contractual Clauses with an assessment—and document the basis.
- Assess the solution: Review encryption, roles, deletion, subprocessors, evidence, and export using the checklist.
- Set up your own processes: Legal basis, processing records, deletion periods, and roles in practice remain your responsibility.
The right path depends on your situation. The key is not a particular product, but knowing where your data is located, who is responsible, and how you can prove it.
All Data. One system.
Contact
Paul Zehm
Founder at Zweigen