Introduction

Eight years ago, on 25 May 2018, the General Data Protection Regulation (GDPR) became applicable across the European Union (EU). Organisations scrambled to update their privacy notices and data mapping exercises, and regulators sharpened their pencils. But the GDPR was never going to stand still.

The GDPR is no longer new, but it is very much still evolving. The intention of the EU Commission, working through a new legislative proposal, the Digital Omnibus, has been to soften some of its rules to make them more business friendly. Meanwhile, enforcement is intensifying. 2025 was, from a fines perspective, a record year with 400+ fines being issued during the year. In this article, we will work through the ten most important GDPR developments from the past year and what organisations need to watch in the months ahead.

1. The Digital Omnibus

Over the last decade, in addition to the GDPR, the EU has launched an unprecedented constellation of digital laws such as the AI Act, the Data Act, the NIS2 Directive, the Cyber Resilience Act, the Digital Operational Resilience Act (DORA), the Digital Services Act (DSA), the Digital Markets Act (DMA) and more, which together, aim to form a framework to protect fundamental rights, promote trustworthy technology and level the playing field. However, in practice, the cumulative effect has been one of regulatory blur with overlapping scopes, inconsistent definitions, parallel reporting channels, fragmented enforcement and difficult interfaces between regimes.

The EU Commission proposed the Digital Omnibus in November 2025 to reduce, deconflict and streamline the regulatory burden. The result was an ambitious legislative proposal seeking to simplify and modernise several digital regulations simultaneously – including the GDPR itself.

What to watch: The proposal is still under negotiation in the EU legislative process. The most recent version of the Presidency compromise text is dated 21 May 2026, though it had not yet been officially published at the time of this blog post. The Digital Omnibus proposal cuts across multiple GDPR obligations as explained below – from the definition of personal data to legal basis, automated decision-making, cookies and data breach notifications.

2. The definition of personal data

The definition of personal data sits at the very heart of the GDPR: if data is not personal, the GDPR does not apply. The baseline position is that personal data is information related to an identified or identifiable natural person.

The EU Commission’s Digital Omnibus proposal intervened in this foundational question in a way that generated immediate and significant controversy. The EU Commission’s proposal intended to narrow that definition, claiming to translate Court of Justice of the EU (CJEU) case law into the letter of the law. This would have shifted the test from a risk-based to a capability-based approach, focused on the specific controller’s means rather than what any third party could do.

The European Data Protection Board (EDPB) and European Data Protection Supervisor, in their Joint Opinion, argued that the proposal misstates CJEU case law and risks “architecture gaming” to escape the GDPR’s scope. The pushback worked. The May 2026 Presidency proposal deleted the proposed redefinition entirely.

What to watch: The definition of personal data has not changed yet. For now, organisations should continue to apply the existing risk-based, context-sensitive framework. Any future change would need to be monitored closely, as it would have cascading effects on data mapping and compliance program scope.

3. Legal basis

Selecting and documenting the correct legal basis has always been a cornerstone of GDPR compliance. The Digital Omnibus proposal has focused particular attention on a long-standing challenge under  the GDPR: the use of personal data for AI and machine learning model training, an area in which the GDPR provides no explicit legal basis.

The EU Commission’s proposal would explicitly recognise legitimate interest as a lawful basis for AI development and operations. However, this recognition comes with meaningful guardrails: a balancing test, Legitimate Interest Assessment (LIA), would still be required and an unconditional right for individuals to object. The proposal would also add a new Article 9 condition permitting residual special category data processing, where removing that data would be unreasonably burdensome, provided appropriate safeguards are in place.

What to watch: Organisations using AI in their processing should conduct a rigorous LIA, under the existing framework. A statutory recognition of legitimate interest for AI training would represent useful certainty, but only if the final text preserves the safeguards proposed alongside it.

4. Automated decision-making

The entire structure of Article 22 has been proposed for reformulation – moving away from a “right not to be subject to automated decision-making”, toward a permission-based framework, where automated decision-making would be permissible under stated conditions.

More specifically, the proposed Digital Omnibus text directly states when automated decisions may occur. When evaluating whether an automated decision is “necessary” for a contract, controllers would not need to show that only an automated process could make the decision – the fact that a human could make the same decision would not, by itself, prevent use of an automated process.

Previously, authorities had been historically restrictive in interpreting the necessity requirement, in some cases requiring organisations to prove there could be no reasonable conduct of that decision process by a human. The proposed changes would have softened this considerably.

However, the latest Presidency draft is moving back toward a more restrictive approach, not following the initial EU Commission proposal that many had hoped would make it easier to implement AI-powered solutions.

What to watch: Organisations deploying AI in contexts that affect individuals – credit scoring, hiring, personalised content, medical triage – should ensure that their Article 22 analysis is current and that governance frameworks are fully documented. The final Digital Omnibus text will be critical here.

5. Cookies

For more than a decade, the European legislator has been trying to reform the ePrivacy Directive, a legal instrument that complements the GDPR by establishing specific rules for the confidentiality of electronic communications, governing issues such as tracking, monitoring and the use of cookies.

Successive legislative proposals to amend the ePrivacy Directive have always been withdrawn. The Digital Omnibus now proposes that certain activities that would involve access to the user’s terminal equipment or the processing of data through cookies would be integrated directly into the GDPR. The aim is to bring the same rules applicable throughout the EU in a harmonised, directly applicable regulation rather than a patchwork of differently transposed national laws.

The EU Commission’s proposal would create new consent exemptions for low-risk purposes and introduce standards for interpreting machine-readable signals expressing users’ choices, with the stated goal of reducing dependence on cookie banners and tackling consent fatigue.

One particularly significant proposed change concerns analytics. The processing of personal data for analytics or statistical purposes could be exempt from users’ consent requirements if certain conditions are met. One of the conditions would be that the data is directly collected by the controller itself or by a third party acting as a processor.

The Digital Omnibus proposal also codifies a number of consent rules that previously existed only as regulatory interpretation: withdrawing consent must be as easy as giving it; users must be given the opportunity to refuse; and controllers cannot immediately re-request consent after a user has declined. These rules, now being written into statute, will bring greater legal certainty to the industry.

What to watch: Cookie rules will not disappear – they will be much more harmonised and made more practical, but organisations should not wait for the final Digital Omnibus text. Audit your consent mechanisms against both the current law and the proposed new standards now.

6. EDPB guidelines

The EDPB is the EU’s overarching data protection body, comprised of representatives from each Member State’s national supervisory authority. Its core function is to foster consistency in the application of the GDPR across the EU. It also convenes to address areas requiring further clarity and issues guidelines, recommendations and opinions that help organisations understand how to interpret and comply with the Regulation in practice.

One might reasonably ask why organisations should pay attention to guidance that does not carry the force of statutory law. The answer is straightforward: EDPB guidelines are issued by the very same regulators that enforce the GDPR. They offer a direct window into how supervisory authorities read and apply the Regulation and when a data protection authority conducts an audit or brings an enforcement action, it will measure compliance against the standards it has itself publicly articulated. Ignoring EDPB guidance is, in practical terms, a significant compliance risk.

The pipeline of recent and upcoming EDPB guidance is substantial and covers a broad range of sectors and issues including:

• Anonymisation: Guidelines on anonymisation have been announced, with further details expected in due course.
• Scientific research (Guidelines 1/2026): Currently open for public consultation until 25 June 2026, these guidelines address the processing of personal data for scientific research purposes. They are particularly relevant for the pharmaceutical and life sciences sectors, providing welcome clarity on consent requirements and the conditions under which personal data may be used for secondary research purposes.
• User accounts in ecommerce (Recommendations 2/2025): Public consultation closed on 12 February 2025. A key finding is that ecommerce operators must offer a guest checkout option alongside any account-based purchase flow – a practical compliance point for any business operating an online retail presence.
• DMA and GDPR interplay (Joint Guidelines): Public consultation closed on 4 December 2025, addressing the intersection between the DMA and the GDPR – an increasingly important interface as gatekeepers navigate dual regulatory obligations.
• DSA and GDPR interplay (Guidelines 3/2025): Public consultation closed on 31 October 2025, clarifying how the DSA and the GDPR interact for online platform operators.

What to watch: This body of guidance reflects the EDPB’s growing ambition to provide sector-specific and cross-regulatory clarity. Organisations would be well-advised to monitor, and where appropriate, engage with the consultation processes as they arise.

7. International data transfers

Under the GDPR, transfers of personal data to third countries outside the EU and international organisations are restricted unless specific conditions have been met. The European Commission has the power to determine whether a country outside the EU offers an adequate level of data protection. The adoption of an adequacy decision follows a structured process:

• The European Commission tables a proposal
• The EDPB issues an opinion
• Representatives of EU Member States give their approval
• The European Commission formally adopts the decision

Where an adequacy decision is in place, the effect is that personal data can flow from the EU to that third country without any further safeguards being necessary. The EU essentially treats transfers to those jurisdictions as equivalent to intra-EU transmissions of personal data.

Without an adequacy decision, organisations transferring personal data outside of the EU must enact alternative transfer mechanisms, most commonly Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs), each of which carries its own negotiation, implementation and ongoing compliance costs. An adequacy decision eliminates that burden entirely, simplifying cross-border data flows and reducing legal and regulatory risk.

Adequacy decisions are not permanent. The European Commission is required to periodically review them, and the EU Parliament and Council may at any time request the European Commission to maintain, amend or withdraw a decision on the grounds that it exceeds the implementing powers provided for in the GDPR.

Below, we outline the key developments relating to the renewal and adoption of new adequacy decisions, reflecting the European Commission’s continued efforts to expand and maintain the network of jurisdictions from which personal data may flow freely from the EU:

• UK: The UK’s adequacy status under both the GDPR and the Law Enforcement Directive was renewed in December 2025, ensuring continued free data flows and reflected in the EU Commission’s updated list of recognised jurisdictions.
• Brazil received an adequacy decision on 26 January 2026. The decision comes with mutual recognition. Brazil’s Autoridade Nacional de Proteção de Dados (ANPD) adopted a resolution simultaneously enabling free data flows in both directions. The decision covers both public and private sector transfers – making it broader in sectoral scope than Canada’s commercial-organisations-only adequacy finding and broader than the US approach, which is limited to Data Privacy Framework-certified organisations. A carve-out applies for transfers relating to national defense, state security or criminal investigation, and the decision will be reviewed every four years.
• European Patent Organisation: The European Patent Organisation (EPO) received an adequacy decision on 15 July 2025 – the first adequacy decision ever granted to an international organisation. This means that personal data can be transferred from the EU to the EPO without additional safeguards such as standard contractual clauses. As the EPO is not subject to the GDPR itself, adequacy was assessed on the basis of the EPO’s own data protection rules, adopted in June 2021, which were found to offer protection comparable to GDPR safeguards. The EPO is an intergovernmental organisation headquartered in Munich, Germany with 39 contracting states, and the adequacy decision is scoped specifically to transfers in the context of patent-related processing.

The European Commission has to date recognised adequacy for (as of May 2026): Andorra, Argentina, Brazil, Canada (commercial organisations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, UK, the US (EU-US Data Privacy Framework), Uruguay and the EPO.

What to watch: For transfers to countries or international organisations not on the list, the standard contractual clauses remain to be the most widely-used mechanism. There has been a peak of enforcement in this area, with the Irish Data Protection Commissioner scrutinising companies that transfer data to countries like China on a regular basis.

8. GDPR fines

Recent GDPR enforcement in Europe has entered an era of landmark penalties against major technology companies, with European supervisory authorities levying an estimated €1.2 billion in fines during 2025 alone. Cumulative sanctions since the GDPR came into force in 2018 now stand at approximately €7.1 billion, with individual penalties against leading platforms now routinely exceeding the €200 million threshold for infringements ranging from unlawful international transfers of user data to third countries offering inadequate protections, to the absence of a valid lawful basis for processing personal data for behavioural analysis and targeted advertising, to the placement of advertising cookies and display of personalised advertising without valid user consent. This shows a pattern that reflects sustained and escalating regulatory vigilance, with big technology firms accounting for the largest GDPR fines ever issued.

We see more coordinated action by the European supervisory authorities, a more streamlined approach to ensuring that fines stand up and data protection authorities (DPAs) increasingly staffed with technical experts who can conduct granular reviews of processing activities. Enforcement is no longer simply reactive – triggered by a data subject complaint – but structural, with supervisory authorities proactively examining whether specific GDPR obligations are being met across sectors. One critically important and often overlooked point: fines are issued by supervisory authorities, not by judges. If an organisation receives a supervisory authority sanction decision, it has the right to appeal. Organisations are strongly recommended to, at least, seriously review whether an appeal is warranted.

What to watch: Take enforcement seriously, but also take your appellate rights seriously. A supervisory authority decision is not necessarily the final word.

9. Children’s privacy

Children’s privacy is arguably the defining topic of 2026 – and it is not a conversation happening only in the EU. In the UK, the US, and many other parts of the world, there is an intense focus on children’s privacy and the protection of children online.

In the EU, the primary legislative vehicle is the DSA. The UK equivalent is the Online Safety Act (OSA). Regulators are scrutinising online platforms used by minors with increasing rigor. Where regulators previously focused primarily on the removal of illegal content, the lens has now shifted significantly. Regulators are examining platform design and recommender systems, assessing whether platforms are addictive to children, checking whether age assurance or age verification mechanisms have been implemented, and reviewing whether platforms have incorporated dark patterns.  

The EU Commission published guidelines on the protection of minors in July 2025. These guidelines are intended to serve as a key benchmark for the EU Commission when applying Article 28(1) of the DSA, particularly in supervisory actions involving very large online platforms (VLOPs) and very large online search engines (VLOSEs).

The guidelines require online platforms to conduct a risk assessment when determining the appropriate mechanisms for protecting minors and clarify that a self-declaration of age by users will not be sufficient enough to comply with the DSA. The EU Commission reiterated in 2026 stakeholder discussions that self-declaration is insufficient for online platforms hosting adult content.

The EU has also developed a transitional age-verification app, made available in late 2025, as an interim solution until the EU Digital Identity Wallet becomes operational in 2026 – though use of that app remains optional. Online platforms may use other age-assurance mechanisms, provided those mechanisms do not require collecting or processing more personal data than is already processed to determine whether a user is under 18, as referenced in Recital 71 of the DSA.

Companies are implementing more robust age verification solutions, typically provided by third-party specialists. But these mechanisms often collect biometric data, such as photographs or copies of identity cards or passports, raising significant GDPR concerns that organisations must address alongside their DSA obligations.

What to watch: For any organisation whose services may be accessed by minors, children’s privacy is now a priority compliance issue. Age assurance strategies must be designed with the GDPR’s obligations built in from the outset, not added as an afterthought.

10. Data breach notifications

The threat environment is deteriorating. Ransomware-driven breaches are surging, especially in healthcare, finance and public services. Supply chain compromises through third-party vendors are rising and AI-powered intrusion techniques are becoming more common.

The GDPR’s 72-hour notification requirement for personal data breaches has always been one of its most operationally demanding provisions. Determining whether a breach crosses the threshold for notification – to the supervisory authority, to affected individuals, or both – requires rapid assessment under significant time pressure. The picture has now become more complex with the introduction of the NIS2 Directive, DORA and the Cyber Resilience Act, which impose parallel notification obligations that do not always align neatly with the GDPR’s requirements.

For organisations subject to the NIS2 Directive, the Cyber Resilience Act or DORA, on top of the GDPR, the notification requirements get even stricter: typically, a 24-hour early notice requirement, followed by a proper notification within 72 hours, with additional requirements kicking in later.

The Digital Omnibus may bring four meaningful changes under the GDPR:

• Raising the notification threshold so that only breaches likely to result in a high risk to individuals trigger notification
• Extending the notification deadline
• Channelling notifications through a single point of contact
• Introducing a harmonised notification template aimed at better aligning the GDPR with the NIS2 Directive, the Cyber Resilience Act and DORA

What to watch: Update your incident response plan under the law as it stands today. Plan for the overlapping requirements of the GDPR, the NIS2 Directive, DORA and the Cyber Resilience Act. Monitor the Digital Omnibus closely. If the notification threshold and single-reporting-point changes survive the legislative process, it would meaningfully reduce the operational burden of breach response.

Conclusion

The GDPR is not standing still; neither should your compliance program.Eight years in, the GDPR continues to reshape itself through enforcement, judicial decisions, regulatory guidance and legislative reform. The Digital Omnibus has the potential to be the most significant rewrite of the GDPR framework since it came into force – but political dynamics in Brussels remain fluid and the final outcome is genuinely uncertain.

For privacy and compliance professionals, this is demanding terrain. But understanding where the landscape is moving, and building the agility to respond, is precisely what allows you to move beyond simply reacting to enforcement.

This blog post is based on the Cooley DataWise webinar “GDPR Anniversary – 10 Things You Should Know About Last Year and What’s Coming Up This Year”, presented on 28 May 2026, by Patrick Van Eecke, Enrique Gallego Capdevila and Bartholomäus Regenhardt.

The post Blog Post: GDPR Anniversary – 10 Key Developments appeared first on cyber/data/privacy insights.

SB 24-205 was significant in its potential impact to financial institutions, with a murky exemption for financial institutions subject to substantially similar obligations and regulatory oversight. However, SB 189 entirely eliminates that exemption.

While SB 189 will impose less burdensome obligations on financial institutions than those in the 2024 law, the fact that it pulls regulated entities into its scope unambiguously by eliminating the limited exemption from SB 24-205 marks a new era in state AI laws for financial institutions.

Key changes from the 2024 law

Terminology

The most noticeable change between the old and new Colorado bills is the terminology and framing.

The prior law applied to “high-risk artificial intelligence systems,” which were defined broadly to encompass any AI system that, when deployed, makes, or is a substantial factor in making, a consequential decision. SB 189 replaces this framework with a more technology-neutral concept and terminology lifted from privacy regulations: “automated decision-making technology” (ADMT), which is defined as a technology that processes personal data and uses computation to generate output (including predictions, recommendations, classifications, rankings, scores or other information) that is used to make, guide or assist a decision, judgment or determination concerning an individual. An ADMT is subject to SB 189 when it is used to materially influence a consequential decision, which is generally a decision that impacts a consumer’s access, eligibility or opportunity to receive, among other things, a financial or lending service or insurance pricing or coverage (covered domains).

A “consequential decision” includes decisions that relate to a differentiated price, cost sharing, compensation or other material terms in a manner reasonably likely to materially limit, delay, effectively deny or otherwise fundamentally alter the consumer’s access, eligibility or opportunity for a covered domain. Relevant to financial institutions, SB 189 includes a handful of narrow exemptions:

• Activities relating to technologies used for cybersecurity, spam and robocall filtering, system reliability, and anti-money laundering and counter-terrorist financing controls.
• Activities relating to technologies used for sanctions compliance, excluding facial recognition unless its sole purpose is to confirm an individual’s identity.
• Activities relating to technologies used for fraud prevention, including identity verification, consumer identification, monitoring and reporting controls required under state or federal law.

While these carve-outs may offer relief for certain core financial services activities, just as in the prior version of the law, there is no entity- or data-level exemption for the Gramm Leach Bliley Act (GLBA) under SB 189. This means that the use of ADMT as part of the offering of financial, lending or insurance products or services to consumers is likely to be within scope of SB 189.

Reduced compliance obligations

SB 189 eliminates several of the most operationally burdensome requirements from SB 24-205, including:

• Anti-discrimination duty. Developers and deployers were required to use “reasonable care” to protect consumers from known or reasonably foreseeable risks of “algorithmic discrimination.”
• Impact assessments. Deployers were required to complete a detailed impact assessment before deploying a high-risk AI system and at least annually thereafter.
• Risk management policy. Deployers were required to implement a formal risk management policy and program governing each high-risk AI system deployment.
• Public website disclosures. Deployers were required to post on their website a statement summarizing all deployed high-risk AI systems and how they managed algorithmic discrimination risks.
• Reporting to the Colorado attorney general. Deployers discovering algorithmic discrimination were required to notify the attorney general within 90 days of discovery.
• Bank/credit union exemption. Banks, credit unions and their affiliates could claim full compliance if subject to regulations or an examination by a state or federal prudential regulator under guidance substantially equivalent to or more stringent than SB 24-205’s requirements.

What’s new and relevant to financial institutions

Limited disclosure safe harbor

A financial institution that is required to provide, and does provide, a notice to a consumer under the Equal Credit Opportunity Act (ECOA) and its implementing Regulation B, and where applicable under the Fair Credit Reporting Act (FCRA), complies with the notice and disclosure requirements of SB 189 for the same decision or adverse outcome. Functionally, this means that financial institutions that provide adverse action notices under ECOA or FCRA can leverage those existing structures, rather than providing redundant or duplicative notices to satisfy SB 189.

No mandatory disclosure where prohibited by law

SB 189 does not require a disclosure, explanation or furnishing of information to a consumer to the extent doing so would be prohibited by federal law (including the GLBA) or would compromise the confidentiality or integrity of cybersecurity, fraud prevention, anti-money laundering, counter-terrorist financing or economic sanctions compliance programs. Functionally, this means that the content of disclosures and notices can be limited in terms of level of detail or the provision of personal data, where these countervailing obligations take over.

Broader exemptions

While AI-assisted decisions involving financial or lending services fall within the law’s covered domains, SB 189 offers practical exemptions for tools used for anti-money laundering compliance, sanctions screening, fraud prevention and identity verification.

Practical takeaways for financial institutions

For financial institutions, the compliance burden under SB 189 generally is substantially lighter than under SB 24-205. The new statute eliminates several of the prior regime’s most demanding features, including mandatory risk management policies, annual impact assessments and reporting obligations to the attorney general. In their place is a more targeted set of requirements focused on consumer-facing obligations, including website disclosures, post-adverse outcome notices within 30 days, meaningful human review upon request and record retention for three years. However, due to the elimination of SB 24-205’s narrow bank and credit union exemption, regulated financial institutions can no longer assume that existing examination or regulatory frameworks may place them outside the law’s reach.

With the January 1, 2027, effective date approaching, financial institutions should begin preparing now. The attorney general is required to issue rules clarifying post-adverse outcome disclosure requirements and consumer rights by that date, and those rules may provide important sector-specific direction. In the meantime, institutions can begin identifying and mapping the AI tools they use in consequential decisions that may be within scope of SB 189.

Authors

Michael Egan

Mari Dugas

The post The New Colorado AI Act: What Financial Institutions Need to Know appeared first on cyber/data/privacy insights.

In recent years, NYDFS has focused attention on novel and accelerating risks, including AI-enabled attacks, sophisticated vishing schemes and cyber threats linked to global instability.

Artificial intelligence

On October 16, 2024, NYDFS published a letter to covered entities (letter) detailing cybersecurity risks related to AI and NYDFS’ guidance on risk mitigation strategies. NYDFS indicated that AI-related cybersecurity risk is a material change for businesses, triggering requirements for a refreshed risk assessment.

The letter describes examples of AI risks specifically related to cybersecurity, stemming from either a threat actor’s use of AI to enhance their attacks or from a covered financial institution’s own use of AI.

Threat actors increasingly use AI to enhance attacks and obfuscate their actions. NYDFS highlights that threat actors may use AI in social engineering attacks in particular (for example, in phishing or vishing attacks, or by using deepfake videos or AI-enhanced or -created photos). The FBI has similarly flagged threat actor use of AI in social engineering attacks as an increased risk for companies. The NYDFS letter also reminds regulated entities that threat actors often use AI in the course of technical attacks. For example, threat actors can use AI to augment their ability to “scan and analyze vast amounts of information,” “quickly and efficiently … identify and exploit security vulnerabilities,” “conduct reconnaissance” once inside a system, and “bypass defensive security controls, thereby evading detection.”

NYDFS also warns that introducing new third parties and vendors, such as AI providers, into a covered financial institution’s supply chain introduces new opportunities for vulnerabilities and potential compromise of the covered entity’s nonpublic information.

According to the letter, covered entities should consider AI-related cybersecurity risks in risk assessments. Risk assessments required by Part 500.2 must be updated annually, as well as “whenever a change in the business or technology causes a material change” to the covered entity’s cybersecurity risk profile. NYDFS  indicates that it considers risks posed by AI to be a material change. The overall takeaway is not that covered entities must deploy AI-specific controls, but that their risk assessments, training, access controls and governance structures should reflect the reality of AI-driven threats within the context of the institution’s risk profile.

‘Vishing’ and advanced social engineering

In line with the focus on MFA, NYDFS has repeatedly emphasized the growing sophistication of social engineering attacks, including voice-based schemes targeting employees, executives and customer service functions. “Vishing” attacks are a type of attack where threat actors use voice-based phishing to bypass traditional technical controls by exploiting human trust. An advisory issued to covered entities on February 6, 2026, warns that vishing is an increasingly common tactic. NYDFS specifically warned about threat actors posing as IT or help desk workers and tricking employees into providing credentials, including MFA, over phone calls.

NYDFS clearly expects covered entities to review their cybersecurity programs in light of this risk and advises that appropriate risk mitigation steps include:

• Implementing procedures to help employees verify the identity of a caller.
• Tailored training for employees in frequently targeted roles regarding the risk of vishing.
• Reviewing access controls and permissions regularly to ensure that if employees are compromised, they do not have more access than necessary, thereby mitigating some of the potential impact of a successful vishing attack.
• Reviewing MFA and evaluating the process for enrolling new methods of MFA.
• Deploying continuous monitoring and detection capabilities.

NYDFS’ overall message is clear: Covered entities should consider whether their controls – such as authentication, employee awareness and incident response – are calibrated to address the risk of vishing and other increasingly sophisticated social engineering tactics, not just traditional malware or network intrusions.

Global conflicts and geopolitical cyber risk

On March 3, 2026, NYDFS issued a new industry letter reminding covered entities that ongoing global conflict has elevated cybersecurity risk across the financial sector. While NYDFS’ letter noted that it had not observed a specific, coordinated campaign targeting covered entities at the time of issuance, the US intelligence community warned law enforcement agencies and private companies that the US financial sector has historically been viewed as a priority target.

The advisory letter serves as a prompt for covered entities to audit their existing compliance with Part 500 – underscoring that the regulation’s requirements are intended to be dynamic, and covered entities are expected to take the current geopolitical situation into account when assessing and responding to risk. The advisory’s specific recommendations – including prompt vulnerability remediation, least privilege enforcement, enhanced monitoring and operational resilience testing – map closely to core requirements, reminding entities that NYDFS views geopolitical threat escalation as an examination-readiness moment, not merely a general warning. Previous guidance issued to covered entities in June 2025 remains responsive to current geopolitical-driven cyber threats. State-aligned actors, spillover attacks and opportunistic campaigns can all affect covered entities.

NYDFS recommends that institutions review their risk assessments to consider whether geopolitical events warrant updates to their cyber risk profile. Covered entities should also closely assess their third-party service providers to determine if they pose additional risks.

Guidance also highlights that reviewing, testing and updating both incident response plans and business continuity and disaster recovery plans are key in mitigating the potential impact of a geopolitical-related cyber event. The amendments to Part 500.16 mirror this guidance, requiring covered entities to have in place a business continuity and disaster recovery plan that is “reasonably designed to ensure the availability and functionality of the covered entity’s information systems and material services and protect the covered entity’s personnel, assets and nonpublic information in the event of a cybersecurity-related disruption to its normal business activities.” Business continuity and disaster recovery plans should be annually reviewed and tested, include procedures for timely recovering critical data and systems, address backup processes and offsite data storage, and be provided to employees with training.

The potential for geopolitical cyber events reinforces NYDFS’ emphasis on resilience: incident response planning, business continuity and the ability to respond quickly to evolving threats. While Part 500 does not require covered entities to predict specific geopolitical events, NYDFS expects them to recognize that global instability can increase cyber risk and adjust their cybersecurity programs accordingly.

Final thoughts

The annual cybersecurity certification process sits at the intersection of law, technology and risk management. As NYDFS’ enforcement of Part 500 evolves – and as the threat landscape grows more complex – financial institutions should view the certification process as an opportunity to assess whether their cybersecurity programs truly align with Part 500 and regulatory expectations. By understanding how NYDFS views key updates to Part 500 within the broader cybersecurity threat landscape, including its focus on MFA and emerging threats, institutions can approach certification with greater confidence and resilience.

The post Part 3: Looking Ahead – Novel Cybersecurity Issues and Department Priorities appeared first on cyber/data/privacy insights.

MFA is a baseline requirement, but not a one-size-fits-all control

Under the amendments to Part 500, MFA is now required for any person accessing a covered entity’s information systems, unless an exemption is approved in writing by the chief information security officer (CISO), or senior-most executive responsible for cybersecurity if the covered entity does not have a CISO. To comply with the requirements, the MFA must consist of at least two distinct authentication factors drawn from three different categories: knowledge (something you know), possession (something you have) or inherence (something you are). Using two factors from the same category (for example, a password and a security question – both something you know) does not satisfy the requirement.

While NYDFS stated that it is agnostic on specific MFA solutions, it reiterated that covered entities are expected to select MFA solutions and vendors appropriate for their specific risk profile. NYDFS’ “Let’s Talk MFA” presentation emphasized that simply deploying an MFA solution is not sufficient to meet the requirements if the configuration is weak or can be bypassed.

Specific use cases: Single sign-on, cloud platforms and external-facing websites

NYDFS highlighted a few specific use cases drawn from industry questions it received regarding Part 500’s updated MFA requirements. First, NYDFS confirmed that single sign-on (SSO) solutions are permitted under Part 500, provided that MFA is enforced and cannot be effectively bypassed through SSO. 

NYDFS also made explicit that cloud-based email, document hosting and other software as a service (SaaS) platforms are considered part of a covered entity’s “information systems” for purposes of Part 500, even when provided or managed by third parties. The entity must comply with Part 500 with respect to these platforms, and MFA must be enforced consistently on these platforms, including for privileged users. NYDFS stated that covered entities may not rely solely on a provider’s default MFA settings to satisfy Part 500 obligations. Instead, institutions are expected to evaluate whether those controls are compliant with Part 500 and appropriate to the covered entity’s risks, information systems and data.

Lastly, NYDFS addressed external-facing resources, a common question regarding the expansion of Part 500’s requirements. External websites intended solely for public consumption do not require MFA because they do not provide access to nonpublic information (NPI). However, NYDFS cautioned that if an external-facing system hosts NPI or poses a material risk to the covered entity or its customers, MFA to access those pages would be required. In practice, this means customer portals that provide access to NPI or other account information must have compliant MFA.

Privileged access remains a supervisory focus

NYDFS noted in the webinar that it continues to observe weaknesses where privileged or administrative users are not consistently subject to MFA. Because privileged access is inherently higher risk, NYDFS expects covered entities to address it explicitly in their risk assessments and consider appropriate MFA. The MFA used for standard access, NYDFS warned, may not be considered compliant for privileged access if privileged access poses significantly more risk to the covered entity’s information systems or NPI.

What NYDFS will look for in examinations

In the presentation, NYDFS noted that its supervisory exams will focus on:

• Whether MFA is implemented where required.
• Whether high-risk systems and users are appropriately protected through the use of MFA.
• The configuration of MFA and its effectiveness.
• The MFA’s ability to prevent phishing, replay attacks and technical bypasses.
• How MFA integrates with the covered entity’s incident detection and response.

In short, NYDFS expects MFA to function as a meaningful security control and not a check-the-box exercise.

Practical takeaways

For covered entities, the “Let’s Talk MFA” presentation reinforces that MFA is now a foundational cybersecurity control under Part 500. Covered entities should ensure that their MFA programs are risk-based, well-documented, consistently enforced (particularly for privileged users and cloud platforms), and supported by strong governance and monitoring.

As NYDFS continues to refine its guidance and enforcement posture, covered entities that can demonstrate thoughtful design and substantive risk analysis will be best positioned in examinations and supervisory inquiries.

Stay tuned for the final installment of our Part 500 refresher series, where we’ll explore how NYDFS has tackled emerging and novel cybersecurity issues.

Authors

Mari Dugas

Mike Egan

Kate Goodman

Elyse Moyer

Bekah Putz

The post Part 2: NYDFS Sharpens Its Focus on Multifactor Authentication appeared first on cyber/data/privacy insights.

Every year by April 15, financial entities subject to the New York Department of Financial Services (NYDFS) oversight (covered entities) are required to certify their compliance with the NYDFS’ cybersecurity regulations, 23 NYCRR Part 500 (Part 500). This year’s deadline will be the first time covered entities must certify compliance with all of the amendments to Part 500 that were phased in from November 2023 through November 2025 (Part 500 amendments).

This series will highlight key aspects of Part 500’s amendments, as well as recent NYDFS guidance, and provide insight into how NYDFS may assess compliance with Part 500.

Part 1 addresses asset inventories and risk assessment amendments, Part 2 details updated requirements for multifactor authentication and Part 3 explores the emerging cybersecurity issues that NYDFS has identified as key priority areas. 

Certification requirements

Certifications of compliance are affirmative representations by a covered entity’s chief information security officer (CISO) or senior most executive responsible for cybersecurity, attesting that the covered entity is in compliance with Part 500, and that the certification has been made upon the certifying individual’s review of the documents and controls upon which the certification is based. Certifications must be accurate, as making false statements to NYDFS itself is actionable, in addition to any substantive violations of Part 500. Additionally, the certifying individual could be held personally liable for certifying false statements to NYDFS. NYDFS has made clear through examinations, consent orders and explicit guidance that it expects certifications to be accurate, supportable and grounded in documented controls.

With the Part 500 amendments now in effect, NYDFS provides covered entities with two options: Submit a certification of material compliance, or submit an acknowledgement of noncompliance. An acknowledgement of noncompliance must contain:

1. An acknowledgment that the covered entity did not materially comply with Part 500.
2. An identification of all sections of Part 500 that the entity is not in material compliance with.
3. A description of the nature and extent of noncompliance.
4. A remediation timeline or confirmation that remediation has been completed for the areas of noncompliance.

Part 500.13: Asset inventories

One of the most significant developments under the amended Section 500.13, effective November 2025, explicitly requires covered entities to maintain an inventory of all assets, not just those that are material to the covered entity or contain nonpublic information (NPI). This reflects NYDFS’ position that institutions cannot protect systems, devices and data they do not know they have. Numerous other Part 500 requirements rely on functional asset inventories, including risk assessments, access controls, vulnerability management and incident response planning. Deficiencies in asset inventories can cascade into compliance gaps with these provisions of Part 500 as well.

An asset management policy should cover the entire asset life cycle – from onboarding and classification to tracking, support and eventual deprecation. The policy should also document a cadence for reviewing, updating and validating the asset inventory. The asset inventory itself should identify owner, location and recovery time objectives for each asset.

The Part 500 amendments make clear that covered entities cannot treat asset inventories as a static list of systems, devices and data; the inventory is meant to be a living record.

Part 500.9: Risk assessments

Risk assessments have always been central to Part 500, but the amendments reinforce their role as the driver of the cybersecurity program and the basis on which a program is evaluated. NYDFS now requires covered entities to conduct risk assessments at least annually and whenever material business or technology changes occur, which could include geopolitical events.

This reflects NYDFS’ position that a risk assessment cannot be static, generic or disconnected from operational reality. A risk assessment serves as the evidentiary bridge between hypothetical risk and implemented controls. A covered entity that cannot demonstrate how its cybersecurity measures are appropriate in the context of assessed risks may face questions about the sufficiency of its overall compliance and certification with Part 500.

Looking ahead

For covered entities, the annual certification should be approached as a governance exercise, not a formality. Individuals responsible for preparing for certifications should take care to review the institution’s compliance posture holistically, building on the asset inventory and risk assessment controls as the key components underpinning compliance.

In our next post, we turn to one of the most heavily scrutinized areas of the amended Part 500: multifactor authentication.

Authors

Michelle Rogers

Michael Egan

Kate Goodman

Mari Dugas

The post NYDFS Refresher Series – Part 1: What Companies Need to Know Ahead of Annual Certifications of Compliance appeared first on cyber/data/privacy insights.

Read the full article on Cooley.com

The post South Korea’s AI Basic Act: Overview and Key Takeaways appeared first on cyber/data/privacy insights.

The post EU AI Act: Proposed ‘Digital Omnibus on AI’ Will Impact Businesses’ AI Compliance Roadmaps appeared first on cyber/data/privacy insights.

This blog post explores the following three key latest developments and their implications:

• Draft Provisions on Personal Information Protection for Large Online Platforms (released for comments on November 22, 2025)
• Draft Measures for Cyberspace Supervision and Inspection by Public Security Authorities (released for comments on November 29, 2025)
• Draft Measures for Network Data Security Risk Assessment (released for comments on December 6, 2025)

Draft Provisions on Personal Information Protection for Large Online Platforms (LOP Provisions)

1. Scope of large online platforms (LOPs)

The LOP Provisions apply to LOPs that are established and operated in China. The Cyberspace Administration of China (CAC), the Ministry of Public Security (MPS) and other competent authorities will designate a platform as a LOP by considering whether such platform:

• Has more than 50 million registered users or more than 10 million monthly active users.
• Provides critical network services or operates across multiple types of businesses.
• Possesses or processes data that, if leaked, tampered with or damaged, would have a significant impact on national security, economic operations or public welfare.
• Falls into the scope of other circumstances as determined by the CAC and the MPS.

Designated LOPs will be listed in a catalogue and maintained by the CAC, MPS and other competent authorities.

2. Appointment of the “person responsible for personal information protection” (DPO)

A LOP must appoint a DPO and disclose their contact information. The DPO must be a member of the management level of the LOP, hold the nationality of the People’s Republic of China (PRC) and have no overseas permanent residence or long-term residence permit. In addition, the LOP Provisions also require the DPO to possess professional knowledge in personal information protection and have more than five years of relevant experience.

The DPO’s duties include, without limitation, guiding the LOP’s personal information processing compliance efforts, participating in decision-making related to personal information processing matters and exercising veto rights over such matters, supervising the processing activities and security measures adopted, and leading the development of rules for minors’ privacy protection. Note that the LOP Provisions empower the DPO to report personal information protection matters related to the LOP directly to the CAC and other competent authorities.

3. Data localization and cross-border data transfer requirements

LOPs are required to store personal information collected and generated from their operations in China locally. Cross-border transfers are allowed only if such transfers are necessary and will be conducted by LOPs in compliance with data transfer requirements under Chinese laws. In addition, the LOP Provisions impose specific requirements for data centers in which LOPs store data, including:

• The data center must be located in China.
• The person in charge of the data center must hold PRC nationality and have no overseas permanent residence or long-term residence permit.
• The data center’s security capabilities must comply with the requirements under applicable national standards in China.

LOPs are also obligated to file certain information of the data centers used by them with the CAC and other competent authorities, such as the data centers’ management team and organizational structure, internal personal information protection policies, security measures adopted, and contracts signed with the data centers.

Draft Measures for Cyberspace Supervision and Inspection by Public Security Authorities (MPS Supervision and Inspection Measures)

These new draft MPS Supervision and Inspection Measures establish procedural rules and inspection criteria for public security authorities – i.e., China’s police force, the public security bureaus (PSBs) – and are intended to replace the existing Regulations on the Internet Security Supervision and Inspection by Public Security Authorities released in 2018.

1. Scope and applicability

The draft MPS Supervision and Inspection Measures permit PSBs to conduct inspections on the following types of entities:

• Internet service providers offering services, such as internet access, data centers, content delivery services, domain name services and information services.
• “Public internet access service providers” (e.g., hotels, hospitals or other public places that provide publicly available Wi-Fi connection).
• “Network operators” (i.e., entities that own or use networks to operate or provide services), along with their developers and maintenance providers.
• Critical information infrastructure operators, along with their developers and maintenance providers.
• Providers of network products and services.
• Data handlers and personal information handlers (i.e., entities that independently determine data/personal information processing purposes and means).

2. Inspection power of PSBs

Under the draft MPS Supervision and Inspection Measures, PSBs have the power to conduct both online and onsite inspections to assess an entity’s posture in cybersecurity, “information security” (undefined under these measures but likely referring to online content safety) and data security through measures such as “network information patrols,” “information review capability tests” (undefined under these measures but likely referring to content moderation capability), and vulnerability scanning. PSBs must focus their inspections on assessing whether the inspected entity has complied with certain key compliance requirements, including without limitation:

• Developing and implementing cybersecurity, “information security,” and data security management program and operating procedures.
• Recording and retaining required user registration information and internet logs.
• Compliance with the obligations under China’s cybersecurity multilevel protection scheme (MLPS).
• Adopting technical measures to prevent viruses, cyberattacks and network intrusions.
• Providing technical support and assistance to PSBs for safeguarding national security, preventing and investigating terrorist activities, and investigating crimes.

Draft Measures for Network Data Security Risk Assessment (Risk Assessment Measures)

The Risk Assessment Measures define network data security risk assessment as “the identification, analysis and assessment of the risk associated with network data[i] and network data processing activities.”

Network data handlers[ii] processing “important data”[iii] (important data handlers) are mandatorily required to proactively conduct the risk assessment on an annual basis. Other data handlers that do not process “important data” are encouraged to conduct the risk assessment at least every three years. Risk assessments can be conducted by network data handlers themselves or third-party institutions engaged by them. In addition to the risk assessment proactively conducted by network data handlers, the CAC and other competent authorities may also mandate network data handlers to engage a third-party institution to conduct risk assessments under the following circumstances:

• Where network data processing activities pose significant security risks.
• Where a network data security incident occurs, resulting in the leakage or theft of “important data” or large-scale personal information.
• Where network data processing activities may endanger national security or public interests.
• Other circumstances determined by the CAC or other competent authorities.

When conducting an annual risk assessment, important data handlers shall prepare an assessment report in accordance with the template attached to the Risk Assessment Measures and file such an assessment report with the competent authority (or the CAC, if the competent authority for an important data handler is unclear). Competent authorities and the CAC at provincial level or above may conduct random inspections and verifications of the authenticity and accuracy of the assessment reports, and network data handlers shall provide assistance.

Next Steps

Violations of these three regulations will be subject to applicable penalties imposed under the CSL, DSL and the PIPL. Companies providing services to Chinese customers and users should assess the applicability of these regulations and closely monitor their developments.

A Chinese translation of this post is available here.

Authors

Will Pao, Partner, Los Angeles

Zhijing Yu, Associate, Singapore

Cooley LLP is not licensed to practice the law of the People’s Republic of China (PRC), and nothing herein constitutes an opinion or legal advice by Cooley with respect to PRC laws or otherwise. This blog may not be relied upon, construed as or used as an opinion, interpretation of or legal advice in any respect relating to or arising out of PRC laws or otherwise. This blog, and our review of the information referenced in this blog, is based solely upon our general familiarity with matters of the type referenced in this blog and the consultation with PRC counsel with respect to certain matters of PRC law or practice, as referenced in the blog, provided that notwithstanding such consultation, no opinions or legal advice with respect to PRC law are made herein. Any analysis, conclusion, advice or opinion with regard to PRC laws, or otherwise with regard to any of the matters referenced in this blog, must be obtained from PRC local counsel.

[i] “Network data” refers to electronic data processed and generated through networks.

[ii] “Network data handlers” refers to individuals or organizations that independently determine data processing purposes and means.

[iii] “Important data” refers to data in specific fields, specific groups or specific regions, or data that has reached a certain level of accuracy and scale, which, if tampered with, damaged, leaked or illegally obtained or used, may directly endanger national security, economic operations, social stability, public health and safety.

The post China Releases Multiple Key Draft Cyber and Data Security Regulations at Year-End 2025 appeared first on cyber/data/privacy insights.

The UK Information Commissioner’s Office (ICO) has released updated guidance on encryption following a recent consultation.

The revised guidance provides a framework outlining when and how organisations should consider implementing encryption to protect personal data. The guidance does not cover end-to-end encryption, privacy-enhancing technologies or the potential implications of quantum computing. 

Although the UK General Data Protection Regulation (GDPR) does not specifically require companies to use encryption or encrypt all personal data they hold, the ICO strongly recommends implementing encryption as a robust technical measure to support the secure processing of data.

The ICO’s updated encryption guidance adopts its “must, should, could” framework: “must” denotes legal obligations, “should” reflects strong expectations for compliance and “could” offers optional best practices. This article focuses on the non-negotiable musts, because understanding and implementing these legal requirements is essential for organisations aiming to avoid regulatory risk.

What must companies do?

Although encryption is not mandatory, the ICO advises that it should be widely used – even in lower-risk situations – alongside other appropriate measures. Encryption is now well established, widely available and low cost, making it an appropriate and practical measure to support organisations’ compliance with data protection legislation.

However, there are a number of non-negotiable requirements for using encryption tools under the new guidance. Organisations must:

• At a general level, put in place appropriate technical and organisational measures to uphold data protection principles and integrate necessary safeguards into organisations’ processing activities. This includes the use of any encryption tools, and measures must be considered both at the design phase and throughout the life cycle of the processing.
• Consider the state of the art of technology and the cost of implementing that measure. This is required when you assess whether a technical or organisational measure is appropriate and is implied to include encryption within its scope. As technology evolves, so must organisations’ encryption standards.
• Consider the necessity of encryption at the design phase of any processing activity.
• Avoid the use of SSL. The guidance notes SSL’s known vulnerabilities and its potential to compromise the security of personal data. Using SSL may result in noncompliance with UK GDPR security obligations, and it must not be used under any circumstances, including public-facing HTTPS implementation.  
• Ensure compliance with legal obligations when processing encrypted data. This includes setting an appropriate review period for encryption use and assessing whether a personal data breach involving encrypted data must be reported to the ICO.
• Use in-transit encryption for your online applications (e.g. TLS) to prevent unauthorised access to data if it is intercepted during transmission.
• Implement robust user authentication mechanisms for accessing encrypted personal data.
• Ensure technical measures are in place to restore availability and access to encrypted personal data promptly in the event of an incident.
• When determining encryption use and backup retention periods, consider the right to erasure under Article 17 of the UK GDPR and how it may apply.

Next steps

In light of the guidance, companies should review their encryption practices and broader data security policies to ensure alignment with UK data protection law. For support with auditing your encryption measures, drafting a tailored encryption policy or any wider queries around compliance with UK data protection legislation, please contact the Cooley team below.

Authors

Guadalupe Sampedro, Partner, London

Dan Millard, Associate, London

The post ICO Updates Guidance on Encryption appeared first on cyber/data/privacy insights.

The case arose from misaddressed annual pension benefit statements sent to current and former Sussex police officers. The High Court had previously struck out the claims on the basis that there was no evidence that the statements were ever opened or read by third parties. The Court of Appeal confirmed both that disclosure was not essential for a GDPR infringement, and that claimants could recover compensation for fear of the consequences of an infringement if that fear was objectively well-founded, rather than hypothetical or speculative.

Note: The breach occurred in 2019, before the end of the Brexit transition period (31 December 2020). At that time, the European Union GDPR applied directly in the UK, so claims were assessed under the EU GDPR rather than the UK GDPR. However, the Court of Appeal noted that there are no material differences between the two regimes for these purposes.

Case background

In 2019, Equiniti, acting as administrator of the Sussex Police pension scheme, posted pension statements in window envelopes to more than 750 out-of-date residential addresses. The statements contained personal details, including dates of birth, national insurance numbers and information on salaries and accrued benefits. Sussex Police had provided Equiniti with up-to-date addresses which were uploaded to Equiniti’s database, but when the statements were produced, Equiniti’s system used the out-of-date addresses in error.

The Information Commissioner’s Office (ICO) was notified and concluded that the risk of individuals suffering significant consequences was unlikely. It took no enforcement action. 474 officers brought claims, seeking £1,250 each. They alleged:

1. Breaches of statutory duties under the GDPR/DPA, focusing on data minimisation, accuracy, fairness, integrity and confidentiality (Article 5) and appropriate technical/organisational measures (Articles 24, 25 and 32).
2. Misuse of private information, centred on “anxiety, alarm, distress and embarrassment” amounting to nonmaterial damage, with some claimants also alleging aggravation of preexisting medical conditions.

At first instance, the High Court struck out most claims on the basis that, unless a claimant could show that the statement was opened/read by a third party, there was no viable case, as there was no “processing” under the GDPR.

Court of Appeal decision

GDPR claim – Processing without disclosure

The Court of Appeal held that the judge was wrong to require the statements to have been opened/read by a third party. Mailing statements to the wrong addresses was itself “processing” under the GDPR, which covers any operation on personal data, not just disclosure. Equiniti’s database handling, printing and posting all fell within the definition of “processing”.

Compensation principles

• No threshold of seriousness. The Court of Appeal confirmed that there is no “de minimis” threshold for compensation under Article 82 of the GDPR. Following EU case law on this topic (e.g., Austrian Post), compensation cannot be denied simply because harm is modest.
• Distress not the only label. Nonmaterial damage is broader than “distress” alone. While Section 168 DPA makes clear that “non-material damage” under Article 82 GDPR includes distress, this is an umbrella term for various forms of emotional harm, including those listed in Recital 85 GDPR. Claims framed as “stress” or “anxiety” are not automatically out of scope.
• Fear of misuse must be “well-founded”. Claims based on fear of identity theft or misuse can succeed, but only if fears are objectively reasonable in the circumstances. Purely speculative or hypothetical risks will not qualify.
• Psychiatric injury. Where well-founded fears lead to recognisable psychiatric conditions, compensation is also recoverable in principle.

What this means for businesses

• Misaddressing or misdirecting personal data is still “processing” under the GDPR and may be an infringement even if nobody opens or reads the communication.
• Claims for fear/anxiety can proceed if objectively reasonable, with the “well-founded fear” test as the filter.
• Organisations cannot argue that a breach is “too minor” to generate liability under the GDPR.
• Where anxiety escalates into psychiatric injury, compensation may be recoverable (subject to the “well-founded fear” test).

Notification and litigation risk

A paradox highlighted by this case is that breach notification itself can create liabilities and generate claims. Informing individuals of a breach may give rise to anxiety, distress or other nonmaterial damage based on well-founded fears. In Farley, many officers said the notification letters triggered their concerns about identity theft or misuse.

Bottom line

The Court of Appeal did not decide whether these claims were successful; instead, it remitted them to the High Court for a detailed review. Some may ultimately fall away, and even successful claims are likely to result in modest awards.

However, Farley confirms that organisations may face litigation risk for data breaches even where disclosure never occurs and the alleged harm is modest. Businesses should maintain robust accuracy and security controls, consider their communications carefully when breaches arise and be prepared to defend claims based on well-founded fears.

[1] [2025] EWCA Civ 1117.

Authors

Ann Bevitt, Partner, London

Morgan McCormack, Associate, London

The post English Court of Appeal Rules on Compensation for Data Breaches appeared first on cyber/data/privacy insights.

The post What the UK’s New Data (Use and Access) Act Means for Your Business appeared first on cyber/data/privacy insights.

The post Comparing New Neural Data Privacy Laws in 4 US States appeared first on cyber/data/privacy insights.

• Describes what is a “covered data transaction” under the rule.
• Summarizes the two kinds of covered data transactions subject to the rule – those that are prohibited versus merely restricted.
• Describes the rule’s privacy and cybersecurity requirements for restricted transactions, which are numerous and challenging to implement.
• Includes a checklist of next steps for companies to assess their exposure to the rule and resulting compliance obligations.

For quick reference, this flowchart can help assess if a transaction might be subject to the rule.

The rule took effect on April 8, 2025, but was recently deprioritized for enforcement in a temporary reprieve by the DOJ that expires July 8, 2025. This deadline is rapidly approaching, and companies should promptly assess whether they have any current or anticipated covered data transactions. If so, they should not delay implementing the rule’s privacy and cybersecurity requirements, which will take time, as well as both legal and technical resources. Violating the rule can be severe because the rule has teeth. Violations entail civil penalties (fines the greater of $368,136 or twice the value of the transaction) and also can incur criminal penalties (fines of up to $1,000,000 and 20 years in prison). 

What transactions are covered by the DOJ’s bulk data transfer rule? 

The rule applies to “covered data transactions,” which may be either prohibited or restricted depending on the type and quantity of data and processing involved. 

A covered data transaction is a transaction that involves access by a country of concern or covered person to bulk US sensitive personal data or government-related data, and that involves a data brokerage, investment agreement, employment agreement or vendor agreement. Exempt transactions avoid much of the rule. We discuss the bolded terms below. 

Access

Access is defined broadly under the rule to mean any logical or physical access without regard to whether security measures, such as access controls, actually deny access.  For example, this means that a person located in China, who has access to a database containing bulk US sensitive personal data but for whom access controls prevent them from actually accessing the data, is still considered to have “access” to the data for purposes of determining whether the rule applies.  

Country of concern or covered person

• Countries of concern include China (including Hong Kong and Macau), Cuba, Iran, North Korea, Russia and Venezuela. 
• Covered persons include entities and individuals in four categories:
  • Foreign individuals primarily resident in countries of concern.
  • Foreign entities that are 50% or more owned (directly or indirectly) by a country of concern, organized under the laws of a country of concern or have their principal place of business in a country of concern (including, potentially, a foreign subsidiary of a US company).
  • Foreign entities that are 50% or more owned (directly or indirectly) by a covered person.
  • Foreign employees or contractors of countries of concern, or of entities that are covered persons.

Bulk US sensitive personal data and government-related data

• Bulk US sensitive personal data is sensitive data of certain thresholds depending on the type of data, regardless of whether the data is anonymized, pseudonymized, de-identified or encrypted:
  • Human genomic data on more than 100 US persons
  • Other human ‘omic data on more than 1,000 US persons.
  • Biometric identifiers on more than 1,000 US persons.
  • Precise geolocation data on more than 1,000 US devices.
  • Personal health data on more than 10,000 US persons.
  • Personal finance data on more than 10,000 US persons.
  • Covered personal identifiers on more than 100,000 US persons. 
• Government-related data includes certain types of data related to certain sensitive locations (such as relating to national security or intelligence), military installations, or current or former government employees or contractors.      

Investment agreement, employment agreement, vendor agreement and data brokerage

• Investment agreements involve agreements in which a person or entity obtains direct or indirect ownership rights in US real estate or a US legal entity, with some exceptions for passive investments.
• Employment agreements involve typical workforce arrangements.
• Vendor agreements involve arrangements where a person or entity provides goods or services to another for payment or other consideration.
• Data brokerage means selling (or licensing access to) data, where the recipient of the data did not collect the data directly from the individuals associated with the data. 

Do any exemptions apply to DOJ’s bulk data transfer rule?

Even if a transaction is a covered data transaction as described above, it may nevertheless be exempt from certain obligations in the rule if it falls within one or more exemptions. Exemptions include:

• Personal communications. Data transactions such as postal and telephonic communications, provided the communication does not transfer anything of value.
• Informational materials. Data transactions that involve importing or exporting information or informational materials to or from any country.
• Travel. Data transactions that are ordinarily incident to travel between countries for personal purposes.
• Financial services. Data transactions ordinarily incident to financial services, such as those provided by financial institutions (e.g., banking, capital markets and financial-insurance services), the transfer of personal financial data incidental to the purchase and sale of goods, the provision of payments or funds transfers involving personal financial data or covered personal identifiers, and the provision of investment management services that manage or provide advice on investments for compensation.
• Corporate group transactions. Data transactions between US companies and subsidiaries or affiliates located in countries of concern that are ordinarily incident to business operations, such as human resources, payroll, risk management and customer support. This exemption is narrower than it sounds as it is limited to transactions that are incidental to standard business operations.  
• Investment agreements subject to a Committee on Foreign Investment in the United States (CFIUS) agreement or condition to resolve a national security risk.
• Telecommunication services. Data transactions ordinarily incident to and part of providing telecommunications services.  
• Certain exemptions relevant to life sciences companies, such as exemptions for data transactions that are part of clinical investigations, involve regulatory approval data and/or are conducted pursuant to federally funded research, are discussed in more detail in our previous post on the rule.

The exemptions are informed by examples in the rule and the DOJ’s FAQs. Commentary from the DOJ suggests that the exemptions are viewed narrowly. Given the rule’s novelty, the breadth of these exemptions in practice remains to be seen.

Is a covered data transaction prohibited or restricted?

A covered data transaction is prohibited if it involves a US person engaging in a transaction that involves:

• Data brokerage with covered persons or countries of concern.
• Data brokerage with foreign parties that are not covered persons or countries of concern, unless there are certain contractual protections in place.
• Access to bulk human ‘omic data (including genomic, epigenomic, proteomic or transcriptomic data) or human biospecimens from which bulk human ‘omic data can be derived. 

A prohibited transaction means just that: It is simply prohibited. 

A covered data transaction is restricted (rather than prohibited) if it involves the following:    

• An employment agreement.
• A vendor agreement, wherein a covered person or a country of concern is providing goods or services to a US person in exchange for compensation.
• An investment agreement.

See the above section on which transactions are covered by the rule for more details on these types of agreements.

Restricted transactions are allowed to proceed under the rule, so long as the company implements privacy and cybersecurity measures. 

In determining coverage by the rule, companies are prohibited by the rule from making arrangements that have the purpose of evading or avoiding the rule. 

What are the compliance requirements for restricted transactions?

As noted above, restricted transactions are permitted so long as the company engaging in such transactions implements a rigorous data compliance program and the security requirements issued by the Cybersecurity and Infrastructure Security Agency (CISA).  An overview of each component is provided below. 

CISA security requirements

• Organizational- and system-level requirements:
  • Implement basic organizational cybersecurity policies, practices and requirements.
  • Implement logical and physical access controls.
  • Conduct an internal data risk assessment.
• Data-level mitigation involving a combination of the following that, when taken together, prevents access to covered data that is linkable, identifiable, unencrypted or decryptable using commonly available technology by covered persons and/or countries of concern:
  • Apply data minimization and data masking strategies.
  • Apply encryption techniques.
  • Apply privacy enhancing technologies.
  • Configure identity and access management techniques.

Data compliance program requirements  

A data compliance program must include:

• Risk-based procedures for verifying data flows in restricted transactions and the identity of vendors.
• A written policy describing the program, certified annually by the senior employee responsible for compliance.
• A written information security policy (including description of implementation of the CISA security requirements), certified annually by the senior employee responsible for compliance.

Recordkeeping and audit requirements

• Recordkeeping under the rule requires records/documentation of the following to be kept for at least 10 years:
  • The written data compliance program and information security policy.
  • Results of the annual restricted transaction compliance audit.
  • Due diligence.
  • Transfer details. 
  • Licenses or advisory opinions.
  • An annual certification of the completeness and accuracy of such records by the senior employee responsible for compliance.
• Audit
  • An audit must be conducted by an independent individual and use a reliable method that examines all restricted transactions, the data compliance program, required recordkeeping and the implementation of the CISA security requirements.
  • The audit must result in a written report that is retained for at least 10 years.

What should all companies do now to address the DOJ’s bulk data transfer rule?

Companies should first assess whether they have any current or anticipated transactions subject to the rule, which may not be an easy task given that a “transaction” is loosely and broadly defined. Next, companies should determine whether their transactions are simply prohibited under the rule, or merely restricted. Companies also should see if they can take advantage of any exemptions to mitigate exposure under the rule. Finally, companies with restricted transactions should promptly implement the privacy and cybersecurity measures required under the rule. Contact a member of Cooley’s cyber/data/privacy team to leverage our guidance across different industries and existing compliance materials to help you get ahead of the rule. 

1. Conduct diligence to determine whether you currently and/or expect to engage in covered data transactions. For example:
   • Analyze a data map to determine the types and quantity of data handled and whether they meet the rule’s thresholds.
   • Analyze data flows and recipients to determine whether a country of concern or covered person has access to such data.
   • Analyze contractual arrangements with corporate affiliates/subsidiaries, partners and vendors to determine if a transaction involves a data brokerage, investment agreement, employment agreement or vendor agreement.
2. Consider ways to mitigate exposure to the rule, such as by applying exemptions or recharacterizing/revising data flows, but without violating the rule’s prohibition on acts designed to evade the rule.
3. Determine whether the covered data transactions are prohibited or restricted. Undertake a review of any data brokerage, vendor, employment and investment agreements to determine whether the rule may apply to such transactions.
4. Implement a data compliance program. Draft or update a written information security plan, including supporting policies and procedures for understanding data flows and downstream recipients of data, as well as vendor management.  Designate a senior employee responsible for such program. 
5. Implement CISA’s security requirements. Identify stakeholders, conduct a risk assessment and work with technical personnel to implement organizational-, system- and data-level security measures and policies.
6. Prepare to comply with recordkeeping requirements, including records on restricted transactions and their details, results of compliance audits and annual certification.
7. Prepare to comply with audit requirements, including identifying an independent auditor and determining a methodology to conduct an audit by reference to the company’s data compliance and security requirements.

Authors

Michael Egan

Christian Lee

Emma Plankey

The post The DOJ’s Data Security Program – Understanding and Complying with the New Bulk Data Transfer Rule appeared first on cyber/data/privacy insights.

The DUA Act is wide-ranging – covering everything from smart data sharing initiatives to digital identity services – but deliberately avoids many of the more controversial proposals found in its predecessor (the Data Protection and Digital Information Bill), such as redefining ‘personal data’ or changing the requirement to maintain records of processing activities.

This post explores the most impactful privacy-related reforms for companies handling UK personal data.

Key changes

1. Automated decision-making (ADM)

Under the UK GDPR, individuals had a right not to be subject to decisions based solely on automated processing that produced legal/similarly significant effects. This meant ADM was generally prohibited unless a specific exception applied (such as consent, contractual necessity or legal obligation) – and even then, safeguards had to be implemented.

For ADM involving nonsensitive personal data, the DUA Act removes the default prohibition where the processing meets certain conditions and specified safeguards are in place. This allows such processing to proceed without the need for a specific exception – including, potentially, on the basis of legitimate interests.

However, the existing safeguards still apply, including the rights of individuals to obtain human review, express their view and contest the decision. In addition, the DUA Act introduces a new requirement to provide affected individuals with information about automated decisions, building on a similar obligation under Article 13 UK GDPR to inform individuals about the existence of ADM.

2. Scientific research provisions

The definition of scientific research has been clarified so that it explicitly includes:

• Any research that can reasonably be described as scientific, including for the purposes of technological development.
• Commercial and privately funded projects.

The DUA Act also introduces more flexible rules on further processing for scientific purposes, allowing companies to rely on an individual’s initial consent for future, unspecified research uses provided certain conditions apply. This is likely to benefit research activities where precise future uses may not be known at the outset, such as longitudinal studies or AI model training.

3. Recognised legitimate interests

The DUA Act introduces a new list of ‘recognised legitimate interests’ which do not require a balancing test to be carried out. However, these mainly relate to activities which are unlikely to be relevant to many commercial businesses, such as safeguarding national security or detecting crime – although the list may later be expanded by the UK government.

The DUA Act also clarifies that processing for direct marketing, intra-group transfers and network security can be based on ordinary legitimate interests, subject to the usual balancing test.

4. The UK’s Privacy and Electronic Communications Regulations (PECR)

Previously capped at 500,000 pounds, fines under the PECR – a complementary regime governing direct marketing, cookies and electronic communications – will now be aligned with the UK GDPR, rising to a maximum of 17.5 million pounds or 4% of global turnover. This is significant, as Information Commissioner’s Office (ICO) enforcement has historically focused heavily on PECR breaches.

Additionally, minor changes have been made to cookie consent rules, clarifying that certain low-risk cookies (e.g., those used to detect fraud or authenticate users’ identities) will not require user consent.

Business implications

1. Data strategy and research

For companies in research-intensive sectors, the broadened definition of scientific research and expanded allowances for further processing should help reduce compliance friction across commercial research and development and AI.

• Commercial research: Clearer recognition that private research qualifies as ‘scientific’. This had previously been assumed in practice, but the specific recognition provides greater certainty.
• Further processing: Individuals can give consent even if the purpose of data use evolves over time, thereby supporting multiphase research studies.

2. Compliance updates

Several operational policies and notices may need updating in light of the DUA Act:

• Marketing: Businesses should review their marketing practices to ensure compliance with requirements under PECR. The significantly increased fine cap, coupled with the ICO’s historical enforcement in this area, substantially increases the stakes for PECR violations.
• ADM: Businesses using ADM tools should ensure that appropriate safeguards are in place and review their privacy notices to ensure that transparency requirements are covered.
• Cookies: Businesses should reassess cookie classifications and consider removing consent prompts for cookies that fall under the exemption.
• Governance documents: Where businesses define ‘UK GDPR’ or reference applicable laws in contracts, data protection agreements or policies, these may need slight adjustments to incorporate the DUA Act.

3. Cross-border data transfers

The UK’s European Union adequacy status under EU GDPR has been extended until 27 December 2025 but remains under scrutiny. While signals from Brussels are positive, businesses that rely heavily on EU-UK personal data flows should review their transfer mechanisms and ensure contingency measures (such as standard contractual clauses) are in place in case of any future adequacy lapse.

Please reach out to the Cooley team for more information and assistance in respect of the implementation of the DUA Act.

Authors

Guadalupe Sampedro, Partner, London

Morgan McCormack, Associate, London

Daniel Millard, Associate, London

Emerald Hockley, Trainee, London

The post The Data (Use and Access) Act: What Businesses Need to Know appeared first on cyber/data/privacy insights.

Phased rollout: Understanding the timeline

The EU AI Act is being implemented in several key stages:

• February 2, 2025: The first obligations took effect, focusing on AI literacy and prohibiting certain high-risk AI practices.
• May 2, 2025: The (delayed) publication of the Code of Practice for GPAI models was expected, though pushback from major industry players and international stakeholders has postponed its finalization.
• August 2, 2025: GPAI governance rules and obligations that apply to GPAI models on the market after this date come into force.
• August 2, 2026: The majority of the EU AI Act’s requirements become fully enforceable.
• 2030: Final implementation steps, especially for the public sector.

This phased approach allows organizations time to adapt but also creates a complex compliance environment.

The EU AI Act in a nutshell

• World’s first comprehensive AI regulation: The EU AI Act sets a global precedent, though its ultimate impact – akin to the “Brussels Effect” of the EU General Data Protection Regulation (GDPR) – remains to be seen.
• Dense legislation: 450+ pages, 68 new definitions, nearly 200 recitals and multiple annexes, with additional guidance and soft law expected.
• Risk-based approach: Obligations scale with the risk level of the AI system, from prohibited practices to high-risk and low-risk categories.
• Wide applicability: The EU AI Act applies to developers (providers), deployers (users), affected individuals, importers and distributors, regardless of whether they are based in the EU or abroad, due to its extraterritorial reach.
• Severe sanctions: Fines can reach up to 7% of global turnover or 35 million euros, surpassing even GDPR penalties.
• Dual enforcement: Both national supervisory authorities and the new EU AI Office will have enforcement powers, especially for GPAI models.

Early compliance: What’s happened since February 2025?

The first two obligations – AI literacy and prohibition of certain practices – have triggered a flurry of activity.

• AI literacy: Companies have launched training programs to ensure staff understand AI risks and regulatory requirements. The European Commission’s best practices repository, fueled by the AI Pact, offers practical examples, though following these does not guarantee compliance.
• Prohibited practices: Organizations have begun mapping and assessing their AI systems to ensure they are not engaging in prohibited activities. The European Commission has issued detailed (though nonbinding) guidance to clarify what constitutes a prohibited practice.

Defining ‘AI system’: Persistent challenges

A recurring challenge is determining whether a solution qualifies as an “AI system” under the EU AI Act. The European Commission’s recent guidelines emphasize a holistic, case-by-case assessment based on seven criteria, acknowledging that not every system marketed as “AI” actually falls within its scope. This has led to concerns about “AI washing”: the overlabeling of products as AI-enabled for marketing purposes.

GPAI models and the Code of Practice

A major focus now is the regulation of GPAI models, such as large language models. The EU AI Act distinguishes between:

• GPAI models: Core AI technologies (e.g., GPT-4, Mistral) capable of a broad range of tasks.
• AI systems: Applications built on top of GPAI models, with user interfaces and specific use cases (e.g., ChatGPT, Le Chat).

Obligations differ for GPAI model providers versus AI system providers. The Code of Practice, currently still under negotiation, is designed to bridge the gap between legal requirements and practical implementation for GPAI model providers. While voluntary, signing up to the Code may help demonstrate compliance and could influence enforcement decisions.

However, industry resistance, particularly from major US tech firms, and pressure from the US administration have delayed its adoption. The final content and legal effect of the Code remain uncertain, but it is expected to focus on:

• Transparency: Such as documentation and disclosure requirements, both to regulators and downstream AI system providers.
• Copyright: Such as ensuring web-crawled data does not infringe on intellectual property rights.
• Systemic risk: Such as additional safeguards for GPAI models with the potential for significant societal impact.

Transparency obligations: A shared responsibility

Transparency is a cornerstone of the EU AI Act. GPAI model providers must maintain up-to-date documentation and share it with both the EU AI Office and downstream system providers. In turn, system providers must inform users about the AI’s capabilities and limitations, echoing GDPR-style privacy notices.

Enforcement: When do the teeth come out?

While compliance is already required for certain obligations, enforcement mechanisms, including fines and penalties, will only become active from August 2025 (August 2026 for GPAI models). National authorities are still being designated but affected individuals and entities can already seek injunctions in national courts.

Key takeaways

• The EU AI Act is complex, far-reaching and still evolving.
• Early obligations focus on AI literacy and prohibiting harmful practices.
• Defining what counts as an “AI system” remains challenging and requires multidisciplinary input.
• The upcoming Code of Practice for GPAI models is a critical but currently delayed piece of the puzzle.
• Transparency obligations affect both GPAI model and AI system providers.
• Enforcement will ramp up significantly from mid-2025.

Stay tuned for further developments, especially as the Code of Practice on GDPAI models is finalized and the AI Act’s next milestones approach. For organizations operating in or with customers in the EU, proactive engagement and cross-functional compliance efforts are essential to navigate this new regulatory era.

Listen to a recording of the webinar, “AI Talks: Understanding the EU AI Act – What It Means for Companies Worldwide.”

Disclaimer: This blog post was generated with the assistance of AI based on the transcript of the webinar, and finally reviewed by a lawyer.

Authors

Patrick Van Eecke, Partner, Brussels

Bartholomäus Regenhardt, Associate, Brussels

The post The EU AI Act: Key Milestones, Compliance Challenges and the Road Ahead appeared first on cyber/data/privacy insights.

Broad scope and definitions

The amendment defines “reproductive or sexual health information” very broadly, encompassing any “information relating to the past, present, or future reproductive or sexual health of an individual.” This definition expressly includes, but is not limited to, information relating to the following, among other listed examples:

• “Efforts to research or obtain reproductive or sexual health information services or supplies, including location information that may indicate an attempt to acquire such services or supplies”
• “Reproductive or sexual health conditions, status, diseases, or diagnoses, including pregnancy, menstruation, ovulation, ability to conceive a pregnancy, whether an individual is sexually active, and whether an individual is engaging in unprotected sex”
• “Use or purchase of contraceptives, birth control, or other medication related to reproductive health, including abortifacients”

The breadth of “reproductive or sexual health information” means that it could encompass activities of many businesses that may not think of themselves as collecting such information. For example, it could include retailers’ collection of transaction records for consumers’ purchase of products, such as condoms or tampons. Similarly, the collection of precise geolocation by mobile applications (even ones whose purpose is unrelated to health) could fall under the definition if such location data “may indicate an attempt to acquire [reproductive or sexual health] services or supplies,” for instance by visiting a clinic or pharmacy.

Further expanding its potential scope, the amendment applies to any entity that is subject to the Virginia Consumer Protection Act. As a result, businesses may be subject to this new requirement even if they do not meet the (relatively high) data processing volume thresholds for applicability of Virginia’s general consumer privacy law, the Virginia Consumer Data Protection Act (VCDPA).

Affirmative consent

The amendment’s consent requirement utilizes the definition of “consent” from the VCDPA, meaning “a clear affirmative act signifying a consumer’s freely given, specific, informed, and unambiguous agreement to process personal data relating to the consumer.” This consent requirement means that businesses collecting these categories of data will likely have to implement new, appropriately designed consent flows, rather than relying on implied consent or disclosures buried in a privacy policy or terms of service. However, unlike other consumer health data privacy laws, such as those of Washington state and Nevada, the new Virginia requirement does not expressly mandate that businesses provide a dedicated health data privacy notice that is separate from the business’s regular privacy policy.

Private right of action

In addition to enforcement by the Virginia attorney general, the new requirement is subject to a private right of action. It remains to be seen how attractive the new requirement will be as a basis for demand letters and lawsuits by plaintiffs’ firms. However, the existence of a private right of action undoubtedly increases businesses’ potential risks. This, together with the short timeline until the new requirement comes into force on July 1, 2025, makes it especially important for businesses to start assessing their potential exposure and compliance strategy.

Authors

Michael Egan

Christopher Suhler

The post Virginia Enacts New Broad Consent Requirement for Collection of Reproductive and Sexual Health Information appeared first on cyber/data/privacy insights.

Duke v. Moores & Ors [2024] EWHC 2746 (KB)

Key issues: The claimant, a teacher, alleged misuse of private information and breaches of data protection laws after a disciplinary investigation. This was in relation to four categories of information: Facebook messages, WhatsApp messages, references from past employers, and alleged unlawful monitoring and surveillance. The court was asked to decide on an application for summary judgment made by the defendants in respect of a claim for misuse of private information and UK General Data Protection Regulation (GDPR) infringements.  

Key decision: The court granted the application for summary judgment, on the basis that the claimant’s case had no real prospect of success. The court found that any reasonable expectation of privacy was significantly outweighed by the need for investigation in the disciplinary process.

Key takeaways: The case serves as a reminder of the courts’ willingness to strike out privacy and data cases which they feel do not have a prospect of success. Viable claims need to pass a ‘threshold of seriousness’ test, which was introduced into GDPR cases by the UK Supreme Court in a seminal privacy case in 2021, and since then has been used as an important filter in damages claims in respect of alleged GDPR breaches. One question relating to the threshold which remains open – to be determined this year by the Court of Appeal in the case of Farley v. Paymaster – is whether or not fear of adverse consequences, without the occurrence of actual adverse consequences, can constitute harm serious enough to warrant the payment of compensation.

Pacini v. Dow Jones & Co Inc [2024] EWHC 2714 (KB)

Key issues: The claimants, two former investigation bankers, brought a data protection claim against Dow Jones, the publisher of The Wall Street Journal. Their claim was that Dow Jones had published two articles, which they alleged contained inaccurate and misleading information which caused them reputational damage. The decision concerned preliminary determinations regarding whether personal information being processed by the defendant was incorrect, as alleged by the claimant. There were two central issues: the meaning of any personal data within the articles and whether any such data is criminal offence data within the meaning of Article 10 of UK GDPR.

Key decision: In determining the first issue regarding the definition of personal data, the court implemented principles from defamation law. The court first applied the ‘single meaning rule’, considering each published article as a whole and interpreting each element in its full context. The court then used this to determine whether the meaning constituted ‘personal data’ under the GDPR. The court also then applied the repetition rule, which treats a party who repeats a defamatory statement as if they made the original statement, to assist with determining whether the publishers were responsible for a breach of the GDPR. With regards to the second issue, the court held that the personal data was not ‘criminal offence’ data within the meaning of Article 10 UK GDPR.

Key takeaways: This is not the first time that a judge deciding a GDPR case which crosses over with media publication has borrowed concepts from defamation law. The judge in this case went to great lengths to make clear that the approach required to interpret meaning might differ significantly in defamation law and data protection law, although it is interesting that a common approach to this was taken here.

RTM v. Bonne Terre Ltd & Hestview Ltd [2025] EWHC 111 (KB)

Key issues: RTM, an online gambler, sued Bonne Terre, a gambling operator, for sending direct marketing materials to him encouraging him to gamble more. RTM claimed he had not consented to the processing of his personal data for this purpose, and that the unlawful processing for marketing purposes had caused him to suffer harm (namely, financial losses and distress).

Key decision: The court concluded that the defendant had not obtained valid consent from the claimant.  Despite no argument having been presented by the claimant on this specific point, it held that the claimant’s consent to the processing of his personal data for marketing purposes could not be valid, because it was clear from the evidence that he had a gambling problem. This meant that the claimant’s ability to give valid consent was impaired. The defendant argued that it used the personal data it collected from its customers to assess gambling addiction, in compliance with its safer gambling obligations, and that it had not concluded that RTM was a problem gambler and so had not excluded him from marketing lists. The court dismissed the relevance of this.

Key takeaways: This case is a good reminder of the need for ‘informed’ and ‘freely given’ consent to data processing, although arguably it sets the bar extremely high for data controllers to meet. The net effect of this decision appears to be that, if a data controller seeks consent from customers to process their data, including for marketing purposes, and vulnerable individuals are within the customer group, then there is a risk that their consent will be invalidated by their vulnerability. This in turn would result in unlawful data processing. That risk apparently lies entirely with the data controller, even if they are completely unaware of the vulnerability in question. This has potentially wide ramifications for the entire online marketing ecosystem.

Ashley v. HMRC [2025] EWHC 134 (KB)

Key issues: The claimant, businessman Mike Ashley, was involved in a tax dispute with HM Revenue & Customs (HMRC) and issued a data subject access request (DSAR) to find out which of his personal data they processed. This case explored the meaning of personal data under Article 4(1) of GDPR, the extent to which a controller needs to conduct a search for it to be considered proportionate, and the rules on what context needs to be given around the personal data of a data subject.  

Key decision: The court found in favour of the claimant regarding HMRC’s data processing failings, but rejected the wider argument that personal data included all data relating to HMRC’s tax enquiry assessment. The lengthy judgment provided a number of insights as to the meaning of personal data in the context of a DSAR:

• The court held that information that is ‘linked’ to an individual should be construed in a broad way, although there should be a ‘continuum of relevance’ (accordingly, a link which is indirect or tenuous ‘at several removes’ is unlikely to make the grade). It also confirmed that data can concern an object rather than an individual, and that subjective opinions, reasoning and assessments concerning an individual can be personal data where interlinked with or connected to information that more specifically relates to the individual. 
• For a ‘reasonable and proportionate’ search, the court made clear that it is up to a data controller to demonstrate a search would not be proportionate, and that, where a controller processes large amounts of data, it is their obligation under GDPR to design systems which can cope with DSARs in such circumstances.
• On the provision of data itself, the court emphasised the need to do so in a transparent and intelligible manner, noting that decontextualised snippets (e.g. in a schedule of extracts, which is becoming standard practice) are unlikely to be adequate. It concluded that a data controller does not have to provide whole documents, but does have to provide enough additional information to enable the data subject to understand the context of the processing. However, it underlined what should be provided should be no more than what is necessary to achieve this.

Key takeaways: Businesses need to be mindful of the approaches they are taking in answering DSAR requests and should ensure their teams are trained on the most up-to-date guidance as to what constitutes personal data.

For a deeper dive into these cases, please check out our recent Privacy Litigation webinar and, as always, reach out if you have any questions about how these developments might affect your business.

Authors

Bryony Hurst, Partner, London

Enrique Capdevila, Special Counsel, London

The post UK Data Privacy Litigation: What’s New? appeared first on cyber/data/privacy insights.

Initial considerations for life sciences companies

To determine whether data transactions trigger the “bulk” thresholds, the rule aggregates transactions over the preceding 12 months to determine the number of US persons’ data implicated. In other words, it is a rolling assessment of whether a particular transaction crosses the relevant bulk thresholds. Different categories of sensitive personal data are associated with different bulk thresholds. Unlike with privacy-focused laws, the thresholds apply regardless of whether the data is anonymized, key-coded, pseudonymized, de-identified or encrypted, which presents significant challenges for life sciences companies. Of particular relevance for life sciences companies are the following:

Potentially relevant bulk thresholds

Countries of concern or covered persons

The rule prohibits or restricts bulk sensitive personal data transactions with countries of concern or covered persons. The rule, while providing for future executive branch flexibility, defines countries of concern to include:

• The People’s Republic of China (including Hong Kong and Macau)
• The Republic of Cuba
• The Islamic Republic of Iran
• The Democratic People’s Republic of North Korea
• The Russian Federation
• The Bolivarian Republic of Venezuela

The rule creates four general categories of covered persons:

• Foreign entities that are 50% or more owned (directly or indirectly) by a country of concern, organized under the laws of a country of concern or have their principal place of business in a country of concern (including, potentially, a foreign subsidiary of a US company).
• Foreign entities that are 50% or more owned (directly or indirectly) by a covered person.
• Foreign employees or contractors of countries of concern, or of entities that are covered persons.
• Foreign individuals primarily resident in countries of concern.

The rule’s impacts

Given the rule’s breadth, its departure from existing US data privacy-focused laws, and significant civil and criminal fines and penalties, life sciences companies potentially within the rule’s scope should consider how to minimize risks associated with “prohibited” and “restricted” transactions.

Prohibited transactions

In relation to bulk US sensitive personal data, the rule generally prohibits a few types of transactions that may result in foreign access to bulk US sensitive personal data.

• Data brokerage transactions: The rule prohibits “data brokerage” transactions, which include not only transactions that would typically be thought of as “data brokerage,” i.e., the sale, in exchange for money, of data that was not collected directly from the individual to whom the data relates, but also any other transactions (excluding an employment agreement, investment agreement or a vendor agreement) involving the sale, licensing or similar commercial transactions of bulk sensitive personal data with countries of concern or covered persons.
  • To avoid circumvention of this requirement, the rule provides that data brokerage transactions with any other foreign person (i.e., not a covered person) must include a contractual provision requiring the foreign person to refrain from subsequent data brokerage transactions with countries of concern or covered persons.
• Human ‘omic data and human biospecimen transactions: The rule prohibits covered data transactions with a country of concern or covered person that involve access by that country of concern or covered person to bulk US sensitive personal data where such sensitive personal data involves human ‘omic or human biospecimens from which bulk human ‘omic data could be derived. This second prohibition, absent the potentially relevant exemptions, could likely significantly impact life sciences companies given the low thresholds for human genomic data or human biospecimens to qualify as “bulk” and the broad definition of “access” under the rule. This prohibition has particular relevance for life sciences companies looking for investments from, or to use vendors or employees in, countries of concern or those who may qualify as covered persons.

Restricted transactions

The rule imposes restrictions on (but does not prohibit) covered data transactions involving certain vendor agreements, employment agreements or investment agreements with a country of concern or covered person, unless they involve bulk human ‘omic data or human biospecimens from which such data could be derived.

The rule permits restricted transactions only if the US person complies with Cybersecurity and Infrastructure Security Agency (CISA) security requirements (effective October 6, 2025) and otherwise maintains a data compliance program that, in relevant part, establishes:

• Risk-based procedures for data flows.
• Risk-based procedures for vendor identity verification.
• An annual certification process of its data compliance program.
• An annual certification process of its data security program.

Potential exemptions for life sciences data transactions

In its background on the rule, the DOJ said it intends to address concerns about the rule’s effects on drug development and biomedical innovation. To that end, the rule exempts certain data transactions from its prohibitions and restrictions, including several exemptions potentially relevant to life sciences companies. These exemptions include:

• Clinical and surveillance exemption. Data transactions incident to and part of clinical investigations regulated by the FDA, or clinical investigations that support applications to the FDA for research and marketing permits (this includes post-marketing surveillance data, including pharmacovigilance and post-marketing studies for already approved therapies), provided that the clinical data is de-identified or pseudonymized in accordance with applicable FDA regulations.
• Regulatory approval exemption. Data transactions that involve “regulatory approval data,” which are necessary to obtain or maintain regulatory approval to research or market a pharmaceutical product or medical device, provided that such data is de-identified or pseudonymized in accordance with applicable FDA regulations and is required to be submitted to a regulatory entity.
• Federally funded research exemption. Data transactions conducted pursuant to a US grant, contract or other agreement.

The breadth of these exemptions remains to be determined as adjudicatory bodies have yet to publicly interpret the rule’s provisions.

Implications for life sciences transactions

The rule could apply to a variety of transactions involving life sciences companies. Below are just a few examples of scenarios in which life sciences companies (and their data transactions) could be within the rule’s scope, and may or may not fall within the rule’s exceptions:

• License or collaboration agreements between US entities and covered persons during which one of the parties conducts clinical trials in the United States and wants to transfer clinical data and/or biospecimens to a country of concern or covered person.
• M&A deals involving covered persons where one or more of the parties conducted clinical trials in the US.
• Vendor agreements (such as those with contract research organizations, contract manufacturing organizations or data-hosting providers) and employment agreements in which US sensitive personal data is shared with a country of concern or covered person.
• Intra-company sensitive personal data transactions.
• Investment agreements with investors who are in a country of concern or are otherwise covered persons.

What should life sciences companies do next?

Given the rule will soon take effect, life sciences companies should evaluate their exposure to the rule, take advantage of potential rule exemptions and, as appropriate, implement compliance strategies to address their obligations under the rule.

• Determine whether you process bulk US sensitive data. Evaluate whether the relevant data that you process (collect, transfer or receive) falls within the rule’s scope.
• Identify potential covered data transactions. Undertake a review of any data brokerage, vendor, employment and investment agreements to determine whether the rule may apply to such transactions.
• Know your company’s data flows and conduct recipient diligence. Know to whom and for what purposes you will transfer data/biospecimens and whether the recipient will engage in any further transfers. Conduct “know-your-recipient” diligence to assess whether they fall within the scope of the rule’s definitions of countries of concern or covered persons.
• Implement compliance strategies. Update policies to identify potentially covered data transactions as part of the diligence process and implement and maintain:
  • Appropriate contractual protections on data transactions (aligned with good general data hygiene practices).
  • Internal policies, procedures and measures designed to limit access to data (particularly if personnel are in countries of concern or are otherwise covered persons).
  • Appropriate security measures for the sensitive personal data.

Michael Egan, Partner, Washington, DC

Daniel Grooms, Partner, Washington, DC

Alan Tamarelli, Partner, New York

Andrew Epstein, Special Counsel, Seattle

Carlton Forbes, Special Counsel

Navya Dasari, Associate, New York

Richard Koch, Associate, Washington, DC

The post The DOJ’s Bulk Sensitive Personal Data Rule’s Imminent Relevance to Life Sciences Companies appeared first on cyber/data/privacy insights.

Background

The first version of the MCC-AI was published in September 2023 in anticipation of the EU AI Act, offering a structured approach to AI procurement. With the EU AI Act officially enacted on 13 June 2024, the EC has now refined these model clauses to ensure greater alignment with regulatory requirements. The new publication includes:

• A full version for high-risk AI systems.
• A light version for non-high-risk AI systems.
• A commentary explaining how to adapt and implement the clauses.

Why should companies get acquainted with the MCC-AI?

The MCC-AI provides a valuable framework for companies procuring or providing AI services by establishing a common, minimum standard of obligations. These clauses help ensure that both parties align on key compliance aspects – such as transparency, risk management and accountability – in line with the EU AI Act.

Organisations incorporating MCC-AI clauses tailored to their needs, contracts and businesses can streamline negotiations, reduce legal uncertainties and demonstrate regulatory readiness.

This is particularly beneficial in an evolving legal landscape where AI governance requirements are still developing, as it helps companies proactively address potential risks and responsibilities.

Who has issued the MCC-AI?

The MCC-AI have been issued by the Public Buyers Community Platform, designed to foster collaboration in public procurement across the EU. It serves as a dedicated space where European public procurers and the EC can connect, share insights and drive innovation in public purchasing. The clauses are to be considered as a working document in progress and do not reflect an official position of the EC.

Who should use the MCC-AI?

The MCC-AI are designed for public-sector organisations procuring AI solutions, but they can be selectively adapted by private entities on a clause-by-clause basis.

• The full version applies to high-risk AI systems as defined in Chapter III of the EU AI Act – AI systems that pose significant risks to health, safety or fundamental rights.
• The light version is tailored for non-high-risk AI systems, but still addresses key procurement considerations, such as transparency, risk management and data governance.

Even in cases where the AI system poses no clear risks, the MCC-AI commentary suggests that contracting authorities include contractual safeguards around:

• Risk management frameworks
• Data governance and usage rights
• Technical documentation and audit mechanisms
• AI registers for accountability

How should the MCC-AI be executed?

The clauses are designed to be annexed to procurement contracts rather than functioning as stand-alone agreements. The MCC-AI includes only provisions specific to AI systems and issues covered by the EU AI Act. It does not address obligations or requirements arising from other applicable legislation. For instance, it does not cover intellectual property, acceptance, payment, delivery deadlines, applicable law or liability.

What do the MCC-AI cover?

The MCC-AI are structured around key legal and operational obligations, including:

• AI system requirements: Ensuring compliance with fundamental legal and ethical standards.
• Supplier obligations: Defining transparency, risk management and compliance expectations.
• Data governance: Establishing rights over data sets used in AI development.
• Audit and accountability: Setting up mechanisms for AI system monitoring.
• Costs and liabilities: Clarifying financial responsibilities for implementation and compliance.

Additionally, the annexes provide templates for describing AI system use cases, defining data governance frameworks and documenting compliance measures.

What are the differences between the European Commission standard contractual clauses and the MCC-AI?

The EU standard contractual clauses (SCCs) are legally binding contract templates issued by the EC to ensure that personal data transferred outside the European Economic Area (EEA) complies with the General Data Protection Regulation (GDPR). They impose specific data protection obligations on the parties involved.

The table below outlines the key differences between model contractual clauses (MCCs) and SCCs for data transfers. Although they serve different purposes, they may be included in the same agreement:

Key takeaways

For organisations providing AI systems, tailoring the MCC-AI to their business enhances credibility and trust with customers by showing a commitment to responsible AI practices.

For buyers, these clauses offer a baseline level of protection, ensuring that the procured AI solutions meet essential ethical and legal standards. Additionally, since the MCC-AI can be annexed to existing agreements, they provide flexibility while maintaining consistency across contracts. This not only facilitates smoother transactions but also minimizes disputes, as both parties operate under a shared understanding of AI-related obligations from the outset.

For further insights on AI contracting and compliance, please reach out to your Cooley team.

Authors

Patrick Van Eecke, Partner, Brussels

Enrique Capdevila, Special Counsel, Brussels

The post Model Contractual Clauses for AI Procurement in the EU: Key Takeaways for AI Companies appeared first on cyber/data/privacy insights.

The UK Information Commissioner’s Office (ICO) has released updated guidance on ‘consent or pay’ business models. These models present users with a choice to either consent to the processing of their personal data for purposes like personalised advertising in return for access to a product or service, or pay a fee to access the product or service without personalised ads.

For many online services, the consent or pay business model provides an important way of monetizing their product or service, generating essential revenue streams. However, there has been uncertainty about whether companies could obtain valid consent from users through these models under UK data protection laws – and, consequently, whether they could establish a legal basis for the processing of personal data for personalised ads.

The ICO’s guidance therefore aims to help companies navigate the complex intersection between UK data protection laws and online monetization. It shows that companies may be able to operate a consent or pay business model in compliance with applicable UK data protection laws; however, some types of companies (such as large social media platforms) may struggle to satisfy the necessary criteria without offering a third option, such as contextual advertisements.

What does the guidance say?

In order to operate a consent or pay business model, companies must assess whether they can demonstrate that their users’ consent is ‘freely given’. The standard for freely given consent is set out in the UK General Data Protection Regulation (GDPR). In the context of consent or pay business models, freely given consent means that users must have a genuine, voluntary choice to consent (or refuse to consent) to personalised ads. If users feel compelled to provide their consent, it will be invalid.

This means that before companies implement a consent or pay model, they must conduct a data protection impact assessment (DPIA) to:

• Assess the validity of consent.
• Identify any risks.
• Take necessary steps to mitigate risk or bring the model into compliance.

The guidance sets out various issues to consider in the DPIA, such as:

What should companies do?

To avoid enquiries from the ICO or complaints from UK individuals about their consent or pay business models, companies subject to UK data protection law should:

• Conduct a DPIA to review current practices and compare them against the ICO’s guidance.
• If the DPIA identifies any compliance gaps or risks in relation to the company’s model, take any necessary steps to mitigate or resolve such gaps and risks. This may require offering an alternative option, such as contextual advertising.
• Keep the consent or pay model under regular review as the company’s product or service develops over time.

Authors

Ann Bevitt, Partner, London

Morgan McCormack, Associate, London

The post ICO Releases ‘Consent or Pay’ Guidance appeared first on cyber/data/privacy insights.