One AI security vendor recently claimed that SOC2 was insufficient for evaluating AI security and controls. Although we might agree with the ultimate conclusion, the vendor made some surprising statements that show an implicit bias for the Band-Aid approach and a poor understanding of how to effectively govern Agentic AI systems. 

Here are a few examples of representations that should raise red flags.

Vendor:

“An AI Agent doesn’t have a fixed set of behaviors.”

Correct Approach:

AI agents in most settings should have established, fixed behaviors. Success and failure modes should be explicitly defined and governed. This should be done with static logic (code) and is one of the most important controls in any Agentic AI system. 

If success and failure are not well defined and monitored, then arguably the system is constructively allowed to misbehave.  And, when it does so, the failure mode will be silent. Trying to detect and stop these system failures after-the-fact with a Band-Aid approach resembles whack-a-mole more than it does governance. Relying on after-the-fact controls is like treating aviation safety as mostly a matter of investigating crashes instead of trying to increase the overall safety and reliability of the system.  After-the-fact detection isn’t meaningless, but it is the wrong layer to lean on.  In agentic AI, as in aviation, the primary safety work should happen before and during system operation.

Vendor:

“The agent may call APIs that are not part of any predefined workflow.”

Correct Approach:

Workflows should be pre-defined, and AI agents should only call APIs for which they are explicitly scoped in advance and subject to pre-defined static logic/control.

If access to API calls is not limited and controlled, then it becomes easier for those APIs to be accessed either inadvertently or maliciously.  Potential exploit chains (which string together multiple agentic components) become deeper and more numerous. To extend the airplane analogy, many commercial airplanes have a control system that sits between pilot action and airplane behavior.  Control systems on modern aircraft actively resist or prevent unsafe pilot maneuvers and will limit pitch, bank, and angle of attack to prevent stalls and exceeding safe speeds. These are exactly like the pre-defined limits on API calls: before the system can do the unsafe thing, a control has already prevented that system behavior.

Vendor:

“An AI agent decides at runtime what tools to use.”

Correct Approach:

Although it is true that Agent behavior is dynamic, the vendor leaves open the possibility that natural language (i.e., a call to an AI endpoint) can be allowed to invoke tools.  For a system to be reliable, however, tool usage should be controlled with static logic. The reason is because responses from AI endpoints are “probabilistic,” meaning one can’t perfectly control the content of the AI response over time. When tool usage turns on probabilistic responses from AI endpoints then, at some point, they are likely be invoked in ways that make the system unreliable and exploitable.  Over time, these small and unexpected responses can chain together and lead to cascading failures.  Similar to ungoverned API use, exploit chains become more dangerous and multiply.  In other words, when preparing for landing, there should be room for the pilot to make judgment calls based on wind speed, runway length, and physical obstacles, but those judgment calls should only be allowed to flip certain switches in the cockpit. 

The Critical Role of Lawyers and Compliance

In the current environment, where Agentic AI risks may not be fully appreciated by existing development and cyber teams, a compliance/procurement/cyber attorney may end up being the first and best line of defense to ensure the organization effectuates real governance and controls over the AI use case. 

With respect to every AI system and AI system component, an organization ideally should begin by posing the following questions:

• What am I trusting the system or component to do and why?
• How do I limit trust (and limit risk)?
• What is the system or component allowed to do?
• What is the system or component not allowed to do?
• What is the data the system is acting upon and what are my rights and limitations with respect to that data?
• How does the system enforce the answers to these questions?
• What is the risk of scope creep and how can I monitor the actual use over time?

The goal is to surface those areas where trust or scope of action is unwarranted or unnecessary.  The governance process is of course a good deal more involved than this, but this is the right conceptual and practical place to start.

In its “Let’s Talk MFA” training on February 26, 2026, NY DFS highlighted additional guidance including updated FAQs addressing Section 500.12. Covered Entities have until April 15, 2026 to certify their compliance with the NY DFS Cybersecurity Regulation in the annual notifications to NY DFS.

Put simply, NY DFS expects Covered Entities to show that MFA is implemented effectively across their systems, that the scope is complete, and that any risk-based exceptions or compensating controls are well documented, with particular attention to SSO, cloud services, and external-facing systems.

What Changed?

The FAQs provide notably granular direction on how NY DFS views common MFA approaches. The FAQs provide guidance on (i) what does and does not qualify as MFA, (ii) push-based authentication, (iii) single sign-on (SSO), (iv) cloud platforms, and (v) when external-facing systems may require MFA.

A Quick Refresher: What NY DFS Means by “MFA”

NY DFS defines MFA as authentication using at least two different factor types:

• Knowledge – something you know, such as a password, passphrase, or PIN.
• Possession – something you have, such as a token, authenticator app, or smartcard.
• Inherence – something you are, such as a biometric characteristic.

NY DFS emphasizes utilizing multiple distinct factor categories. Simply layering more checks that fall into a single bucket does not satisfy NY DFS’s requirements. For example, requiring two passwords is not considered MFA, because both passwords fall under the same “knowledge” factor type. Requiring a password (a “knowledge” factor) plus a token placed on your company-issued device (a “possession” factor) would constitute MFA since those incorporate two different factor types.

NY DFS Expectations

• “Possession” means real proof of possession. NY DFS highlights that a possession factor should provide cryptographic or technical proof that the user controls a specific device/token/authenticator at the moment of authentication.

• Push-based MFA is common, but NY DFS is focused on its weaknesses. NY DFS flags risks associated with push prompts (including “MFA fatigue”) and points to safeguards such as number-matching or challenge-response, displaying contextual login details, limiting push retries, and using adaptive MFA for suspicious activity.

• Single sign-on (SSO) can work, but SSO alone is not the answer. NY DFS states SSO may be used; however, MFA must be enforced as part of the authentication process in order to prevent the SSO layer from becoming a bypass route.

• Cloud email and document platforms are firmly in scope. NY DFS indicates that MFA is required for Covered Entities accessing cloud-based document storage and collaborative platforms.

• External-facing systems: often no MFA, but “material risk” changes the analysis. NY DFS notes that many external-facing systems, such as basic marketing pages, may not require MFA. But MFA may be expected where an external-facing system can be used to access other information systems without authentication, or where it otherwise poses a material cybersecurity risk to the Covered Entity, customers, other systems, or nonpublic information. For example, an insurance company’s website that contains only publicly available marketing materials would not need MFA. If the website enables access to personal information, however, additional analysis may be necessary.

Compensating Controls: Allowed, But Tightly Governed

Part 500 permits “reasonably equivalent or more secure” compensating controls in in place of MFA, but only with specific governance guardrails: CISO approval in writing and periodic review at least annually. Similarly, in examinations, NY DFS often focuses on the reasonableness of the decision-making and the supporting documentation, not just the existence of a tool. A compensating control may be reasonable immediately following the acquisition of another company during the transition period but may not be reasonable the following year.

Our Take

NY DFS’s recent guidance reinforces that MFA is a baseline expectation under Part 500. In practice, NY DFS supervision focuses on whether MFA is implemented effectively, whether coverage is complete, and whether exceptions or alternatives are supported by documentation and governance. Here are a few steps to help identify potential gaps and achieve compliance:

1. Confirm MFA is implemented broadly and consistently

Validating that MFA is not only deployed but consistently enforced across the access paths and information systems is key. NY DFS highlights the scope and sufficiency of implementation, including whether MFA has been implemented with third-party platforms.

2. Review documentation supporting MFA scope and design choices

NY DFS emphasizes documentation and reasonableness of risk-based determinations. Even strong technical controls can fall short if the organization cannot explain scope, exceptions, and design decisions.

3. Review and assess whether the existing process for compensating controls meets NY DFS requirements

NY DFS highlights governance requirements for compensating controls, including written CISO approval and periodic review at minimum annually.

The NY DFS guidance is another reminder for Covered Entities to get ready to demonstrate that MFA is consistently enforced across environments, and any exceptions or compensating controls are supported by clear documentation and governance practices.

Thanks to Jake Alfarah for his assistance with this post.

A threat already identified – From awareness to action

As early as 2024, the CNIL warned of a 20% increase in breach notifications and a surge in large-scale data breaches. It noted that attackers regularly exploited the same vulnerabilities, which included compromise of login credentials and failure to detect intrusions, and also frequently involved processors.

Although the number of sanctions may still appear small relative to the number of data breach notifications (5,629 in 2024), four significant fines were announced within two months, targeting both controllers and processors:

• €1.7M against a software publisher in the social welfare sector (December 2025);
• €1M against a marketing processor of a streaming platform (December 2025);
• €5M against the French public body in charge of employment (January 2026); and
• €42M against a major ISP (January 2026).

What to expect in 2026

This focus is in line with the CNIL’s 2025–2028 strategic plan, in which cybersecurity features as one of the four priority areas. It is also reflected in the guidance issued on 30 April 2025 regarding how security measures should be strengthened. This emphasised rigorous identity and access management, real-time logging and analysis of network traffic, regular cybersecurity training for staff, and better oversight of security arrangements with processors and subprocessors.

More specifically, the CNIL now requires companies holding customer, prospect, and user databases comprising data relating to several million individuals to implement multi-factor authentication for their employees, partners, processors, and any other parties that can access the database remotely. It also encourages adherence to the recommendations already published by the CNIL and France’s National Agency for the Security of Information Systems (ANSSI).

Compliance with this requirement for multi-factor authentication will be subject to inspections by the CNIL from 2026 onwards. Failure to implement multi-factor authentication may lead to the commencement of enforcement proceedings.

To access the CNIL’s 2025 review: Sanctions and corrective measures: the CNIL presents its 2025 review | CNIL – to access the CNIL’s recommendations on multi-factor authentication: https://cnil.fr/fr/recommandation-mfa

During its most recent board meeting at the end of February 2026, CalPrivacy provided further insight into the new audit requirements and what businesses can expect in the coming year.

WHO IS COVERED

Cybersecurity audit requirements apply to a business whose processing of personal information presents “significant risk to consumers’ security.” In determining whether processing presents a “significant risk,” the Regulations contemplate factors such as the business’s size and revenue, and the volume and sensitivity of personal information it processes.[1]  

TIMING

The Regulations establish phased timing for initial compliance depending on a business’s gross revenue. A business subject to the requirements must complete a cybersecurity audit report and submit a certification to CalPrivacy by:

• April 1, 2028, if the business’s annual gross revenue for 2026 was over $100 million as of January 1, 2027. The audit would cover January 1, 2027 to January 1, 2028.
• April 1, 2029, if the business’s annual gross revenue for 2027 was between $50 million and $100 million as of January 1, 2028. The audit would cover January 1, 2028 to January 1, 2029.
• April 1, 2030, if the business’s annual gross revenue for 2028 was less than $50 million. The audit would cover January 1, 2029 to January 1, 2030.
• After April 1, 2030, if on January 1 of a given year, a business meets the general criteria discussed above in the preceding year, it will need to complete a cybersecurity audit.

SCOPE, THOROUGHNESS, AND INDEPENDENCE OF CYBERSECURITY AUDIT

Under section 7123 of the Regulations, the cybersecurity audit must evaluate “how the business’s cybersecurity program protects personal information . . . and protects against unauthorized activity affecting the availability of personal information.” It must span across “the business’s establishment, implementation, and maintenance of its cybersecurity program, including the related written documentation thereof (e.g., policies and procedures), that is appropriate to the business’s size and complexity and the nature and scope of its processing activities, taking into account the state of the art and cost of implementing the components of a cybersecurity program.” The cybersecurity audit must also assess each of the 18 components[2] listed that the auditor deems applicable to the business’s information system, and may cover additional components of a cybersecurity program beyond those listed.

The cybersecurity audit must result in a written audit report that describes the relevant policies, procedures, and practices assessed and includes, among others, any gaps or weaknesses and documents the business’s remediation plan and timeline, any corrections to prior audit reports, and list the titles of up to three individuals responsible for the cybersecurity program.

While the Regulations do not expressly require submission of the report itself to CalPrivacy, the report must be provided to a member of the business’s executive management team responsible for the cybersecurity program, and both the business and the auditor must retain relevant audit documentation for at least five years.

The cybersecurity audit must be completed by a “qualified, objective, independent professional” auditor who has knowledge of cybersecurity and how to audit a business’s cybersecurity program. The auditor may be internal or external to the business; if they are internal, independence and objectivity must be demonstrable.

RECENT INSIGHTS FROM CALPRIVACY

CalPrivacy indicated during its February 27, 2026 board meeting that it will publish short-form overviews for businesses and more robust compliance checklists for practitioners. CalPrivacy aims to “better educate businesses” and “help practitioners assist those businesses in coming into compliance,” with materials to be made available on the CalPrivacy website and promoted in spring and summer 2026. An active and specialized CalPrivacy Audits Division is expected under the recently appointed Chief Privacy Auditor Sabrina Boyce Ross with the support of a growing number of legal specialists and technologists.

TAKEAWAYS

The Regulations provide a framework for demonstrating that a cybersecurity program is designed thoughtfully and operates effectively. As the Regulations allow leveraging existing audit, assessment, or evaluation prepared for other purposes (e.g., an audit that uses the National Institute of Standards and Technology Cybersecurity Framework 2.0), provided they meet the requirements specified, first understanding the existing resources and assessing how they map onto the requirements under the Regulations will help identify opportunities to streamline the growing list of must-haves. Inventorying the relevant documentation and evaluating potential auditors that fit the qualifications now will also help save time and headaches down the road. After all, the first auditable period begins on January 1, 2027, less than ten months from now.

[1] Specifically, businesses that meet the following criteria must complete audits: a business that derives 50% or more of its annual revenues from selling or sharing consumers’ personal information; or a business that has an annual gross revenue exceeding $25 million in the preceding calendar year; and the business processed the personal information of 250,000 or more consumers or households in the preceding calendar year; or the business processed the sensitive personal information of 50,000 or more consumers in the preceding calendar year.

[2] (1) Authentication (including multi-factor authentication and strong password requirements); (2) encryption of personal information at rest and in transit; (3) account management and access controls; (4) inventory and management of personal information and the business’s information system; (5) secure configuration of hardware and software; (6) internal and external vulnerability scans, penetration testing, and vulnerability disclosure and reporting; (7) audit-log management; (8) network monitoring and defenses; (9) antivirus and antimalware protections; (10) segmentation of information systems; (11) limitation and control of ports, services, and protocols; (12) cybersecurity awareness regarding evolving threats and countermeasures; (13) cybersecurity education and training for personnel with system access; (14) secure development and coding practices; (15) oversight of service providers, contractors, and third parties; (16) retention schedules and proper disposal of personal information; (17) security-incident response management; and (18) business-continuity and disaster-recovery planning.

Although companies are generally aware of the potential for federal enforcement under HIPAA, companies should also consider the additional risks posed by state regulators enforcing the HIPAA Privacy and Security Rules. Additionally, the Massachusetts and Connecticut settlements demonstrate that state regulators may seek additional fines and requirements beyond those imposed by HHS.  Together, these actions underscore the continued regulatory scrutiny HIPAA-covered companies face from both federal and state regulators in what appear to be coordinated state enforcement actions following the HHS settlement last May.

Background

Comstar experienced a ransomware incident in 2022, which involved unauthorized access, encryption, and exfiltration of the company’s files.  Comstar’s forensic investigation confirmed that the threat actor obtained personal information and Protected Health Information (PHI), including names, dates of birth, Social Security numbers (SSN), driver’s license numbers, financial account numbers, health insurance information, and medical assessment information.  The company disclosed the incident on March 25, 2022, when it provided notification letters to affected individuals.  In total, the incident affected the information of 585,621 individuals, including more 320,000 Massachusetts residents and more than 22,000 Connecticut residents.  According to HHS’ investigation, Comstar violated requirements to conduct an accurate and thorough risk assessment related to electronic PHI that it holds. 

Cybersecurity Requirements

The May 2025 HHS settlement includes a corrective action plan agreed to by Comstar that requires it to develop a detailed inventory of physical and virtual assets used to collect and process PHI; conduct a risk analysis and prepare a risk management plan as it relates to the confidentiality, integrity, and availability of PHI in Comstar’s environment; and revise Comstar’s procedures and policies to comply with the HIPAA Privacy and Security Rules, and Breach Notification Rules.

In comparison, the January 28, 2026 settlements between Comstar and the Attorneys General of Massachusetts and Connecticut include more prescriptive requirements and detail many of the measures that organizations often consider implementing to strengthen their cybersecurity program, including the following steps:

• Use of encryption for personal information and PHI at rest and in transit.
• Conduct annual risk assessments and penetration testing, and implement remediation measures accordingly.
• Deploy multi-factor authentication (MFA) for individual user accounts, system administrator accounts, and remote connections to the company’s network.
• Enhance the cybersecurity program maturity by developing a Written Information Security Program (WISP), and adopting a zero-trust architecture.
• Appointing a Chief Information Security Officer (CISO) responsible for maintaining the information security program and advising the CEO on the program, including reporting to the CEO on security risks faced by Comstar on at least a semi-annual basis.
• Implement improved security controls, including through access control policies, password management, security monitoring (e.g., SIEM), email filtering, phishing protection, antivirus, data loss prevention (DLP) tools, and endpoint security (e.g., EDR).

Privacy & Information Governance Requirements

The settlement agreements with the state regulators also required a number of measures meant to reinforce Comstar’s privacy and data minimization practices.  In addition to notifying its employees of the consent order’s requirements, Comstar must provide specialized training to employees responsible for implementing the company’s information security program.  This training is required to cover how to safeguard and protect personal information.

Additionally, the settlement agreements expand the scope of the security awareness and privacy training required for all personnel with access to personal information as defined under state law, rather than solely personnel with access to PHI as planned under the settlement with HHS.  The state regulators expect Comstar to provide this training within 90 days of the consent order and annually thereafter.

The consent orders also require Comstar to comply with the minimum necessary standard of the HIPAA Privacy Rule which provides that PHI should not be collected or maintained when it is not necessary to satisfy a particular purpose.  The specific inclusion of the “minimum necessary” standard aligns with the growing list of regulators that have scrutinized over‑retention practices and data minimization requirements in recent settlements, an enforcement trend we have covered in previous articles, including actions taken by NYDFS and the FTC.

Notably, the state regulators emphasized the importance of effective information governance practices by imposing on Comstar precise data archiving requirements.  For both the Massachusetts and Connecticut Attorneys General, Comstar agreed to archive patient transportation data within two years of the date of service of the patient.  Moreover, where Comstar is required to retain these records for more than two years, the company will “to the extent required by applicable law…archive 2-7 year old records” within its offline archival storage under the agreement with the Massachusetts Attorney General.  The periods identified by the Massachusetts Attorney General for archival of old records imply a regulatory expectation that records will be kept for no longer than 7 years unless otherwise needed to fulfill regulatory, legal, and contractual requirements.

These data archiving requirements, coupled with an emphasis on compliance with the “minimum necessary” standard, were presumably included within the agreements with the goal of increasing the security of older data.  First, as many regulators have pointed out, data minimization means less information is available for a threat actor to potentially obtain in a security incident; and, second, by moving older data to offline storage, that data may become more difficult for the threat actor to access when properly configured.  This requirement is somewhat similar to the archival and record retention requirements national securities exchange members, brokers, and dealers:  they “must preserve for a period of not less than 6 years, the first two years in an easily accessible place.”

Our take

The various HHS and state consent orders with Comstar serve as a helpful blueprint for organizations seeking to enhance their cybersecurity, privacy, and information governance and retention programs, at a time when regulators’ focus on all three dimensions continues to intensify.  As regulators increasingly scrutinize data retention and storage practices and compliance with data minimization standards, companies should develop a plan to update their information governance strategy, with particular attention to records containing personal information.  These settlements are particularly interesting because the regulators were not just focused on over-retention – a mantra that has come out in many recent cyber incident settlements – but the state regulators focused on a more nuanced approach to protecting older data that does not need to be accessed as regularly by the business.  This evidences a more sophisticated approach to information governance and a new focus by regulators on pushing for more refined data security procedures and protections based on not just the sensitivity of the data, but how it is used within the organization and its age.

Additionally, although the risk of federal enforcement actions following a cybersecurity incident remains a key consideration, HIPAA-regulated entities should also account for the growing likelihood of state enforcement actions.  Here, the numerically inclined reader will have noticed that the civil penalties agreed to by Comstar in its agreements with the states Attorneys General were considerably higher than in its agreement with HHS.  In this instance, the Massachusetts and Connecticut Attorneys General settled for almost seven times more in civil penalties than HHS.

The latest developments in the Middle East – marked by a significant surge in military activity and retaliatory strikes across the region – have been accompanied by a parallel intensification of cyber operations.

It is common in such situations for state-sponsored hackers, hacktivist groups, and advanced persistent threat (APT) units to conduct coordinated campaigns against government systems, critical infrastructure, and private entities during conflict or warlike times.

This article examines the evolving cyber threat landscape that could arise from the current regional conflict and the potential implications for organisations operating within the Gulf.

Cyber Operations Surge in Parallel with Physical Conflict

As tensions develop, the cyber domain has become an increasingly active battleground. Cyber activity in the Middle East has historically featured a blend of destructive attacks, espionage, and large‑scale disruption. The current conflict reflects similar patterns, including:

• deployment of wiper malware against government and commercial systems
• DDoS campaigns targeting public‑sector platforms and media outlets
• attempts to infiltrate energy, aviation, and communications infrastructure
• digital influence operations aimed at shaping public narratives

It is common in such times for state‑aligned cyber units to launch broad offensive operations designed to disrupt military command systems, undermine state media channels, and interfere with critical service delivery. These operations typically include both high‑volume DDoS attacks and deeper intrusions targeting energy and aviation infrastructure.

At the same time, hacktivist groups aligned with various sides of the conflict often take advantage of the volatile environment, conducting opportunistic attacks such as account hijackings, website defacements, and mass dissemination of information or propaganda via compromised applications.

In response, opposing cyber actors typically target regional defence systems, infrastructure assets, and industrial environments. As is typical in periods of heightened conflict, these activities often blur the lines between state activity, state‑aligned groups, and independent cyber collectives pursuing ideological goals.

Gulf States: A Surge in Activity

Entities in the GCC states face elevated cyber risk both as direct targets and as potential collateral victims of spill‑over from the broader regional confrontation.

The Gulf’s strategic importance – its advanced digital and energy infrastructure, global economic ties, and hosting of international defence assets – makes it a central area of interest for hostile cyber activity during regional conflict.

According to reports from various authorities in the GCC, the recent scale of attempted intrusions is significant. For example, as of 18 February 2026, UAE authorities were intercepting between 90,000 and 200,000 cyberattacks per day, with more than 70% linked to state-sponsored threat actors.

On 21 February, the UAE Cybersecurity Council announced the successful disruption of coordinated attacks described as “terrorist in nature”, involving attempted ransomware deployment, network infiltration, and extensive phishing campaigns targeting national platforms.

These patterns reflect a long‑standing trend: in times of regional tension, Gulf states often experience a surge in activity from sophisticated actors aiming to disrupt energy supplies, defence systems and government networks, compromise sensitive data, or undermine regional stability.

What are the implications for GCC entities?

The cumulative effect of these developments is that organisations across the Middle East now face a materially elevated cyber‑risk profile. Industries with the greatest exposure include energy and oil infrastructure, aviation, financial services, defence, telecommunications, and IT service providers. Organisations without direct links to the conflict or only indirect connections to the Middle East may be affected through collateral targeting, opportunistic exploitation, or supply‑chain vulnerabilities.

To mitigate these risks, GCC organisations should undertake comprehensive exposure assessments, evaluating direct threats as well as indirect or spill‑over impacts. Enhanced governance, robust detection and response mechanisms, and well‑tested incident‑response and business‑continuity plans are essential. Organisations should consider undertaking rapid assessments of third‑party and supply-chain dependencies, resilience testing across critical functions, and conducting tabletop exercises that replicate state‑linked attack scenarios.

Insurance Implications

From a cyber insurance standpoint, organisations and insurers in the GCC should anticipate far greater focus on exclusion clauses, which commonly exclude losses arising from “war” or “hostile or warlike action” by a government or sovereign actor.

With the heightened risk of cyber-attacks at present, insureds should look closely at their policies to determine whether they have sufficient cyber cover for state-linked incidents, and where there is doubt, they should seek to include greater clarity. 

Insurers, for their part, should consider aggregation risk (given the sheer volume of cyber-attacks and potential for correlated claims across multiple policyholders), clarify exclusion wording, and ensure that the exclusions align with the distinct realities of digital conflict.

Conclusion

Cyber operations have become a defining feature of geopolitical tension in the Middle East, operating alongside and often amplifying physical conflict. For organisations in the Gulf region, this environment demands heightened vigilance, accelerated defensive measures, more stringent compliance measures, and recognition that cyber resilience has become inseparable from broader business continuity and national security.

In the event of a cyber incident, the NRF team is available to assist on our 24/7 365 hotline. Please contact us via databreachresponse@nortonrosefulbright.com or +44 20 7444 5452 / +971 4 369 6362.

With thanks to Alaa El Kholy for her contribution to this publication.

To read our analysis of these recent decisions and practical takeaways for safeguarding privilege while using GenAI, click here to access the article.

Background

Bret Stanley, one of several plaintiff attorneys in the MDL proceeding against Uber, also represents plaintiffs in other matters against Uber. The Court previously determined that Stanley violated the Protective Order in the MDL by disclosing information that Uber had designated as confidential in the MDL. Uber filed motions to enforce the Protective Order against Stanley in August 2025 and again in December 2025.

First Protective Order Violation (August 2025)

Uber argued that either Stanley or his co-counsel violated the Protective Order, which provided that a “Receiving Party may use Protected Material that is disclosed or produced by another Party or by a Non-Party in connection with this case only for prosecuting, defending, or attempting to settle this Action or the consolidated [California JCCP] action captioned In re Uber Rideshare Cases…so long as such use is permitted herein” Specifically, Stanley included lists containing protected information, specifically the names of Uber policies and how Uber categorized the policies, in discovery requests served on Uber in other cases in Texas and New Jersey, and nearly identical requests were served by other plaintiffs’ attorneys in two additional New Jersey cases. In a ruling on the record for an August 12, 2025 hearing, the Court found that Stanley’s spreadsheets and document requests in other litigation disclosed the complete substantive contents of certain documents Uber designated as confidential in the MDL, stating that it was “pretty straightforward that a disclosure occurred” and noting that “Stanley could have challenged Uber’s confidentiality designations if he had wished to do so, but that he never did.”

On August 18, 2025, the Court adopted a joint proposed order finding that Stanley violated the Protective Order. The Court ordered Stanley to identify all persons outside the MDL to whom he disclosed confidential information and to provide a copy of the order to those persons and courts within three days. The Court also ordered Stanley to take reasonable efforts to retrieve or ensure destruction of all unauthorized confidential information. The Court did not impose monetary sanctions in August.

However, Stanley failed to notify the appropriate courts and persons of the Court’s August 18, 2025 order within the required three-day deadline. Additionally, despite the Courts order that Stanley needed to ensure that the material was destroyed and his co-counsel’s knowledge of the violation, his co-counsel refiled the same confidential material in the public record in one of the cases on October 8, 2025, with the filing remaining publicly accessible for approximately thirteen days.

Second Protective Order Violation (December 2025)

Separately, Stanley searched for documents related to another matter in the repository of documents that Uber produced in the MDL, including documents designated as confidential under the Protective Order. Stanley then relied on what he found in a confidential document to advance arguments in his unrelated matter, though he did not disclose the document itself to that court or others unauthorized to see it. Stanley had access to this repository of documents because of his membership in the Plaintiff Steering Committee.

The Court’s February 17,2026 Order

            First Motion for Sanctions for the Disclosure of the Policy List

The Court found that “Stanley’s disclosure of that information unilaterally rendered Uber’s designations meaningless, disregarding the Protective Order’s process for challenging a designation if parties reasonably disagree over whether information should be protected” and that “[a]ttorneys do not have ‘discretion to decide unilaterally that competing rationales…permit the blatant breach of preexisting protective orders.’” The Court found that Stanley’s interpretation of the Protective Order was impermissible and unreasonable and that some sanction was required under Rule 37(b)(2)(C). On the other hand, Uber had not shown significant actual or likely harm from the disclosure, and its request for attorneys’ fees was excessive under the circumstances.

Given Stanley’s failure to take reasonable efforts to retrieve or ensure destruction of all unauthorized confidential information after being ordered to in August 2025, the Court granted Uber’s first motion for sanctions in part in its February 2026 Order and ordered Stanley to pay Uber $30,000 as partial reimbursement for its attorneys’ fees within thirty days. The Court considered several factors in reducing the fee award of $168,572.97 original requested by Uber, including:

• Uber delayed seeking sanctions and appeared to have “sandbagged” its request, with no indication in its original motion that more than $150,000 in attorneys’ fees would be sought and “remain like a sword handing by a slender thread, ready to drop if Stanley was late or otherwise delinquent in meeting his obligations”
• Uber’s billing records showed the matter was overstaffed with senior attorneys and overworked beyond what was reasonable for the matters in dispute
• While disclosure was improper, Uber had not shown actual harm, and the lack of harm informed the Court’s assessment of a just sanction
• Uber’s own conduct in the MDL warranted a reduction in the fees that it should be permitted to recover because the Court previously found that Uber likely violated at least one discovery order and had “wasted the Court’s and Plaintiffs’ time” through incomplete and misleading disclosures
• Stanley directly revealed protected material only to other attorneys and courts
• Stanley genuinely, though unreasonably, believed his disclosure did not violate the Protective Order, and Uber had not shown bad faith

The Court also recognized that protective orders for confidential information are not intended to serve as barriers to efficient and effective discovery in other litigation. Accordingly, the Court ordered the parties to meet and confer regarding the degree to which Uber’s policy names are “CONFIDENTIAL” or “HIGHLY CONFIDENTIAL – ATTORNEYS’ EYES ONLY” within the meaning of the Protective Order and “to consider whether a modification to the Protective Order is appropriate to allow for limited use of this or other material designated as confidential in serving discovery requests in other litigation, subject to specific safeguards to prevent undue public disclosure.”

            Second Motion for Sanctions for Conducting an Unauthorized Search

For the second motion involving Stanley’s unauthorized search of the MDL discovery repository, the Court found that Stanley violated the Protective Order “when he resorted to self-help to research his [] client’s claims in the confidential MDL discovery repository” and that sanctions were appropriate under Rule 37(b)(2)(C). The Court ordered Stanley to pay Uber’s reasonable attorneys’ fees for bringing that motion, with the parties encouraged to negotiate the amount. 

The Court also referred Uber’s request to disqualify Stanley from the Plaintiff Steering Committee to the appropriate court for resolution.

Our Take

Regardless of the type or size of litigation, the majority of the parties will at some point be required to produce highly sensitive and confidential information to the other side. Production of the information does not convey any additional rights or ownership to the receiving party, nor does it grant the receiving party rights to use this information as it sees fit. However as soon as a party produces the information, their ability to control the information decreases dramatically. Protective orders provide rules for this exchange of information allowing parties to share sensitive information with other parties in order to further the truth-seeking function of the court and to avoid surprises at trial without needing to worry that the information will be used for improper purposes or cause harm to the producing party. If a party believes an opponent’s designation is unwarranted, the right approach is to meet and confer and raise a challenge to the court if necessary not decide unilaterally what portions of an opponent’s confidential documents can and cannot be disclosed.

This Order makes clear that protective orders are not perfunctory agreements nor orders that are issued at the beginning of litigation and then have little meaning as the case unfolds. Compliance is non-negotiable and courts are prepared to order parties to comply. 

This ruling also highlights the importance of carefully negotiating the protective order and being prepared to enforce it if it becomes necessary. When negotiating the protection of sensitive information, it is crucial for parties to consider cyber security obligations that should be incorporated, as we have discussed in prior blog posts and articles: LINK and LINK. If more courts take the approach Judge Cisneros did, that may give some comfort to clients who have to produce sensitive information in order to comply with their discovery obligations knowing the court  will impose sanctions where “necessary and sufficient to deter future violations and appropriate to partially compensate [the producing party] for its costs.”