GDPR Cloud Storage: How to Evaluate Providers in 2026

GDPR-ready cloud storage is not a badge that a provider can give your organization. A service can offer useful contracts, security controls, data-location options, and audit evidence, but your compliance still depends on why you process personal data, which data you store, how you configure the service, who can access it, and how you handle people’s rights.

This guide explains how to evaluate cloud storage for GDPR due diligence. It focuses on file-storage and collaboration services, while noting where infrastructure, backup, and managed-service responsibilities differ.

Checked on August 25, 2026: legal and provider references were reviewed against current official sources. This article provides general information, not legal advice.

GDPR cloud storage at a glance

• A provider’s features can support compliance, but they cannot make every customer or workload compliant.
• Define whether each party acts as a controller, processor, subprocessor, or a combination of roles.
• A data processing agreement and an international-transfer mechanism solve different problems.
• EU storage can simplify some risks, but location alone does not settle remote access, support, subprocessor, or onward-transfer questions.
• Encryption matters, but GDPR security is risk-based and also covers access, resilience, recovery, testing, monitoring, and operating procedures.
• Ask for evidence you can review, not a broad claim that a product is “GDPR compliant.”

What GDPR-ready cloud storage should mean

A useful service should let an organization understand and manage its own obligations. That starts with the GDPR principles in Articles 5, 24, 25, 28, and 32: lawful and transparent processing, purpose limitation, data minimization, accuracy, storage limitation, security, accountability, data protection by design, and documented processor instructions.

In practice, “GDPR-ready” should mean that a provider can answer specific questions and supply the relevant evidence. It should not mean that every customer, configuration, or use case automatically complies.

The same product can support one compliant implementation and one noncompliant implementation. A team might choose an appropriate region and strong encryption, then undermine those controls through excessive permissions, indefinite retention, an unsupported legal basis, or an incomplete response process for data-subject requests.

Ten questions to ask a cloud storage provider

1. Which service are we buying? File sync, collaboration software, object storage, backup, and infrastructure services create different operational responsibilities.
2. Which party has which GDPR role? Identify the controller, processor, and any subprocessors for the exact workload.
3. Which agreement applies? Obtain the correct service terms and, where required, an Article 28 data processing agreement.
4. Where can data be stored, processed, supported, and accessed? Ask about primary data, replicas, backups, logs, support access, and administrative operations.
5. What supports international transfers? Identify any adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, derogation, transfer assessment, and supplementary measures that apply.
6. Who are the subprocessors? Review their roles, locations, notice process, and objection mechanism.
7. Which security controls are available? Check encryption, key control, identity and access management, logging, recovery, resilience, testing, and incident response.
8. How are deletion, export, retention, and data-subject requests handled? Confirm what the service can do and what the customer must operate.
9. What happens after an incident? Check notification commitments, investigation support, evidence preservation, and contact routes.
10. What evidence can we review? Ask for current audit reports, certifications, contractual commitments, architecture documentation, and control descriptions that cover the service you will use.

A provider comparison becomes useful when every candidate answers the same questions. A list of logos and feature claims does not provide the same assurance.

Start with controller and processor roles

The GDPR assigns obligations according to what each party does. A controller determines the purposes and means of processing. A processor handles personal data on the controller’s behalf and under documented instructions. A provider can act as a processor for customer files while acting as a controller for account, billing, fraud-prevention, or service-operations data.

The European Data Protection Board’s controller and processor guidance explains that labels in a contract do not override the parties’ actual roles. Map the data flows and decisions for the service you plan to use.

For a processor relationship, Article 28 requires a contract covering subjects such as instructions, confidentiality, security, subprocessors, assistance, deletion or return, and audit information. The customer still needs its own lawful basis, notices, retention rules, access governance, and rights-handling process.

A DPA is not an international-transfer mechanism

A data processing agreement allocates controller and processor duties. International transfers are governed separately by GDPR Chapter V.

If personal data moves outside the European Economic Area, or can be accessed from a third country, identify the transfer route. Depending on the circumstances, that may involve an adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, a specific derogation, and supplementary technical or organizational measures.

The EDPB’s international-transfer guidance provides a practical starting point. Do not treat a signed DPA, an EU data center, or an encryption checkbox as a substitute for the Chapter V analysis.

Data residency is one part of the transfer analysis

Data-location controls can reduce uncertainty and support a risk decision, but physical storage location is only one input. Review where the contracting entity, support teams, administrators, subprocessors, backups, telemetry, and recovery systems operate.

Ask the provider to distinguish:

• primary storage location;
• replica and backup locations;
• account and billing-data locations;
• support and administrative access;
• subprocessor access and onward transfers;
• customer-controlled region settings;
• technical measures that protect transferred data.

Our guide to where cloud data is stored explains the infrastructure side. The European cloud storage comparison covers geography and provider choice. This page remains focused on the legal and operational due-diligence questions.

Security controls and shared responsibility

Article 32 uses a risk-based test. Controllers and processors must select technical and organizational measures appropriate to the risk. The regulation names encryption and pseudonymization as examples, alongside confidentiality, integrity, availability, resilience, recovery, and regular testing.

A useful cloud-storage review should cover at least:

• Encryption: protection in transit and at rest, key ownership, rotation, recovery, and any client-side or end-to-end encryption option.
• Identity and access: multi-factor authentication, single sign-on, role-based access, least privilege, session controls, and account recovery.
• Logging and monitoring: administrator events, file access, sharing, exports, deletions, retention, and alerting.
• Resilience and recovery: replication, backups, version history, deletion recovery, disaster recovery, and tested restoration procedures.
• Secure operations: vulnerability management, change control, employee access, incident response, and regular control testing.
• Customer configuration: which controls are automatic, optional, plan-specific, or the customer’s responsibility.

Encryption can reduce risk and may affect breach-notification analysis, but it does not create a lawful basis, set an appropriate retention period, restrict an overprivileged account, or answer a deletion request by itself.

Check subprocessor and support access

A provider may rely on other companies for hosting, support, communications, analytics, billing, or security operations. The Article 28 contract should explain how subprocessors are authorized and how customers are informed about changes.

Review the current list rather than relying on a general statement. Record each relevant subprocessor’s function and location. Pay particular attention to services that can access file contents, account identifiers, logs, support tickets, or encryption keys.

The operational question is simple: who can reach the data or the systems that protect it, from where, for what purpose, and under which controls?

Plan breach response before choosing a provider

The often-repeated “72-hour rule” needs precision. Under Articles 33 and 34, a controller generally notifies the supervisory authority within 72 hours after becoming aware of a personal-data breach when the breach is likely to create a risk to people’s rights and freedoms. Communication to affected individuals is required without undue delay when the breach is likely to create a high risk, subject to the regulation’s conditions and exceptions. A processor must notify the controller without undue delay after becoming aware of a breach.

The European Commission summarizes these duties in its personal-data-breach guidance.

Before procurement, agree on:

• the provider’s notification contact and contractual timing;
• which facts the initial notice will contain;
• how logs and forensic evidence will be preserved;
• who assesses risk and makes regulatory decisions;
• how affected records and people can be identified;
• how exercises and post-incident reviews will be run.

How to compare provider evidence

Large cloud providers publish extensive GDPR material, but the same rule applies to each one: read the documentation for the exact service and configuration you will use.

• AWS’s GDPR Center describes its contractual and security resources and makes clear that customers retain responsibility for their own compliance.
• Microsoft’s shared-responsibility guidance explains how customer and provider duties vary by service model.
• Google Cloud’s GDPR resource provides contractual and transfer documentation while emphasizing the customer’s assessment and responsibilities.

These resources are evidence inputs, not automatic approval for a workload. Confirm the contracting entity, service scope, region, plan, subprocessor list, transfer terms, encryption model, and audit coverage.

Where Hivenet fits in the evaluation

Hivenet’s public Terms of Service, Privacy Policy, and Trust page are the starting points for understanding the service, account-data roles, and current security and privacy commitments. The Help Center also describes how Hivenet’s storage encryption works.

Use the same due-diligence standard you would apply to any provider. Confirm which Hivenet service and agreement cover the workload, which party has each GDPR role, which locations and subprocessors apply, which controls you must configure, and which evidence is available. If Hivenet would process personal data on your behalf, obtain the appropriate contractual documents before placing that workload into production.

Do not treat distributed architecture, encryption, European operations, or a privacy commitment as a complete compliance conclusion. They are factors to evaluate alongside purpose, legal basis, minimization, retention, rights handling, transfers, access, and accountability.

A practical procurement workflow

1. Describe the workload. List data categories, people, purposes, legal basis, volume, sensitivity, retention, and expected locations.
2. Map the service. Identify products, integrations, administrators, support routes, subprocessors, backups, and data flows.
3. Assign roles. Record controller, processor, joint-controller, and subprocessor responsibilities for each flow.
4. Review contracts and transfers. Check the service agreement, DPA, subprocessor terms, transfer mechanism, and supplementary measures.
5. Test controls. Configure identity, permissions, sharing, encryption, logging, retention, export, deletion, and recovery in a non-production environment.
6. Collect evidence. Retain the approved contract versions, technical documentation, risk assessment, test results, and decision owners.
7. Approve and monitor. Set review dates for provider changes, subprocessor notices, incidents, control tests, and changes to the workload.

A Data Protection Impact Assessment may be required when the planned processing is likely to create a high risk. Make that decision from the actual workload, not from the provider’s marketing category.

Frequently asked questions

Can a cloud storage provider be GDPR compliant?

A provider can comply with obligations that apply to its own activities and can supply services and contracts that support customers. That does not automatically make every customer use compliant. The result depends on both parties’ roles, the workload, configuration, contracts, transfers, and operating practices.

Does GDPR require personal data to stay in the EU?

GDPR does not impose a general rule that all personal data must remain in the EU. Transfers outside the EEA need an applicable Chapter V route and an assessment of the relevant protections. EU storage can still be a useful risk and procurement preference.

Is encryption required for GDPR cloud storage?

Article 32 names encryption as a possible security measure, but the requirement is to implement measures appropriate to the risk. Encryption should be considered with access controls, resilience, recovery, testing, monitoring, and organizational procedures.

What belongs in a cloud storage DPA?

An Article 28 processor contract should cover documented instructions, confidentiality, security, subprocessors, assistance with rights and incidents, deletion or return, and information needed to demonstrate compliance. The exact agreement must match the service and roles.

Are Standard Contractual Clauses the same as a DPA?

No. A DPA allocates controller and processor duties. Standard Contractual Clauses can provide safeguards for certain international transfers. A relationship may require both.

Who reports a personal-data breach?

A processor notifies the controller without undue delay. The controller evaluates the risk and, when the GDPR thresholds are met, notifies the supervisory authority and possibly affected individuals. Contracts should define how the provider supplies the information needed for that assessment.

What evidence should a buyer request?

Request current terms, the DPA, transfer documentation, the subprocessor list, data-location information, security-control descriptions, audit or certification scope, incident commitments, deletion and export procedures, and a clear shared-responsibility model for the exact service.

Choose evidence over labels

The strongest GDPR cloud-storage decision is traceable. It connects a defined workload to assigned roles, appropriate contracts, a defensible transfer analysis, tested security controls, documented operating procedures, and evidence that can be reviewed over time.

Use provider features to support that work. Do not use them as a substitute for it.