April/May Data Wrap: A snapshot of key regulatory developments

The European Commission has called on Member States to accelerate the rollout of a new EU age verification app, urging that it be made available to citizens by the end of 2026.  The recommendation forms part of a broader strategy to strengthen child protection online while maintaining strong safeguards for privacy and data security.

Central to the proposal is a secure, privacy preserving application that allows users to prove they meet a required age threshold without disclosing their exact age or identity. This approach relies on anonymous proof of age technologies designed to ensure that only the necessary information is shared with online services.  The Commission has already developed a technical blueprint for the app, leaving Member States responsible for adapting and deploying national versions tailored to their own systems.

The app can be introduced either as a standalone solution or integrated into the planned European Digital Identity Wallet, which Member States must provide to residents by the end of 2026.  These wallets will enable individuals to securely share identity data and attestations, including proof of age, across the European Union.

The initiative is part of a wider framework to protect minors online, complementing measures such as enforcement of the Digital Services Act, the Better Internet for Kids Strategy, and efforts to combat cyberbullying.  The Commission has emphasised that age verification is only one element of a multi layered approach, but is a necessary tool in limiting access to harmful or inappropriate content.

Under the Digital Services Act, online platforms are required to ensure a high level of privacy, security and safety for minors.  Guidelines adopted by the Commission recommend the use of reliable and non-intrusive age assurance methods, including verification tools, to restrict access to adult services such as gambling or age restricted purchases.

To support implementation, the Commission has set out a common EU wide approach. Member States are encouraged to use the shared blueprint, develop national rollout plans, and cooperate closely with each other, digital regulators, researchers and civil society. They are also expected to ensure compliance with cybersecurity standards through independent oversight.

The Commission plans to establish an EU age verification scheme, including a list of trusted providers capable of issuing proof of age attestations.  These providers may rely on official identification documents such as passports, ID cards or electronic identities to confirm eligibility, while still preserving user anonymity during verification.

The European Union has agreed to delay the rollout of key obligations under its landmark Artificial Intelligence Act, in a move aimed at easing implementation pressures while maintaining the regulation’s core framework. The agreement, reached in May 2026 between the European Parliament and the Council, forms part of a broader effort to simplify EU digital rules through the so called Digital Omnibus package.

At the centre of the reform is a postponement of requirements for high-risk AI systems, which include technologies used in areas such as recruitment, biometric identification and critical infrastructure. These obligations were originally due to apply from August 2026 and August 2027 depending on the category of system. Under the new timeline, compliance deadlines have been deferred to 2 December 2027 for stand-alone high-risk systems and to 2 August 2028 for AI embedded in regulated products.

The delay reflects concerns that the regulatory and technical infrastructure needed to support compliance, including harmonised standards and guidance, will not be ready in time. By providing additional lead time, EU institutions aim to give businesses greater legal certainty and space to prepare for the complex requirements of the AI Act, while preserving its risk-based approach.

Despite the deferral, the agreement leaves several near-term obligations unchanged. In particular, transparency rules will still begin to apply from 2 August 2026. These include requirements for companies to inform users when they are interacting with AI systems and to disclose AI generated content in certain contexts.

However, the specific obligation to ensure that AI generated content is watermarked or otherwise detectable has been delayed to December 2026, with a shorter grace period for implementation.

On 14 April 2026, the European Data Protection Board ("EDPB") launched a public consultation on a standardised template for Data Protection Impact Assessments ("DPIA"). 

Article 35 of the GDPR requires controllers to carry out a DPIA prior to undertaking any processing activity that is likely to result in a high risk to individuals' rights and freedoms. However, the GDPR does not prescribe any specific format for doing so, which has led to significant variance in the way DPIAs are structured and documented, both across organisations and between Member States.

Aimed at simplifying GDPR compliance and strengthening consistency across the EU, the EDPB's proposed template is designed to help organisations harmonise and evidence their DPIA reporting processes. Alongside the template, the EDPB has produced a complementary guidance document explaining how to complete it. The consultation closed on 9 June 2026 and we now await the EDPB's finalised output.

The template contains seven sections which use prescribed fields to guide controllers through the requirements of Article 35 GDPR. These cover an overview of the processing activity, a detailed description and analysis of the processing (including prompts relating to its lawful basis), considerations of necessity and proportionality, a risk assessment, and provisions for the involvement of relevant interested parties.

The EDPB's proposed template is a welcome development, offering much needed clarity and consistency in how DPIAs are documented across the EU, and could become the standard approach adopted by organisations going forward. Nevertheless, organisations should be mindful that the template addresses only the documentation aspect of the DPIA process. It does not alter or replace the underlying assessment work required when identifying and evaluating high-risk processing activities. The underlying analysis remains entirely the organisation's responsibility.

In April 2026, the European Data Protection Board’s (“EDPB”) approved the Europrivacy certification scheme as a mechanism for international data transfers, marking a significant evolution in the GDPR’s compliance toolkit. 

The EDPB’s April 2026 opinion now means that a specific version of the Europrivacy criteria is certified for use as an “appropriate safeguard” under Article 46 GDPR for transferring personal data outside the EEA.  This effectively elevates Europrivacy into a new category of transfer tool alongside established mechanisms such as Standard Contractual Clauses and Binding Corporate Rules. 

For international organisations operating out of or interacting with the EU, this development is particularly important for both legal and operational reasons: 

1. It offers an additional, potentially more standardised and audit-based mechanism for legitimising cross-border data flows to jurisdictions where there is no adequacy decision, an area that has become increasingly complex following regulatory scrutiny of transfers.  
2. The use of certification can help organisations demonstrate accountability and reduce compliance risk through independently verified controls, while also strengthening trust with customers, partners, and regulators.  
3. As the certification requires binding and enforceable commitments by data importers, it reinforces data subjects’ protections and helps ensure an “essentially equivalent” level of protection when data leaves the EU.  

This new aspect to Europrivacy introduces a scalable, globally applicable framework that may streamline compliance, reduce due diligence burdens, and provide an alternative compliance route for organisations engaged in international transfers of personal data outside of the EEA.

On 29 April 2026, the Information Commissioner’s Office (“ICO”) finalised its Guidance on the use of storage and access technologies (the “Guidance”). The Guidance covers how the Privacy and Electronic Communications Regulations (“PECR”) (and relevant UK GDPR) apply to cookies, tracking pixels, device fingerprinting and similar technologies (known as “storage and access technologies”). It reflects updates following prior consultations, amendments introduced by the Data (Use and Access) Act (the "DUA"), and includes new examples and clarifications designed to assist organisations in meeting their compliance obligations.

Under PECR, the use of storage and access technologies within the UK requires opt-in consent from users, unless a recognised exemption applies. The DUA has broadened the exemptions available under the UK’s cookie consent framework. The Guidance clarifies two new PECR exemptions introduced by the DUA: (i) storage and access technologies used solely for “statistical purposes” (analytics); (ii) or solely to remember user interface preferences, such as language or display settings (the "appearance" exemption). Organisations may now set these by default without obtaining prior consent, provided that users receive clear information and have a simple, free means to object, in accordance with the "simple means of objecting” condition set out in the DUA. The Guidance suggests implementing this via cookie banners (eg toggles left “on” by default for these two categories) rather than relying solely on browser settings.

The Guidance further emphasises that each PECR exemption is limited to a specific purpose. If a storage and access technology serves multiple purposes, including any that falls outside an exemption, the organisation deploying it cannot rely on a sole-purpose exemption and must still obtain consent. For example, an analytics cookie that also serves advertising or profiling functions would not qualify for the “statistical purposes” exemption and must be treated as requiring opt-in consent.

Additionally, the Guidance offers further examples confirming that the “strictly necessary” exemption applies only where a storage and access technology is essential, assessed from the user’s perspective, for the provision of a service that the user has expressly requested. For instance, the Guidance confirms that security or compliance cookies can only be considered “strictly necessary” if they are the sole practicable means of meeting a legal or security requirement and are truly indispensable to the user’s service experience. Storage and access technologies that are not strictly necessary do not qualify for this exemption and still require consent.

From a practical standpoint, the Guidance identifies several steps that organisations deploying storage and access technologies should take. To rely on the new exemptions, the Guidance recommends that organisations update their cookie banners or consent management platforms to provide users with a straightforward means of opting out. The Guidance also emphasises the importance of conducting thorough audits of cookie usage to ensure that no non-essential tracking takes place without valid consent.

On 18 May 2026, the UK Information Commissioner’s Office ("ICO") published formal advice to the Government on potential reforms to the rules governing online advertising. The recommendations form part of a broader effort to balance strong data protection standards with innovation and growth in the UK’s digital economy. It is estimated that digital advertising contributes to £129 billion  of gross value added per year to the UK economy. However, it is tightly regulated under the Privacy and Electronic Communications Regulations ("PECR") and the UK GDPR, particularly through “Regulation 6” of PECR which requires user consent before storing or accessing information on a user’s device (for example, via cookies or tracking technologies). 

The ICO’s central concern is that the current consent-based regime applies uniformly across all types of online advertising, regardless of the level of privacy risk involved. This means that even relatively low-risk activities, such as contextual advertising, are subject to the same consent requirements as more intrusive behavioural advertising that tracks individuals across multiple sites. According to the ICO, this “one-size-fits-all” approach may inadvertently discourage the development of more privacy-friendly advertising models. 

To address this issue, the ICO has proposed a more nuanced, risk-based framework. At the heart of its recommendations is the idea that regulatory requirements should better reflect the differing levels of privacy risk across advertising activities. In particular, the ICO suggests introducing limited exemptions from consent requirements for “low-risk” forms of online advertising – see its findings here. These could include activities such as ad delivery, attribution and frequency capping. These exemptions would operate within a “first-party” framework, meaning that data processing would largely remain with the website or service directly interacting with the user, with restricted sharing with third parties. 

Importantly, the ICO makes clear that more intrusive forms of advertising, particularly those involving behavioural profiling or cross-site tracking, would continue to require user consent. The intent is not to weaken privacy protections but to calibrate them more effectively according to risk. 

The advice was provided in the context of new legislative powers under the Data (Use and Access) Act, which allow the government to amend PECR through secondary legislation. The ICO’s role is advisory, offering evidence-based input to support policymaking rather than introducing immediate legal changes. As of now, the existing rules remain in force, and organizations must continue to comply with current consent requirements. Any changes would depend on further government consultation and legislative action. 

However, the ICO’s recommendations signal a potential shift towards a more flexible and risk-based regulatory model for online advertising in the UK. By distinguishing between high and low-risk practices, the proposed reforms aim to foster innovation while maintaining robust privacy protections - an increasingly important balance in a data-driven economy.

The Data (Use and Access) Act 2025 ("DUA") introduced important changes to how data protection complaints are made and handled in the UK. For organisations that handle personal data, the reforms create new procedural obligations that require action now before they come into force on 19 June 2026.

The most significant change is the introduction of a mandatory internal data protection complaints process for data controllers. There are no exemptions to this. Before the DUA, there was no statutory requirement for data controllers to handle complaints, even if it has been good practice to do so and expected by the ICO. However, the DUA imposes a new legal obligation on data controllers to provide a way to complain directly, acknowledge complaints, and handle them. Previously, individuals could complain directly to the ICO about an alleged data protection infringement without first raising it with the organisation concerned. Under the new regime, the ICO has made it clear that in most cases, if a complaint comes to them, they will ask the individual to first raise that complaint directly with the organisation. Controllers must therefore have a documented, accessible internal complaints procedure in place. 

Controllers must provide a clear way to complain directly, acknowledge complaints, and deal with them in a specific way. But what does this mean in practice? The ICO has published key guidance.

1. Providing a way to complain

The ICO provides the following examples of how to give people a way to complain to you: providing complaint forms; providing an email address and/or phone number for complaints; via an online complaints portal or a live chat function (with the ability to escalate to a human if needed); and/or providing a way to complain in person if needed, (e.g. if you have no online presence). However, the ICO does make clear that data subjects can complain via any channel they choose, even if they do not use your set process. This could include via social media, for example. You must therefore have processes in place to recognise such complaints.

2. Acknowledging complaints

Data protection complaints must be acknowledged within 30 days. 

3. Dealing with complaints

All data protection complaints must be investigated, and organisations must respond without undue delay, (i.e. without an unjustifiable or excessive delay). Organisations should also keep data subjects informed of progress and clearly explain the outcome using plain, accessible language. When being informed of the outcome of a complaint, data subjects should also be informed of their right to complain to the ICO, along with the ICO’s contact details. Note that the ICO does provide further guidance on people making complaints on behalf of others, setting out that you must check that they are authorised to act, and not investigate the compliant until you receive the appropriate authority.

What you should do now

1. If they haven’t already, controllers should audit their existing complaints infrastructure and take any actions necessary to ensure compliance.
2. Put in place mechanisms to ensure they have a clear and communicated internal complaints procedure, including adherence to response timescales.
3. Update their privacy documentation (e.g. privacy notices), if necessary.
4. Train their workforce on the process, their roles, and the statutory requirements.
5. Keep thorough records and document all complaints. If a complaint does escalate to the ICO, this evidence will be central to demonstrating that they handled the matter appropriately.

The Information Commissioner’s Office (ICO) has fined South Staffordshire Plc and South Staffordshire Water Plc £963,900 following a cyber attack that exposed the personal data of more than 633,000 individuals. The ICO found infringements of both Article 5(1)(f) (integrity and confidentiality principle) and Article 32(1) (security of processing) UK GDPR, underlining that failures in cyber security controls can amount not just to technical deficiencies, but to breaches of core data protection principles.

The decision provides a clear indication of the ICO’s current enforcement approach to cyber security. In particular, the ICO focused on failures in well‑established “best practice” controls - such as monitoring, access management and patching - which it treated as baseline legal requirements. The case also highlights the regulatory significance of prolonged undetected access (around 20 months), large‑scale data exfiltration, and phishing as a foreseeable entry point, as well as the increased scrutiny faced by organisations processing large volumes of sensitive data, particularly in essential service sectors.

The accompanying penalty notice also provides insight into the ICO’s fining methodology, demonstrating how it moves from the statutory maximum to a final penalty through a structured assessment and successive reductions, including for cooperation and early settlement. Together, these elements make the decision an important reference point for organisations assessing cyber security risk and regulatory exposure.

For further detail of the fine please refer to our blog post here.

On 8 May 2026, the Dutch Data Protection Authority imposed a €100 million fine on MLU B.V. after it was determined that the European version of the Yango taxi app transferred personal data from Norway and Finland to Russia without implementing appropriate safeguards under the GDPR. This is one of the largest fines issued by the Dutch DPA and highlights the increasing regulatory scrutiny of international data transfers.

The decision concerned Ridetech International B.V., an Amsterdam-based company which, in the course of operating the Yango taxi app in Norway and Finland, transferred large volumes of personal data relating to customers and drivers to affiliated entities within the Yandex group in Russia, where it was subsequently stored. Following Ridetech's dissolution in October 2025, the parent company, MLU B.V., was held responsible for the breach.

Despite Ridetech relying on Standard Contractual Clauses ("SCCs") and the data being pseudonymised and encrypted, the Dutch DPA found the SCCs to be deficient in two respects, failing to satisfy the requirements of Articles 44 and 46 of the GDPR.

1. The wrong SCC module was used: Ridetech relied on a controller‑to‑processor SCC module despite the Russian recipient determining the purposes and means of processing alongside Ridetech in practice, such that it should have been characterised as a (joint) controller. As a result, the contractual framework did not reflect the parties’ actual roles, rendering the SCCs ineffective as a valid transfer mechanism under Article 46 GDPR.
2. Encryption keys were held in Russia: Contrary to the terms of Ridetech's SCCs, the encryption keys were stored on the same servers as the encrypted data until 27 November 2023.

Following this significant regulatory fine, organisations must ensure that SCCs are correctly selected and accurately reflect the factual processing relationships, and must supplement them with effective technical and organisational measures following a robust transfer impact assessment.

On 28 May 2026, the CNIL published guidance on cloud computing actors’ roles and obligations. The guidance addresses three areas: (i) provision of services, (ii) service improvement and (iii) security, reflecting the complexity of cloud arrangements where providers may offer multiple services and responsibilities may evolve.

Provision of services:

The CNIL reiterated that the customer is the controller for processing carried out using the cloud service, as it determines the purposes and means, including the choice of provider.

The supplier usually acts as processor, processing data on the customer’s instructions. It may be a co-controller where processing serves both parties’ purposes.

Service improvement:

Roles for service improvement must be assessed case by case. Depending on who determines the purposes and means, the provider may be a controller, processor or joint controller with the customer.

A cloud provider may be a controller where it alone determines the purposes and means, or improves the service on its own initiative and for its own needs.

Where the customer determines the improvement method and has the means to achieve it, and the provider has no separate objective, the customer is controller and the provider acts as processor.

Security: 

The CNIL distinguishes cloud security from security “in” the cloud. Cloud security covers provider measures protecting the service, such as servers, networks and physical components; these are generally not customer-specific, and customers usually have no role in their implementation.

Security “in” the cloud covers customer measures protecting data stored in the cloud, whether using provider tools or third-party tools. These measures are customer-specific and may vary between customers of the same supplier.

Generally, the customer is controller for cloud processing, and security measures may form part of that processing.

On 28 May 2026, the French data protection authority (the "CNIL") published a decision fining IQVIA Corporation ("IQVIA") €5 million. IQVIA is a health data analytics company that operates two health data warehouses, Longitudinal Prescription Data (“LRx”) and Electronic Medical Record (“EMR”). The LRx warehouse receives data from approximately 14,000 pharmacies while the EMR warehouse processes information from thousands of physicians..

The decision followed complaints from individuals and associations, prompted by a report on the French television programme, ‘Cash Investigation’. Concerns were raised about a lack of transparency in the processing of patient data which led CNIL to investigate IQVIA and its partner pharmacies. The CNIL found three key failings: (i) IQVIA had not adequately informed individuals about data processing activities; (ii) had not facilitated the exercise of their rights; and (iii) had not  established appropriate data security.

From a security perspective, no measures were in place to analyse connection logs on a regular basis, preventing effective detection of abnormal activity. In respect of the EMR warehouse, no multi-factor authentication had been implemented. Otherwise, the patient information leaflet contained inaccuracies, and no effective procedure existed for individuals to exercise their right to object to the processing of their data. IQVIA was ordered to rectify the breaches within 6 months or face a penalty of €10,000 per day of non-compliance. IQVIA has since confirmed that the data security and confidentiality breaches have been remedied.

The CNIL also found that four partner pharmacies had failed to inform customers about the transmission of their data to IQVIA. As data controller, IQVIA bore responsibility for ensuring patients were informed. 

In setting the fine, the CNIL took into account several aggravating factors. These included IQVIA’s significant financial resources, its market position, the number of individuals affected, and the sensitive nature of the data. 

The CNIL's rejected IQVIA’s argument that the data had been anonymised. It found that pseudonymisation alone did not prevent re-identification by reasonable means. The data was linked to a unique identifier, was highly detailed, and could be cross-referenced with publicly available information held by IQVIA. 

This decision is a reminder that organisations processing large volumes of sensitive health data must maintain ongoing compliance with the legal and technical requirements of regulatory authorisations. It also highlights the important distinction between anonymised and pseudonymised data, particularly where re-identification risks remain significant.

The Code of Practice on Artificial Intelligence and Automated Decision-Making Regulations 2026 (the "Regulations") came into force on 12 May 2026. The Regulations require the Information Commissioner’s Office (the “ICO”) to prepare a code of practice on the processing of personal data in relation to Artificial Intelligence (“AI”) and automated decision-making, including children’s personal data. The ICO will begin engaging with stakeholders to develop this code, with the aim of publishing a draft in Spring 2027 for consultation.

Under the Data Protection Act 2018, the ICO is duty-bound to set out good practice. Such guidance must describe the personal data or processing to which it relates, identify who it applies to, and explain which practices the ICO considers desirable having regard to the interests of data subjects and the requirements of data protection legislation.

The Department for Science, Innovation and Technology have expressed their intention for the Regulations to help organisations understand and comply with data protection requirements as new technologies emerge. The code will not be legally binding but will be taken into account by the ICO when assessing whether organisations have complied with data protection obligations.

Notably, the Regulations do not define ‘AI’, allowing the ICO flexibility to adapt the code as technologies evolve. By contrast, automated decision-making is defined as a significant decision made without meaningful human involvement that produces a legal or similarly important effect for the data subject. The code must address the use of personal data in both contexts.

Organisations can expect practical clarity on how to meet existing data protection obligations in the context of AI and automated decision-making. While the code will not be binding, it will be relevant in practice, as regulators will use it as a benchmark when assessing compliance.

On 15 April 2026, the European Data Protection Board ("EDPB") adopted Guidelines 1/2026 on processing personal data for scientific research purposes, now under public consultation until 25 June 2026. The Guidelines provide the EDPB’s most comprehensive guidance to date on applying the GDPR to scientific research. Key takeaways are set out below.

Concept of scientific research

The Guidelines clarify that only genuinely scientific research benefits from the GDPR’s research-specific provisions. This depends on six factors: (1) a methodical and systematic approach; (2) adherence to relevant ethical standards; (3) verifiable results shared with peers; (4) autonomy and independence; (5) objectives that contribute to general knowledge and wellbeing; and (6) potential to advance or apply scientific knowledge in novel ways. If not all factors are met, the controller must justify why the activity still qualifies as scientific research under the GDPR.

Purpose limitation and storage

Further processing for scientific research is presumed compatible with the original purpose under Article 5(1)(b) GDPR, so controllers need not conduct the Article 6(4) compatibility test. They must still ensure the processing is lawful and may often rely on the original legal basis.

Personal data may be stored longer if it will be processed further solely for scientific research, including future related projects. However, broad, unspecified storage is not permitted: controllers must identify at least a research area and regularly review whether storage remains necessary.

Consent

Where research purposes are not fully known at collection, controllers may rely on “broad consent” for a defined research area, supported by ethical standards and safeguards giving data subjects sufficient control. Alternatively, they may use “dynamic consent” for each project or stage, or combine both approaches. The Guidelines distinguish research participation consent, such as informed consent in clinical trials, from GDPR consent as a legal basis; any GDPR consent must meet the GDPR’s requirements.

Public and legitimate interest 

Article 6(1)(e) GDPR is highlighted as an important legal basis for scientific research. It is not limited to public bodies: private entities may rely on it where Union or Member State law covers their activities.

Scientific research may also constitute a legitimate interest, whether non-profit or commercial, provided Article 89(1) safeguards protect data subjects’ interests, rights and freedoms and the controller’s interest is not overridden.

Special categories of personal data

When processing special category data for scientific research, controllers must apply effective Article 89(1) safeguards. Genetic, biometric or health data may be subject to additional Member State restrictions. Controllers must also identify an applicable Article 9(2) GDPR exception for processing special category data.

Transparency

Controllers must maintain transparency throughout any extended research processing, for example through webpages, privacy dashboards or contact points. However, Article 14(5) notices may not be required where they would involve disproportionate effort.

Data subject rights

Article 17(3)(d) GDPR allows refusal of erasure where deletion would make research impossible or seriously impair its objectives. The EDPB stresses that this is limited and must be assessed case by case, including the number of data subjects affected and the importance of the individual’s data.

Article 21(6) GDPR also permits rejection of an objection where processing is necessary for a public-interest task, including where a controller’s legitimate interest aligns with public interest. 

Attribution of responsibility

The Guidelines explain how roles should be allocated where multiple entities are involved. Defining a research protocol will usually make an entity a controller, while mere funding or independent consultancy will not. Individual researchers generally act under a controller’s authority unless conducting fully independent research. Joint controllership arises where entities jointly determine purposes and essential means, such as by jointly drafting a protocol. Responsibilities must be documented and communicated to data subjects.

Appropriate safeguards

Controllers must apply Article 89(1) safeguards. Anonymised data should be used where possible; otherwise, pseudonymisation should be applied. Directly identifiable data is allowed only where strictly necessary and proportionate. Other safeguards may include ethical oversight, secure environments, privacy-enhancing technologies, strict purpose limits, confidentiality obligations, researcher qualifications, anti-re-identification measures, publication safeguards, codes of conduct and certification mechanisms.