Spain and Greece’s Privacy Regulators Say a Secure Processing Environment Is Only as Strong as Its Provider’s Control

On November 5, 2026, Spain’s Agencia Española de Protección de Datos (AEPD) and Greece’s Hellenic Data Protection Authority (HDPA) published a joint guide, Secure Processing Environments from the Data Protection Perspective. It runs to 44 pages in English, with a Spanish edition. The subject is technical, but it will matter to many organisations in the next few years. Under Europe’s new health data law, a secure processing environment (SPE) is the only place where researchers, companies, and public bodies will be allowed to work with electronic health data reused for secondary purposes. The two regulators’ main message is that an SPE is a governance obligation as much as a security product.

What a secure processing environment is, legally

The term comes from the Data Governance Act (Regulation 2022/868). Article 2(20) defines an SPE as an environment that allows the entity providing it to determine and supervise all processing actions, including the display, storage, download, and export of data and the calculation of derivative data. The authorities treat that definition as the starting point. The core requirement is not encryption or a locked room. It is supervision: the provider must be able to see and control what users do with the data.

The European Health Data Space Regulation (Regulation 2025/327) makes SPEs mandatory for one large category of processing. Under Article 73, secondary use of electronic health data takes place inside an SPE governed by a health data access body. Secondary use means research, innovation, policymaking, and similar purposes, as opposed to treating a patient. The guide summarises the main safeguards: access only for people named in the data permit, state-of-the-art protection against unauthorised reading, copying or removal, audit logs kept for at least one year, and no export of personal data. Only anonymised, checked outputs may leave the environment.

This is worth stating precisely, because some early summaries said the EHDS requires all processing of health data to happen inside such an environment. It does not. The SPE requirement covers secondary use through health data access bodies. Primary care, insurance administration, and a hospital’s own operations follow other rules. Timing also matters. Most secondary-use provisions apply from March 2029, and genetic, genomic, and some research and clinical-trial data follow in 2031. Health data access bodies and their technical providers are designing for those dates now.

Control cannot be outsourced away

The AEPD’s Spanish-language press release highlights one point above the others. The entity that provides the SPE must have real and effective control over the infrastructure and the processing, even when a third party supplies the infrastructure. In the release’s words (translated), contractual guarantees or certifications “by themselves are not enough.” They must be backed by technical measures, supervision, and a genuine ability to audit. The guide recommends avoiding dependence on a single provider and avoiding concentration of technical control.

This is a stricter position than many cloud procurement teams are used to. A standard data processing agreement, an ISO certificate, and a right-to-audit clause would usually satisfy a vendor-risk checklist. The authorities say those are necessary but not sufficient for an SPE. The provider has to be able to verify for itself what the platform is doing. That ties the guide to the digital-sovereignty debate: the third-party measures in the guide include assessing vendor lock-in, adopting multi-vendor strategies, using open standards, tracking software bills of materials, and controlling data residency and cross-border transfers.

The guide also distinguishes SPEs from trusted execution environments (TEEs). A TEE uses hardware isolation and remote attestation to protect code and data in use, and it can be one building block of an SPE. The authors point out that a TEE does not provide the supervision of user actions, output checking, and governance the legal definition requires. Buying confidential-computing capacity is not the same as running an SPE.

A risk method built from two frameworks

For risk management, the guide combines two existing tools. The first is LIINE4DU, the AEPD’s privacy threat-modelling framework, which sorts threats into ten categories, including linking, identifying, inaccuracy, non-repudiation, exclusion, and detecting. The second is the Five Safes framework used in statistical and research data access, which asks five questions: Is this use appropriate (safe projects)? Can the users be trusted (safe people)? Does the setting prevent unauthorised use (safe settings)? Is there disclosure risk in the data itself (safe data)? Are the outputs non-disclosive (safe outputs)?

The authorities also say that because SPEs usually support high-risk processing, a data protection impact assessment under Article 35 GDPR is generally required. Teams still asking whether DPIAs are mandatory for a research platform have a clear regulatory answer here. The guide also widens the scope of risk beyond privacy, so the analysis covers intellectual property, trade secrets, national security, third-party dependencies, and other fundamental rights in a single framework.

The measures section lists required controls in ten families. Here is how a compliance lead might use them as a gap assessment:

1. Governance and accountability: named roles, clear controller and processor allocation, and documented decisions.
2. Data management: minimisation per permit, so users see only the data their approved purpose needs.
3. Identity and access control: access tied to the people listed in the data permit.
4. Physical security: protection for the facilities that host the environment.
5. Network and communications security: segmentation and controlled connections.
6. System and application security: hardened tools inside the environment, including any AI tooling.
7. Audit, logging, and monitoring: logs that can actually be reviewed, not just stored.
8. Incident response and resilience: breach procedures, tested backups, and possibly a parallel environment for critical services.
9. Third-party management: lock-in assessment, SBOM tracking, critical-vendor designation, and residency controls.
10. Culture and training: role-specific training and a working incident-reporting culture.

Privacy engineering, with the limits stated

The engineering section reviews homomorphic encryption, secure multi-party computation, polymorphic encryption and pseudonymisation, oblivious pseudonymisation, differential privacy, and federated learning. The authors say none of these is a cure-all, that not every technique is always possible or necessary, and that each has its own limits. They still say the techniques should be taken into account when building an SPE, because their benefits go beyond conventional security. Readers who want background on how regulators assess these tools can compare the ICO’s case studies on privacy-enhancing technologies and the OECD’s PETs repository.

The use case shows why this matters. A research consortium wants to study the relationship between allostatic load, a biomarker of chronic stress, and age, sex, area of residence, and socioeconomic status, using data from hospitals, registries, and statistical offices. No direct identifiers are needed. The guide still concludes that a combination such as age, sex, postcode, and socioeconomic status can allow re-identification when matched against the data holders’ records, so the dataset cannot be treated as anonymous. It also warns that download restrictions alone do not stop linking. Repeated regression runs and fine stratification can build up information about small subgroups over time. That is consistent with Europe’s broader debate on how pseudonymised data should be classified. The guide then shows how homomorphic encryption could support the statistical analysis while limiting what any party sees in clear.

Who should read it, and why now

The guide is aimed at controllers, DPOs, consultants, and third parties that design, deploy, or operate SPEs. In practice that means four groups. Health data access bodies and the public agencies setting them up. Universities and research hospitals that already run trusted research environments and will need to map them to the EHDS. Cloud and analytics vendors that want to supply SPE infrastructure. Life-sciences companies that will be data users. Research-data governance failures elsewhere, such as the UK Biobank data exposure, show what happens when access is granted on trust and outputs are not controlled.

The guide is a joint regulatory guide, not binding law and not a European Data Protection Board opinion. It is still a strong signal of how two national authorities will read GDPR accountability in this context. The English edition of the guide is the text to cite.

Frequently asked questions

Is an SPE the same as a data clean room?

No. A data clean room is a commercial setup for joint analysis, often in advertising. An SPE under the DGA and EHDS is a legally defined environment in which the provider supervises every processing action and checks outputs before release.

Does using an SPE make the data anonymous?

No. The guide’s use case shows that quasi-identifiers inside an SPE can still allow re-identification. The environment lowers risk. It does not change the data’s legal status, so the GDPR continues to apply.

Can a public body rely on a hyperscaler’s certifications?

Only as one input. The authorities say contractual guarantees and certifications alone are insufficient without technical measures, oversight, and real audit capability.

Is the guide binding?

No. It is guidance from two national authorities. It explains how they interpret the GDPR, DGA, and EHDS obligations that are binding.

The vault is only as good as the keyholder

It is easy to treat a secure processing environment as a product to buy before 2029 arrives. The Spanish and Greek regulators argue the opposite. The environment is the set of decisions its provider can still make and enforce after it goes live: who gets in, what they can run, what leaves, and what happens when a vendor fails. Organisations that start with those questions will have something to show a regulator. Those that start with a procurement checklist may find their environment is secure but not under their control.