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.

The EU AI Act is set to reshape the regulatory landscape for AI systems deployed in the EU. As the first comprehensive AI law of its kind, it introduces strict compliance requirements, including AI literacy obligations, prohibited uses of AI systems and a phased rollout of enforcement mechanisms. Here’s what businesses need to know to stay ahead of the curve.

1. The AI Act at a glance

The EU AI Act aims to establish a harmonized framework for AI systems, categorizing them based on risk levels. Notably, the EU AI Act introduces:

• A broad scope covering providers, deployers, manufacturers, importers and distributors of AI systems, even if they are based outside of the EU but operate within its market. Check our blog post, ‘EU AI Act: Does It Affect Your Organization or Not?’ to learn more about your role and responsibilities under the EU AI Act.
• A definition for AI systems.
• A phased enforcement schedule starting with certain obligations coming into effect immediately.
• Severe penalties for noncompliance, potentially exceeding those imposed under the General Data Protection Regulation (GDPR).

What is an AI system under the EU AI Act?

The EU AI  Act does not apply to all AI systems but specifically targets those that meet the definition of an ‘AI system’ as outlined in Article 3(1) of the AI Act: ‘“AI system” means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments’.

To clarify the scope of this definition, the European Commission (EC) has issued guidelines on the definition of an AI system, which aim to assist providers and other relevant persons – including market and institutional stakeholders – in determining whether a system constitutes an AI system within the meaning of the EU AI Act.

The EC acknowledges in the guidelines that, due to the rapidly evolving nature of AI technology, it is impossible to provide an exhaustive list of systems that either fall within or outside the definition of an AI system. This may pose challenges for companies when assessing whether their systems are within scope of the EU AI Act and understanding their obligations under it.

While the guidelines provide valuable insight, they are nonbinding, and any definitive interpretation of the EU AI Act will be determined by the Court of Justice of the European Union (CJEU).

2. Immediate compliance obligations as of 2 February 2025

a. AI literacy (Article 4)

i. Concept

Article 4 of the EU AI Act requires providers and deployers of AI systems to ensure a sufficient level of AI literacy for their staff and any other users who are interacting with AI systems.

The EU AI Act does not specify how AI literacy should be achieved by providers and deployers. However, to support this requirement, the EU AI Office has created a living repository of ongoing practices among AI system providers and deployers. The purpose of the repository is to share examples of AI literacy initiatives that organizations are implementing. These practices can help others understand how to build their own strategies for meeting the literacy obligations in Article 4.

The repository of AI literacy compiles practices gathered through a survey shared exclusively with AI Pact pledgers, at least for now. As such, the list of practices provided is not exhaustive and will be updated regularly.

The EU AI Office recalls that adopting the practices listed in the repository does not automatically guarantee compliance with Article 4 of the AI Act.

ii. What should you do now to prepare for compliance with your literacy obligations?

• Evaluate current practices: Assess the current AI literacy levels within your organization. Are your staff and users equipped with the right knowledge and training?
• Leverage the repository of AI practices: Consult the living repository to find practices that could be relevant to your organization. Even if your AI literacy efforts are still in the planning phase, it is useful to learn from others.
• Assess whether you should engage in the AI Pact.
• Regularly update practices: Stay updated with evolving AI literacy standards, be proactive in improving your organization’s literacy efforts and make sure you document them to demonstrate compliance.

b. Prohibited AI practices

i. Concept

Article 5 of the EU AI Act prohibits the placing on the EU market, putting into service or use of certain AI systems which pose an ‘unacceptable risk’, including AI systems used for the following purposes:

• Harmful AI-based manipulation and deception.
• Harmful AI-based exploitation of vulnerabilities.
• Social scoring.
• Individual criminal offence risk assessment or prediction.
• Untargeted scraping of the internet or CCTV material to create or expand facial recognition databases.
• Emotion recognition in workplaces and education institutions.
• Biometric categorisation to deduce certain protected characteristics.
• Real-time remote biometric identification for law enforcement purposes in publicly accessible spaces.

These prohibitions came into effect six months after the AI Act entered into force, starting from 2 February 2025.

The EC recently adopted the guidelines on the practical implementation of the practices prohibited under Article 5 of the AI Act. These guidelines aim to enhance legal clarity and offer insights into the EC’s interpretation of the prohibitions in Article 5 of the EU AI Act, ensuring their consistent, effective and uniform application. They are intended to serve as practical guidance for competent authorities enforcing the AI Act, as well as for providers and deployers of AI systems to help ensure compliance with their obligations. The guidelines also provide some clarity around exclusions from the scope of the EU AI Act – such as national security, defence and military purpose, judicial and law enforcement cooperation with third countries, research and development, or personal nonprofessional activity.

It is important to note that these guidelines are nonbinding. Any definitive interpretation of the AI Act can only be provided by the CJEU.

c. Is your compliance documentation covered by legal privilege?

The EU AI Act grants regulators broad investigative powers, including access to AI risk assessments and compliance documentation. However, legal privilege can protect certain internal communications from disclosure. Businesses should consider consulting legal counsel to ensure compliance strategies remain privileged where applicable.

3. Next steps for businesses

For businesses with a global presence, the guidance issued by the EC is a crucial resource for managing the complexities of complying with the EU AI Act. Below you will find some recommended practices to enhance your compliance strategy:

• Assess whether your AI systems fall under the EU AI Act’s scope.
• Identify whether your company is a provider, deployer or both under the EU AI Act.
• Review and mitigate risks associated with AI deployments.
• Ensure compliance with AI literacy obligations through staff training.
• Consult legal counsel to ensure your AI compliance strategies remain privileged.
• Monitor regulatory updates, including forthcoming EU guidelines.

With the EU AI Act’s phased implementation, now is the time for businesses to align their AI strategies with regulatory expectations. Compliance today will help organizations mitigate risks and avoid significant penalties in the future.

For further legal insights on AI compliance, please do not hesitate to contact us.

Authors

Patrick Van Eecke, Partner, Brussels

Enrique Gallego Capdevila, Special Counsel, Brussels

The post AI Talks: Understanding the EU AI Act – AI Literacy Obligations and Prohibited Practices appeared first on cyber/data/privacy insights.

In an attempt to address ongoing regulatory uncertainty about how the UK General Data Protection Regulation (UK GDPR) and UK Data Protection Act 2018 apply to the development and use of generative artificial intelligence (AI), the UK Information Commissioner’s Office (ICO) has released its initial response to its five-part consultation series on the topic which it conducted in 2024. The series covered the following areas:

1. The legal basis for web-scraping to train generative AI models.
   
2. Purpose limitation – i.e., having a specified, explicit and legitimate purpose – throughout the generative AI life cycle.
   
3. Accuracy of training data and model outputs.
   
4. Respecting individual rights in the training and fine-tuning of generative AI models.
   
5. Allocating controllership across the generative AI supply chain.

What has changed?

In its initial response, the ICO updated its seemingly highly permissive position on ‘legitimate interests’ as a legal basis for web-scraping under the UK GDPR. In previous draft guidance, the ICO’s position was that data controllers could rely on legitimate interests as a legal basis for training AI models on web-scraped data, provided that they could pass the ‘three-part’ test by demonstrating:

1. The purpose of the processing is legitimate.
   
2. The processing is necessary for the purpose (the ‘necessity test’).
   
3. The individual’s interests do not override the developer’s interests being pursued (the ‘balancing test’).

Following consultation on the initial draft guidance, the ICO has refined its position somewhat – and highlighted some specific considerations which organisations need to bear in mind if they want to rely on legitimate interests for training on web-scraped data.

Increase transparency

• The ICO says that web-scraping often occurs without people being aware of it (so-called invisible processing).
  
• The ICO feels that this type of ‘invisible processing’ creates challenges for the purposes of the balancing test – primarily because where people are unaware that their data is being processed, they are unable to exercise their rights under the UK GDPR.
  
• According to the ICO’s updated position, it now expects generative AI developers to significantly improve their approach to transparency.

Making sure scraping is necessary

• The ICO questioned whether AI developers really need to use web-scraping to collect training data – i.e., whether they can satisfy the necessity test – when alternative methods of data collection exist.
  
• For example, the ICO seems to believe that developers could effectively train models by licensing personal data from organisations that specialise in collecting such data in a transparent way and in accordance with the UK GDPR.
  
• It is not clear on what basis the ICO reached the conclusion that the relatively limited personal data available via the nascent training data licensing market would be sufficient for the purposes of training latest-generation models. It remains to be seen whether AI model developers would share this view …

Recommendations

Given this emerging line of thinking from the ICO, AI model developers relying on legitimate interests as their legal basis for web-scraping under the UK GDPR must assess (and document such assessment):

• Whether they really need to use web-scraping to collect personal data for development of their AI model, or whether an alternative approach (such as licensing personal data) could realistically satisfy their needs.
  
• How they intend to address their transparency obligations under the UK GDPR – taking appropriate steps to increase transparency and controls for data subjects will be a key part of getting this right.

What happens next?

The ICO’s initial response informs its current core guidance on AI and data protection. This guidance is expected to be formally updated when the UK’s new UK GDPR reform legislation – the Data (Use and Access) Bill – is passed into law. This is expected to happen around Easter 2025.

Authors

Leo Spicer-Phelps, Associate, London

Morgan McCormack, Associate, London

The post ICO Updates Position on Web-Scraping for AI Development appeared first on cyber/data/privacy insights.

Private organizations in the EEA have long faced challenges in managing such requests while ensuring compliance with the GDPR. To address these issues, the European Data Protection Board (EDPB) issued Guidelines 02/2024 on 2 December 2024, offering clarity on the interpretation and application of Article 48. These guidelines, open for public consultation until 27 January 2025, are essential for businesses, legal professionals and privacy experts navigating cross-border data transfers under the GDPR.

Background on Article 48 of the GDPR

Article 48 of the GDPR states that ‘any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognized or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty, in force between the requesting third country and the Union or a Member State, without prejudice to other grounds for transfer pursuant to this Chapter’.

This provision specifically restricts the transfer of personal data to third countries that may not comply with GDPR standards, even if the transfer arises from a court decision or administrative order that requires a controller or processor established in the EEA to disclose personal data, unless certain conditions are met.

Private organizations established in the EEA face a dilemma between complying with third-country requests – often related to national security or law enforcement orders – and adhering to the requirements of the GDPR.

Scope of the Guidelines 02/2024

These guidelines focus on requests for direct cooperation between a third-country public authority and a private entity in the EEA, rather than scenarios where personal data is exchanged directly between public authorities in the EEA and third countries (for example, under mutual legal assistance treaties). These requests may come from a wide range of public authorities, including those regulating the private sector, such as banking regulators and tax authorities, as well as law enforcement and national security agencies.

The guidelines specifically address situations where such requests are directed to controllers or processors in the EEA, whose processing activities are subject to Article 3(1) of the GDPR.

‘Two-step test’ must be fulfilled when responding to a third-country public authority request

The EDPB recalls in these guidelines that the ‘two-step test’ must be applied when transferring personal data to third-country public authorities. First, the transfer of personal data to a third country shall take place only if there is a legal basis together with all relevant provisions of the GDPR. Second, the conditions of Chapter V (‘Transfers of personal data to third countries or international organizations’) must be complied with.

1. Identification of a legal basis under Article 6 of the GDPR

• Compliance with a legal obligation (Article 6(1)(c)): Article 48 contemplates a situation where a court ruling, tribunal decision or administrative order from a third-country authority requires a controller or processor in the EEA to transfer personal data based on an international agreement, which could establish the request as a legal obligation with potential legal consequences for noncompliance. If the processing of personal data is necessary to fulfill a legal obligation, Article 6(1)(c) of the GDPR provides a clear legal basis for the transfer.

In a scenario where there is no legal obligation arising from an international agreement for the EEA organization, the use of other legal bases must be assessed on a case-by-case basis.

• Consent (Article 6(1)(a)): In principle, a data subject’s consent could serve as a legal basis for transferring data to a third-country authority. However, the EDPB considers that relying on consent in this context would be generally inappropriate, as the data transfer is linked to the exercise of authoritative powers. Hence, there would be an imbalance between the parties.

• Vital interests (Article 6(1)(d)): The EDPB acknowledges that in certain established situations, the vital interests of the data subject could be used as a legal basis for a data transfer triggered by a third-country request, provided that the conditions outlined in international law are met. Regarding the vital interests of other individuals, the EDPB emphasizes that the processing of personal data based on the vital interests of another person should – in principle – occur only when it cannot clearly be justified by another legal basis.

• Legitimate interests (Article 6(1)(f)): The EDPB reminds that any processing based on the legitimate interests of the controller or third parties must be necessary and balanced against the interests, fundamental rights and freedoms of the data subject. The outcome of this balancing test, which is subject to an individual assessment, determines whether the legitimate interest legal basis can be relied upon for transferring personal data to a third-country authority. The EDPB states that, although a controller may, in some cases, have a legitimate interest in complying with a request to disclose personal data to a third-country authority, a private business acting as a controller cannot rely on Article 6(1)(f) for the collection and storage of personal data in a preventive manner.

Furthermore, these guidelines remind that the EDPB has previously held that in certain situations, the interests or fundamental rights and freedoms of the data subject would override the controller’s interest in adhering to a third-country law enforcement authority’s request to avoid sanctions for noncompliance.

2. Compliance with Chapter V of the GDPR

The provision of Article 48 itself contains no data protection safeguards for data transfers, but clarifies that decisions or judgments from third-country authorities cannot be directly recognized or enforced in the EEA unless an international agreement provides for this.

Therefore, before responding to a request from a third-country public authority falling under Article 48 of the GDPR, the controller or processor in the EEA must identify an applicable ground for the transfer.

If an international agreement governs cooperation between an EEA controller or processor and a third-country public authority, it can serve as a legal basis for a data transfer, provided that the agreement includes appropriate safeguards in accordance with Article 46(2)(a).

If there is no international agreement that would bound the EEA controller or processor and the third-country public authority, or the agreement does not preclude adequate safeguards for the transfer, the transfer must be based on another ground for transfer under Chapter V – e.g., standard contractual clauses or binding corporate rules – or rely on any of the derogations of Article 49, such as when necessary for important public interest reasons or for the establishment, exercise or defense of legal claims. However, as the EDPB has previously stated, the derogations in Article 49 must be narrowly interpreted and are primarily intended for occasional, nonrepetitive processing activities.

Impact on businesses with an entity in the EEA

For businesses operating globally, the guidance set out in Guidelines 02/2024 is an essential tool for navigating the complexities of handling third-country requests. Companies must remain vigilant in assessing the legal environments of the countries to which they transfer data, ensuring that EEA-established controllers and processors rely on an adequate legal basis and on a ground for transfer under Chapter V when responding to requests from third-country authorities in compliance with the GDPR.

If your organization requires skilled advice and support on how to handle third-country public requests, such as subpoenas, please do not hesitate to contact us.

Authors

Patrick Van Eecke, Partner, Brussels

Enrique Gallego Capdevila, Special Counsel, Brussels

The post Guidelines 02/2024 on Article 48 of the GDPR: EDPB Clarifies Rules for Data Sharing With Third-Country Authorities appeared first on cyber/data/privacy insights.