In a rare digital privacy verdict, an eight-person San Francisco federal jury held in August 2025 that Meta illegally eavesdropped on millions of women who entered menstrual and pregnancy health data into the Flo Period and Ovulation Tracker app (Flo app), finding that the social media giant had violated the 1967 California Invasion of Privacy Act (CIPA). Hundreds of lawsuits about websites and apps have invoked the law, originally enacted to protect consumers from unauthorized recordings of phone calls.

The case’s substantial implications are strongest for the roughly 500 CIPA lawsuits involving health information, which have been more successful in pretrial stages than other case types, reported Tammana Malik, an attorney at Troutman Amin. “Courts are taking a stricter approach when it comes to health information cases,” she told the Cybersecurity Law Report. “It’s an area where we have seen the plaintiffs doing really well.”

The jury reached conclusions on the core issues of “eavesdropping” and expectations of confidentiality running through CIPA case law. If Meta’s promised appeals fail, it could end up paying hundreds of millions of dollars, thanks to the law’s $5,000 statutory damages fine for each affected Californian. The verdict warns the multitudes of companies that receive data from a software development kit (SDK) in a mobile application that they could have CIPA liability.

This article, the first in a two-part series about CIPA lawsuits, examines how the plaintiffs persuaded the jury that Meta intentionally eavesdropped on them without consent, and the dynamics of trying privacy cases before a jury, with commentary from privacy litigators at Farella, Braun & Martel, Holland & Knight and Troutman Amin, and from an attorney who reached a $725‑million settlement with Meta. Part two will discuss the implications of the verdict for other CIPA disputes and examine other important 2025 CIPA court decisions.

See “Lessons From the Trenches: Winning Strategies for Defeating Pen Register Lawsuits” (Jun. 12, 2024).

How Plaintiffs Made It to Trial

Plaintiffs filed the case in 2021, based on a Wall Street Journal 2019 investigation and an FTC enforcement action against Flo Health, Inc. (Flo). The plaintiffs argued that Meta was liable for receiving information between June 2016 and February 2019 about their menstrual cycles, pregnancy goals and 10 other details about reproductive health that Flo’s app transmitted using Meta’s SDK.

In the Court’s May 2025 class certification and summary judgment decisions, it held that several disputed points in the case belonged with a jury. These included whether intentional eavesdropping occurred and whether users consented to allow Meta to “record” interactions with the Flo app.

As trial approached, Meta had two co-defendants, but fellow Big Tech monolith Google settled two weeks before opening arguments. The parties have not disclosed terms. A fourth defendant, defunct mobile analytics company Flurry, settled with plaintiffs for $3.5 million in March 2025. Flo and Meta then opted to risk a giant verdict for the possibility of cementing CIPA defense arguments as winning precedents.

See “Google’s Wiretap Cases Highlight Evolving Privacy Transparency Standards” (Jan. 24, 2024).

The Playing Field for a Trial of App Users Versus Tech Companies

The plaintiffs’ attorneys had a few strategic advantages for a trial presenting five women as the victims of prominent technology companies that care more about ad placements than whether users consented to share personal data, raising questions about Meta’s gamble on a jury over settlement.

The Bay Area Jury

The defendants had some reason to be confident. In the Bay Area, some sets of jurors can be problematic for privacy plaintiffs litigating against Big Tech companies, Bleichmar Fonti & Auld partner Lesley Weaver told the Cybersecurity Law Report. “Lawyers may face cynical jurors who say, ‘I assume everybody’s taking everything data-wise. I don’t believe anything anybody says.’ The plaintiffs have to win over that juror,” she reported.

The plaintiffs’ lawyers may also face Bay Area jurors who are “tech defenders,” Weaver continued. Meta’s post-trial motion highlights this demographic, with a twist. The defendant contends that the Court should have excluded “Juror #4” because that juror stated that he was friends with a WhatsApp founder who publicly disagreed with Facebook after it acquired that popular messaging app.

Highly Sensitive Data in the Courtroom

The plaintiffs had the intimacy of menstrual data as a sympathy point to anchor their arguments, Malik noted. Risks around reproductive health information have been widely discussed since the Supreme Court’s Dobbs decision about abortion rights, including state prosecutors’ vows to use menstrual and pregnancy information to investigate abortions, she observed.

Privacy concerns also have deepened culturally, Farella Braun partner Sushila Chanana observed, as people’s use of “health applications has increased drastically over the past five or six years. [Data breaches have] also increased in that time. They are always in the news. Consumers are just thinking about personal data more,” she told the Cybersecurity Law Report.

Public awareness of third-party data sharing for advertising has grown with the expansion of cookie banners, Chanana continued. “Consumers today are more aware of the consequences of poor data management and expect businesses to be transparent about data collection and usage practices – especially when it comes to sensitive health information,” she said.

A Strong Promise Unfulfilled

Plaintiffs litigating a data privacy case almost always show the jury a broken promise. The second crucial exhibit they must show is technical evidence of mishandled data.

In this trial, the plaintiffs spotlighted a commitment in Flo’s 2018 privacy policy, which indicated that the app might share users’ information with third parties if “reasonably necessary to perform their work,” such as supplying software applications and web hosting. The policy clarified, however, that it would “exclud[e] information regarding your marked cycles, pregnancy, symptoms, notes and other information that is entered by you and that you do not elect to share.”

“Plaintiffs are more likely to win in a privacy case where a defendant breached an express promise not to do something by then doing it. That’s what happened here,” explained Weaver, who won a $15‑million jury verdict in 2014 against a website that shared information about users’ sexually transmitted disease status, and then, in 2024, helped plaintiffs reach a $725‑million settlement with Meta for sharing data with Cambridge Analytica.

Plaintiffs needed to prove that their menstrual and pregnancy information traveled to Meta using its SDK. Courtroom jousting by expert witnesses over data transmissions and “app events” can implicitly help plaintiffs’ case – the jury’s effort to decipher the technical details underscores the plaintiffs’ predicament with consent. “The asymmetry in knowledge between what the companies are doing with data and what the average person understands is happening is a gap that has closed in recent years, but it’s still immense,” Weaver highlighted.

See “Why Companies Unintentionally Fail to Honor Opt-Outs” (Aug. 16, 2023).

The Complications of Two Defendants

The plaintiffs had a procedural advantage at trial. The Court had allowed them to move forward with multiple legal claims against Flo, but only a CIPA Section 632 claim against Meta. Plaintiffs’ attorneys had the advantage of presenting evidence against two defendants, telling a fuller story. In contrast, the two defendants were at risk of fragmenting their arguments to address different claims.

Flo settled before final arguments. The parties did not disclose that settlement’s financial terms. That left Meta to face a jury without an app owner to absorb blame for breaking its promise to users.

Meta’s attorneys decided to move forward with the federal jury, facing the risks of defending itself as the deep pockets quietly receiving the data as a third party. “Meta has much more at stake than any individual app owner or web developer,” pointed out Holland & Knight partner Ashley Shively. “This SDK is fundamental to Meta’s business and how it makes money,” so it has incentive to defend it to the last, she added. Perhaps the trial risk was worth the gamble to Meta, which has the resources to look past the jury to appellate judges who may be skeptical about applying a 1960s law to today’s technology.

See “Defense and Plaintiff Perspectives on How to Survive Data Privacy Collateral Litigation” (Mar. 8, 2017).

The Disputed Points in the Trial

The trial delivered an unusual courtroom spectacle of privacy victims and a privacy engineer testifying about the governance of intimate personal data, as well as cross-examinations raking over a few insensitive internal employee comments about personal data. In its defense, Meta tried to combat unflattering facts about notice and consent, and to downplay its control over its SDK’s actions.

The CIPA claim before the jury required it to answer the following questions:

• Did Meta intentionally eavesdrop on plaintiffs’ conversations on an electronic device?
• Did plaintiffs prove they had a reasonable expectation that the conversation was not being overheard and/or recorded?
• Did Meta have the consent of all parties to the conversation to record it?

Eavesdropping, or Passing Secondhand Information?

The jury’s central factual decision to make was whether Meta’s SDK directly recorded plaintiffs’ communications. The plaintiffs’ experts claimed that the SDK listened in the background while women typed in the Flo app, then sent to Meta the records of women’s answers to 12 Flo questions about pregnancy or menstruation details, such as last period date and length of menstrual cycle.

To counter the eavesdropping accusation, Meta strove mightily to persuade the jury that its SDK relayed a “secondhand” version of the women’s typed information rather than listening secretly to obtain a word-for-word version of a communication, the way a spy’s classic wiretap does. Only Flo “heard” the details, Meta’s engineers testified, further explaining that the Meta SDK “generated” a separate summary that did not match exactly what the women typed in the app.

The defendants “were relying on very technical discussions about how the SDK is integrated into the app code and the timing of separate transmissions” between user and app, and then app and Meta, Shively noted. This was “to try and lead the jury to the conclusion there was no eavesdropping or that this data was not confidential. And that’s incredibly challenging,” she said.

See “Facebook Wiretap Ruling Inspires Slew of Lawsuits Over Consumer Tracking” (Dec. 2, 2020).

Intentional Data Collection, or Accidental and Unwanted?

Meta claimed it did not “intentionally” seek the menstrual data, emphasizing its passivity throughout the process. Apps like Flo configured Meta’s free, open-source SDK as they wanted, choosing the app events to send to Meta for its ad services. Meta imposed almost no requirement about the information it wanted from apps for ads, nor did it need all the information Flo sent about the users, the company’s defense insisted.

Meta’s defense counsel showed the jury two letters that it sent Flo warning that its app had improperly sent forbidden PII to Meta, violating its terms of service for business tools, including the SDK.

“Meta was trying to walk this tightrope in their defense strategy, both blaming the app developer for sending data that Meta claims it never wanted and downplaying the significance of the data, saying it was minimal and limited,” Shively said.

The second part of the Court’s jury instruction around intent snared Meta, however. Intentional eavesdropping reflects either a defendant’s “purpose or desire” to record a confidential conversation or that the defendant acted “with the knowledge to a substantial certainty that his use of the equipment will result in the recordation of a confidential conversation,” according to the instruction.

Inspired by the second prong of the definition of “intent” in the jury instruction, the plaintiffs highlighted that Meta crafted its SDK to ingest information about users’ statements. This underscored that “the Facebook SDK was doing the transmission, not the Flo app,” Weaver said. The plaintiffs’ presentation about the SDK’s operations reinforced that Meta wanted it nestled inside the app, like a bug on the phone line. “After you spend some time with the details, it becomes very clear to people what’s going on,” she underlined.

See our four-part series on tracking technologies: “Privacy Regulation, Enforcement and Risk” (Jan. 17, 2024), “A Deep Dive on What They Are and How They Work” (Jan. 31, 2024), “A 360‑Degree Governance Plan” (Feb. 21, 2024), and “Compliance Challenges and Solutions” (Apr. 17, 2024).

Expectation of Confidentiality, or Knowledge of Recording?

Meta made a technical point in its post-trial motion, arguing that the plaintiffs could not expect confidentiality because their “entering information into a period and pregnancy tracking app suggests that the information was ‘by nature recorded’ by the app.”

Defendants like Meta have grounds to keep battling the plaintiffs’ arguments that wiretapping law fits with online tracking technologies, Shively opined. “Most of the authority on confidentiality comes from call recording cases, like a case 20 or so years ago about an ex‑spouse listening to their significant other in the next room. None of the law has been developed in the context of internet activity communications,” she pointed out.

Meta cast the SDK’s transmissions as prosaic operational data to be used for automated advertising. Plaintiffs’ attorneys in privacy cases often seek to translate for the jury the experts’ terminology, Weaver noted. “Everyone calls it ‘data,’ which is clinical. But it’s not data, it’s information, and information about you that can be stitched together for all kinds of purposes,” she said.

The plaintiffs in this Meta case were able to argue that they expected confidentiality because the case involved intimate health data, Shively noted. In a similar suit involving an e‑commerce or retail company facing CIPA claims, plaintiffs’ expectation of confidentiality argument might not hold up because the unauthorized revelation of purchasing information seems less harmful than menstrual data, she said.

Consent to Share Menstrual Information, or Insufficient Boilerplate?

The two-part jury instruction for assessing the plaintiffs’ consent was defendant friendly. It defined plaintiffs’ consent as either affirmative, sufficiently clear words or acts, or implicit approval. “A plaintiff may also express consent by silence or inaction if a reasonable person would understand that the silence or inaction intended to indicate consent,” according to the instruction.

The jury rejected Meta’s contention that the plaintiffs’ agreement to boilerplate Facebook terms of service sufficed as their specific consent to share this personal information. Meta disclosed it received data about user activity on third-party apps and may use the information for advertising. Plaintiffs’ counsel stated in the closing argument that, to constitute consent, Meta’s policy needed to specify that it might gather “private health information” or cull data from “fertility apps.”

Furthermore, Flo’s privacy policy (during the class period) mentioned sharing PII with Facebook and other third parties but also said that it did not rent or sell information without the user’s consent.

See “Practical Strategies for Effective Consent Management” (Sep. 25, 2024).

Contents of the Communication, or Just Data Points?

To succeed under CIPA Section 632, the plaintiffs had to prove that the “contents of their communication” were intercepted by Meta, as opposed to just “the record” of the communications, Malik noted.

Perhaps influencing the outcome, the jury instructions listed 12 data points that app users entered in the app and Meta received. Flo’s names for the data points included “R_SELECT_PERIOD_LENGTH” and “R_PREGNANCY_WEEK_CHOSEN,” among other pregnancy and menstruation details. “The custom event labels probably had an impact on the case,” persuading the Court and the jury that Meta was receiving the “contents of a conversation” rather than just a scattering of data points that simply served as a record of the communications, Malik posited.

See “Sale of 23andMe’s Genetic Data: Lessons for Companies Around Sensitive Data” (Apr. 23, 2025).

Post-Trial Motion

After trial, Meta filed a motion under Rule 50(b) arguing that the evidence in trial allowed only one conclusion, of no violation. The company reiterated its trial arguments that evidence showed no “eavesdropping,” “recording,” “intentionality” or “confidentiality.”

Meta requests that, “at minimum,” the Court order a new trial. The Court made a critical error in the jury instruction about intent, issued erroneous evidentiary rulings and wrongly seated an admittedly biased juror, Meta asserts, adding that each error independently warrants a new trial. Plaintiffs argued in their opposition, filed August 21, 2025, that “the jury was well within its right” to make its findings about eavesdropping, recording, intent and confidentiality.

The Statutory Damages Decision

If the Court denies Meta’s motion, it will then decide damages. The plaintiffs seek damages treating each member of the California class of plaintiffs as a single CIPA violation, Meta’s trial brief states. If the Court adopts that approach, “the number of unique California individuals would be the key inquiry,” said Shively.

The trial documents do not break out the number of Californians whose data was transmitted. The SDK transmitted to Meta data points about menstrual cycle length for more than 31 million individuals; California has 12% of the U.S. population.

Data reflecting users’ responses to the app was deleted in the normal course before litigation, Shively noted. Thus, the Court and parties lack shared evidence to determine which class members have a viable claim and may be entitled to damages. For an individual to be considered a member of the class with a viable claim, she will need to show that (1) she joined the app during the class period, (2) while physically present in California, and that she (3) shared “sensitive” information during the signup process, and (4) suffered a compensable injury resulting from the data shared with Meta.

“Meta makes a compelling case that resolving these questions will require an individual inquiry” for each member, Shively opined. Meta has a right to cross-examination, so it is unlikely to accept a self-attesting claims process.

The proliferation and ease of use of generative AI (GenAI) tools that are widely available on the market today have made it easier for cybercriminals to effortlessly carry out their attacks, including by impersonating corporate executives. It can be disturbingly difficult to identify a real individual from a deepfake, making AI-generated fraud a threat that requires urgent attention.

This article distills insights, delivered by panelists during an August 2025 HaystackID webinar, along with Cybersecurity Law Report analysis, on what a deepfake is and common characteristics, red flags, and current trends in deepfake schemes, as well as practical tips for companies on how to spot one and avoid falling victim to this growing and fast-evolving cyber threat.

See “From CEO Deepfakes to AI Slop, AI Incident Tracking Ramps Up” (Jul. 30, 2025).

Defining “Deepfake”

In order to effectively identify a deepfake, it is necessary to first understand what it is. “A deepfake is a type of synthetic media created using artificial intelligence,” Rene Novoa, vice president of forensics at HaystackID, explained.

Deepfakes can take the form of audio, images, video, text or a combination of all four. Synthetic media is “AI-generated non-reality,” said Todd Tabor, HaystackID’s senior vice president of forensics. “It is pictures that are computer generated. It is video that is purported to be real but is completely computer generated.”

Synthetic media often is created using deep-learning techniques, particularly using a generative adversarial network (GAN), Novoa added. A GAN exists when two adversarial networks – a “generator” and a “discriminator” – compete against each other, and one network (the generator) generates new data using data that has been input into the AI training model, while the other (the discriminator) tries to decipher between the real data and the generated data. “It’s trying to find ways to fool itself,” Novoa explained. “Does it pass the test to be a deepfake?” Having something to compare itself to enables the generator to make increasingly realistic deepfakes.

The risk that GANs create for companies, however, is that they can be used by cybercriminals as well. “Bad actors are also training their models” and “finding ways to make them look more real,” Novoa reported.

Trends in the Deepfake Threat Landscape

“It is not the technology. It is how it is being used,” Novoa said. Bad actors use synthetic media for various nefarious purposes, such as spreading misinformation, creating sexually explicit deepfakes, impersonating corporate executives to carry out financial extortion schemes and more.

Main Targets

A Deepfake Incident Report from Resemble.AI (Report), which analyzed 163 documented deepfake incidents that occurred between January and April 2025, provides clearer insight into the biggest targets of deepfake attacks and how they have evolved. Of the 163 deepfake incidents analyzed for the Report, 41% targeted public figures, including business leaders, politicians and celebrities. Thirty-four percent targeted private citizens, particularly women and children, while 18% targeted organizations, including corporations, government agencies and educational institutions. Just 7% targeted information systems, according to the Report.

See “Cybersecurity and AI Are Top Global Business Challenges Identified in Kroll Study” (Jul. 16, 2025).

Tools Used

Sophisticated criminal networks often will use multiple AI tools at once to create deepfakes, using a combination of AI-created video, audio and text, noted John Wilson, CISO and president of forensics at HaystackID.

According to the Report’s findings, 46% of the deepfake incidents analyzed were carried out using video formatting, followed by images (32%) and audio (22%). In these schemes, bad actors carried out their attacks using techniques such as voice cloning, facial manipulation or a combination of multiple media formats to create synchronized video-audio impersonations, occurring in 33% of incidents, the Report reveals.

Quantified Losses

Resemble.AI’s analysis also found that financial losses from the 163 disclosed incidents of deepfake-enabled fraud exceeded $200 million in the first quarter of 2025 alone. “I think the number [of incidents] is actually quite a bit higher,” Wilson said.

North Korean IT Worker Scheme

A North Korean scheme involving IT workers demonstrates how widespread and damaging a deepfake scheme can become. According to the DOJ, North Korean IT workers posing as U.S. citizens were able to obtain remote IT jobs at 309 U.S. companies, including Fortune 500 corporations.

The exploited companies include a major television network, a Silicon Valley technology company, an aerospace manufacturer, a U.S. car maker, a luxury retail store, and a U.S media and entertainment company, the DOJ stated. In total, the scheme generated more than $17 million in illicit revenue for the Democratic People’s Republic of Korea (DPRK) for its nuclear and ballistic missile programs.

According to information shared by the DOJ, the U.S. Department of Treasury and the FBI, the fraudulent workers’ covert tactics include:

• AI-Generated Resumes: The North Korean IT workers use “fraudulent documents, stolen identities, and false personas to obfuscate their identities and infiltrate legitimate companies,” the Treasury Department stated in a press release. With these stolen documents, the IT workers maintained a repository of job postings and generated fake resumes tailored to those open IT positions.
• Deepfake Job Interviews: They then participate in job interviews using deepfake tactics. “North Korean IT workers have been observed using [AI] and face-swapping technology during video job interviews to obfuscate their true identities,” according to the FBI.
• Laptop Farms: Once the IT workers were hired, U.S. accomplices would operate “laptop farms” in their homes, where computers from the U.S. companies were kept, “deceiving the companies into believing that the work was being performed in the United States,” the DOJ stated in a press release.

What is disturbing is that these threat actors “get elevated privileges, passwords, credentials and sensitive information,” Novoa said. In some cases, the DPRK IT workers “introduced malware into company networks to exfiltrate proprietary and sensitive data,” the Treasury Department stated.

See “Recognizing the Signs of Remote Employee Fraud to Save Money and Data” (Jun. 11, 2025).

Beneficial Uses Too

Synthetic media and deepfakes are not always used for nefarious purposes, said Wilson. The term deepfake “carries a negative connotation, but there are certainly a lot of legitimate uses,” he said, adding that a product video or a product image can be developed using AI tools, for example.

“It’s not always about fooling somebody,” Novoa concurred. A tool like ChatGPT, for example, can be used to create original media and original content, he said.

Several other widely available GenAI tools on the market enable even the most novice users to create synthetic media, even just for fun. Examples include text-to-image technologies, like Dall‑E, Stable Diffusion and Midjourney, while apps like SwapAI enable users to swap faces with ease.

Deepfake Red Flags

Companies should be aware of the following red flags, Novoa and Wilson highlighted, which could point to a deepfake:

• unnatural lighting and shadowing;
• unnatural or out-of-sync lip and speech;
• unnatural blinking (e.g., excessive blinking or lack of blinking);
• unnatural skin tone or changes in skin tone; and
• background distortions.

To spot a fake message, “look for subtle imperfections in images and videos,” the FBI advised. These include things like “distorted hands or feet, unrealistic facial features, indistinct or irregular faces, unrealistic accessories such as glasses or jewelry, inaccurate shadows, watermarks, voice call lag time, voice matching, and unnatural movements.”

The FBI further advised listening closely to a person’s tone and word choice “to distinguish between a legitimate phone call or voice message from a known contact and AI-generated voice cloning, as they can sound nearly identical.”

Measures to Prevent Falling for a Deepfake Scheme

Combating AI-enabled deception requires a layered strategy. Below are several steps companies should take to reduce the risk of becoming the next victim of a deepfake scheme.

Train Employees to Recognize Deepfakes

Employees should learn to spot deepfake scams. They should be instructed on the red flags above and take steps to verify the identity of the person who is calling, sending texts or leaving voice messages. “Before responding, research the originating number, organization, and/or person purporting to contact you,” the FBI advised in a May 2025 alert. “Then independently identify a phone number for the person and call to verify their authenticity.”

Likewise, employees should carefully examine the email address and other contact information, URLs, and spelling used in any correspondence or communications. “Scammers often use slight differences to deceive,” the FBI warned. “For instance, actors can incorporate publicly available photographs in text messages, use minor alterations in names and contact information, or use AI-generated voices to masquerade as a known contact.”

Legal teams should be educated as well, Wilson advised. “You have to educate your investigators – the boots on the ground” – so that they can look for red flags and identify fraudulent schemes, he said.

See “Staying Ahead of Rising Identity-Based and Cloud Intrusions” (Mar. 19, 2025).

Rehearse Incident Response Plans

Part of employee training should be preparing for a potential deepfake incident. In his interview with the World Economic Forum, sharing lessons learned from his company’s deepfake incident, Rob Greig, CIO of U.K.-based engineering company Arup Group, stressed the importance of rehearsing responses, “not to a particular incident, but to a general set of incidents that might occur so everyone knows what their role is.”

See our two-part series on a mock cyber incident tabletop exercise: “Day One, Everything at Once” (Jun. 19, 2024), and “Day Two and Beyond” (Jun. 26, 2024).

Deploy AI-Powered Deepfake Detection Measures

Training alone is not enough. Many deepfakes cannot be detected with the human eye. Moreover, traditional security tools were not designed to detect deepfakes. Detection is only possible with the right tools and expertise, including behavioral anomaly monitoring, and biometric authentication with liveness checks.

“You can’t trust what you see. You can’t trust what you hear,” Wilson said. “Get the tools that can help you identify some of these things.”

See “Examining the Cyber Threat Landscape Dominated by Stealth Attacks” (Mar. 20, 2024).

Lessons From Actual Events

Arup Group Financial Extortion Incident Demonstrates Importance of Visibility

Criminal networks also have been using deepfakes in financial extortion attempts. In one high-profile case that occurred in early 2024, bad actors were able to scam Arup Group out of $25 million by carrying out a sophisticated deepfake scheme. The fraudsters succeeded by getting a finance employee on a virtual call, tricking the employee into believing the meeting was with the company’s CFO and other senior management who were able to persuade the employee into making a purportedly urgent finance transfer. In reality, the call was an AI-created deepfake, and the employee had just transferred the money to fraudsters.

When the company realized it had been scammed, the first step was to “quickly assess the extent of the attack and identify if the entire organization was affected: Were our clients at risk? Were our people or their data at risk?” Greig shared in the interview. “With that visibility, we were able to very quickly identify that we were not compromised, and this was being caused by something else.”

To uncover a deepfake in the first place, it is essential to first have complete visibility over what is happening from a technology, cyber and data perspective within the organization, Greig advised. “Who has access to what and when? What data is moving around your organization? Who is trusted and what is not trusted? And what sort of erroneous activity is happening within the organization?”

Ferrari and WPP Demonstrate How to Thwart a Deepfake Scheme

Not all deepfake extortion schemes succeed. Companies looking for real-life case studies on how to successfully thwart a deepfake scheme can take a page from Ferrari and WPP.

Ferrari Case Study

In July 2024 a Ferrari executive received several text messages through WhatsApp, followed by a phone call from an unknown number. As Ferrari insiders told a news source, the voice on the other end sounded authentically like CEO Benedetto Vigna, who proceeded to ask for the executive’s help in closing a confidential acquisition by carrying out a currency hedge. He urged the executive to sign a nondisclosure agreement, adding that Italy’s market regulator and the Italian stock exchange already had been informed about the transaction.

The executive became suspicious, however, when he began to pick up on inconsistencies in the voice tones of the speaker on the other end of the line. To confirm the CEO’s identity, the executive asked a question that only Vigna would know the answer to — the title of a book Vigna had recommended to him days earlier. Unable to answer the question, the scammer ended the call.

WPP Deepfake Incident

Two months earlier, advertising company WPP had become the target of a similar AI-created scheme. As publicly reported, WPP CEO Mark Read detailed the deepfake scheme in an internal email to leadership. In that email, he described how cybercriminals created a WhatsApp account using a publicly available image of him, which was then used to arrange a Microsoft Teams meeting with another WPP senior executive using an AI-generated voice.

The email went on to list several red flags that offer wider lessons for all corporate executives, which include being aware of requests for personal information, like passports, or any mention of confidential acquisitions, transactions or money transfers.

As use of software-as-a-service (SaaS) has grown, so have the associated security threats. According to AppOmni’s 2025 State of SaaS Security Report (Report), there is a significant disconnect between organizations’ confidence in the security of their sanctioned SaaS applications and the dramatic increase in reported breaches involving SaaS. Drawing from a survey of more than 800 IT and security professionals, the Report explores organizations’ approaches to SaaS management, risk assessment and monitoring, ownership of responsibility for SaaS security and approaches to SaaS security monitoring. It also covers steps organizations can take to improve their SaaS security posture. This article discusses the key takeaways from the Report.

See “Staying Ahead of Rising Identity-Based and Cloud Intrusions” (Mar. 19, 2025).

Survey Demographics

The survey included 803 respondents, most of whom are the final decision-makers for their organizations’ IT and security purchases. Most respondents hold senior IT-oriented positions, including IT manager, director, administrator, specialist, engineer, security manager and analyst (collectively, 42%); managing director or general manager (14%); CTO (11%); and head of cybersecurity (4%).

Sixty percent of respondents are based in the U.S., with the remaining 40% divided roughly equally across Australia, Germany, Japan and the United Kingdom. The largest industry sectors represented in the study are IT services (30%), manufacturing (15%), and finance/insurance and software development (9% each). Three-quarters of the organizations represented in the study have more than 2,000 employees, including 30% with more than 5,000 employees.

Widespread Use of SaaS

Fifty-seven percent of respondents said they are aware of more than 50 SaaS applications in use in their organizations. Forty percent are aware of more than 100 SaaS applications in use. The five most widely used SaaS applications include Microsoft 365 (81%), Google Workspace (62%), Salesforce (44%), Adobe (34%) and Zoom (30%).

Increasing SaaS Incidents Despite Confidence in Security

The overwhelming majority of respondents (91%) reported confidence in their SaaS security posture, and 89% believe they have appropriate visibility into their SaaS environment. Notably, most respondents (88%) rated their confidence level in the security of their organizations’ sanctioned SaaS applications as a “four” on a scale of one to five, including 36% who rated it as a “five.” The primary drivers of respondents’ confidence in their SaaS security include:

• confidence in the SaaS provider (53%);
• high visibility into sanctioned SaaS apps (37%);
• confirming secure configuration at deployment (36%); and
• ongoing configuration management (23%).

However, neither appropriate configuration nor monitoring alone is sufficient to ensure SaaS security. “Monitoring without configuration enforcement results in alert fatigue. Configuration without monitoring leads to blind spots,” cautions the Report.

Notwithstanding respondents’ confidence in SaaS security, three-quarters of them also said they had experienced a SaaS incident or data breach in the past year – a 33% year-over-year increase. Those incidents involved:

• SaaS security vulnerabilities (41%);
• SaaS misconfiguration (29%);
• data exposure (26%);
• human error resulting in data exposure (25%);
• cyberattacks resulting in data breach (23%); and
• insider threats compromising security (22%).

Respondents’ top data-related concerns include:

• data breaches and loss of intellectual property (57%);
• compromise of customer data (37%);
• unintended data exposure (28%); and
• configurations deviating from policies (24%).

See “Limiting Data Breach Liability in Cloud Service Agreements” (Feb. 23, 2022).

Reasons for the Gap

The Report attributes the widening gap between organizations’ perceived and actual SaaS security posture to:

• misplaced confidence in SaaS security;
• inconsistent ownership of responsibility for SaaS security; and

outdated practices for monitoring SaaS applications.

See “Fostering Collaboration and Communication Between Security and Compliance” (Mar. 13, 2024).

SaaS Security Responsibilities and Oversight

Centralized Management

Virtually all respondents take a centralized approach to managing SaaS applications. Most (73%) have a policy permitting employees to use only sanctioned SaaS applications, which is enforced by their cybersecurity function. Nearly one-quarter have the same policy – but do not enforce it strictly. Just 2% of respondents leave management of SaaS applications to decentralized business units.

See “Negotiating SaaS Agreements” (Nov. 14, 2018).

Cybersecurity Teams

Nearly half or more of respondents said their organizations have cybersecurity teams dedicated to cloud security (65%), SaaS security (55%), network security (50%) and/or cybersecurity compliance (45%). Thirty percent have a dedicated identity and access management, threat intelligence and third-party risk team. Roughly one-fifth have teams dedicated to incident response, application security and/or endpoint security.

Most respondents (82%) said SaaS security is integrated into their overall cybersecurity strategy and incident response planning. Ownership of SaaS security varies widely among respondents. It most often lies with the following teams:

• security operations (47%);
• network security (40%); and/or
• cybersecurity compliance (37%).

Shared Responsibility

There was a year-over-year shift toward shared ownership of responsibility for SaaS security. In 2025, 43% of respondents said sole responsibility rests with the business owner of the SaaS app, down from 50% in 2024, while 41% said the business owner and cybersecurity team share ownership, up from just 34% in 2024. Just 16% said responsibility rests solely with the cybersecurity team. Shared ownership can reduce “stakeholder urgency” and potentially result in inconsistent practices and security gaps, cautions the Report.

When SaaS business owners share responsibility for SaaS security with cybersecurity functions, they most often collaborate with teams dedicated to:

• SaaS security (60%);
• cloud security (47%);
• cybersecurity compliance (33%);
• security operations (32%);
• network security (31%); and/or
• identity and access management (22%).

See “Ten Cybersecurity Resolutions for 2024” (Jan. 10, 2024).

Risk Assessments

More than three-quarters of respondents evaluate the risks associated with SaaS applications internally using industry frameworks (37%), proprietary tools (34%) or other auditing techniques (10%). Eleven percent use independent cybersecurity audits based on industry frameworks.

See “Unifying Risk Assessments: Breaking Silos to Enhance Efficiency and Manage Risk” (Jan. 29, 2025).

Monitoring SaaS Use and Security

Use of SaaS Apps

Nearly two-thirds of respondents (63%) use dedicated automated or semi-automated tooling or log-analysis processes to detect and monitor third-party apps that are connected to corporate SaaS environments. Seventeen percent use manual processes for that purpose. Even so, unsanctioned use of SaaS apps persists, most often because of lengthy approval processes or lack of employee awareness, according to the Report.

Compliance Audits

A majority of respondents conduct manual SaaS security compliance audits either regularly (30%) or on an ad hoc basis (22%), up from 21% and 14%, respectively, in 2024. Forty-three percent conduct continuous monitoring of SaaS regulatory compliance using a SaaS security posture management (SSPM) suite or other tools with similar capabilities, down from 57% in 2024.

Approximately half of respondents use point-in-time SaaS security compliance audits (52%). The rest either conduct audits on a regular basis (30%) and/or take an ad hoc approach (22%). Most respondents said their security administrators spend either two to five hours (45%) or five to eight hours (31%) per week on SaaS security matters. An additional 10% spend at least a full day on it.

More than one-third of respondents (38%) consolidate SSPM with security service edge (SSE) solutions. Approximately one-quarter:

• use an SSE solution;
• use a cloud access security broker; and/or
• monitor SaaS audit logs with in-app functionality, a security information and event management (SIEM) or another tool.

Just 13% of respondents use a standalone, purpose-built SSPM platform or equivalent. Of those respondents, 42% have a “dedicated, productized SSPM solution.” Additionally, nearly half of such respondents use an identity and access management solution, 44% rely on the built-in security features of their SaaS platforms and 41% rely on an SIEM tool.

Respondents cited threat detection (61%), SaaS app discovery and inventory (54%), and detecting unauthorized SaaS connections (52%) as the most important SSPM capabilities.

See “How to Select the Latest Cloud Security Tools and Platforms” (Aug. 21, 2024).

Concerns About AI and SaaS Cybersecurity

AI creates new opportunities for data exposure and other security breaches, notes the Report. Nearly two-thirds of respondents expect more discussion about AI-driven efficiencies in the coming months. More than half expect discussions concerning secure use of AI and mitigating AI-related risks.

Virtually all respondents (96%) expect SaaS cybersecurity to become more important in the next three years, including 72% who believe it will become one of the top three cybersecurity priorities. Consistent with that perspective, 82% of respondents said their organizations plan to increase cybersecurity spending in the coming year.

See “Six Steps for Improving Cloud Security From CSRB’s Report on Microsoft Intrusion” (Jun. 12, 2024).

Addressing SaaS Security Risks

The Report offers the following seven recommendations for addressing SaaS security challenges.

1) Expand Visibility

Security tools should enable an organization to enforce policy alignment, detect misconfigurations and provide context on security exposures. Organizations should prioritize securing the SaaS applications that hold the majority of their sensitive data.

See “Restricting Super Users and Zombie IDs to Increase Cloud Security” (Jul. 31, 2024).

2) Ensure Clear Ownership of SaaS Security Responsibility

Organizations should establish and document clear ownership of responsibility for SaaS security. They should also embed SaaS security into their incident response planning.

3) Implement Continuous Monitoring

Because SaaS environments are constantly changing, security gaps may develop between audits. Consequently, organizations should implement continuous monitoring of SaaS applications to identify issues as they emerge.

4) Prioritize Key Apps and Automate Monitoring

Organizations should prioritize securing apps that hold the most sensitive data. They can use AI and automation for continuous monitoring, which can reduce human error and free security teams to focus on “threat response, risk reduction and strategic alignment.”

See “Assessing and Managing AI’s Transformation of Cybersecurity in 2025” (Mar. 19, 2025).

5) Implement an SSPM Solution

SSE tools, which focus on network and systems access, were not designed for securing SaaS data or configurations, according to the Report. Consequently, organizations should consider dedicated SSPM solutions, which may include identity governance, threat monitoring and visibility into third-party integrations.

6) Trust, But Verify

Although most organizations trust their SaaS vendors, they should conduct routine assessments of app configurations, identity entitlements and external integrations.

See “Checklist for Framing and Assessing Third-Party Risk” (Aug. 16, 2023); and our two-part series on allocating risk in cloud computing relationships: “Spectrum of Offerings” (Dec. 4, 2019), and “Key Legal Issues” (Dec. 11, 2019).

7) Ensure Appropriate AI Governance

Organizations should apply to AI the same identity governance principles that they use in other applications. Thus, they should:

• inventory AI uses;
• implement least access privileges; and
• apply the same access controls and monitoring policies that apply to human users.

See “Benchmarking AI Governance Practices and Challenges” (May 7, 2025).

Prince Lobel has welcomed Joshua Cook as a partner in its data privacy and security practice group in Boston. He arrives from The Wagner Law Group.

Cook’s practice focuses on privacy, brand protection and emerging technologies such as AI, and includes negotiating complex technology and data contracts that integrate cybersecurity and privacy strategy into business objectives. With more than 20 years of legal experience, he has commanded dozens of critical cyber, privacy and fraud incidents, guiding C‑suites and boards through various crises such as data breaches, ransomware attacks, large-scale fraud investigations and government inquiries. He also has extensive experience advising IT officers, broker-dealers and data brokers concerning their regulatory compliance and risk management obligations.

Prior to joining Prince Lobel, Cook established and led The Wagner Law Group’s cybersecurity and privacy practice group. He also previously spent 12 years in-house at John Hancock, where he served as the company’s first global cyber counsel and launched its cybersecurity legal function.