The governor of Alabama recently signed House Bill 351, which establishes a consumer data privacy law for the state. The law takes effect May 1, 2027.

To whom does the law apply?

The law applies to controllers that conduct business in Alabama or produce products or services targeted to Alabama residents, if they either:

(1) control or process the personal data of more than 25,000 consumers, excluding data processed solely to complete a payment transaction, or

(2) derive more than 25 percent of gross revenue from the sale of personal data. 

The Act does not apply to various entities, including political subdivisions and certain public bodies, institutions of higher education, certain securities associations, certain financial institutions and GLBA-regulated data, HIPAA covered entities and business associates, certain small businesses with fewer than 500 employees that do not sell personal data, certain nonprofits with fewer than 100 employees that do not sell personal data, certain regulated entities under specified Alabama statutes, certain political organizations and data sellers serving them, and certain electric providers. 

Who is protected by the law?

The law protects “consumers,” defined as individuals who are residents of Alabama. It excludes individuals acting in a commercial or employment context.

The law also specifically allows a parent or legal guardian to exercise rights on behalf of a known child, and a guardian or conservator to exercise rights on behalf of a consumer. 

What data is protected by the law?

The law protects “personal data,” defined as information that is linked or reasonably linkable to an identified or identifiable individual. It excludes deidentified data and publicly available information. 

The defines “sensitive data” to include: data revealing racial or ethnic origin, religious beliefs, a mental or physical health condition or diagnosis, information about an individual’s sex life, sexual orientation, or citizenship or immigration status; genetic or biometric data processed for uniquely identifying an individual; personal data collected from a known child; and precise geolocation data. 

What are the rights of consumers?

Under the law, consumers may require a controller to do the following:

  • Confirm whether the controller, processor, or third party acting on the controller’s behalf is processing the consumer’s personal data and access that data;
  • Correct inaccuracies;
  • Delete personal data;
  • Provide a portable and, where technically feasible, readily usable copy of personal data previously provided by the consumer; and
  • Allow the consumer to opt out of processing for targeted advertising, sale of personal data, and profiling in furtherance of solely automated significant decisions. 

A controller must respond to a consumer request within 45 days, subject to a possible 45-day extension when reasonably necessary and must explain if it declines to act. 

Controllers must allow opt-out requests through a clear and conspicuous link on the controller’s website to a webpage that enables the consumer directly to opt out of targeted advertising or the sale of personal data, or to provide up-to-date contact information for submitting the opt-out request. 

What obligations do controllers have?

Controllers must:

  • Limit collection of personal data to what is adequate, relevant, and reasonably necessary for the disclosed purposes;
  • Establish, implement, and maintain reasonable administrative, technical, and physical data security practices; and
  • Provide an effective mechanism for consumers to revoke consent that is at least as easy as the method used to provide consent. 

Controllers may not process personal data for purposes that are not reasonably necessary to or compatible with disclosed purposes, process sensitive data without consent (or, for known children, outside COPPA-compliant processing), process data in violation of discrimination laws, or process personal data for targeted advertising or sell personal data without consent where the controller has actual knowledge that the consumer is at least 13 and younger than 16. 

Controllers may not deny goods or services, charge different prices or rates, or provide a different level of quality because a consumer opted out, although the law allows certain loyalty and reward programs. 

Controllers must establish and describe in the privacy notice one or more secure and reliable means for consumers to submit requests to exercise their rights and may not require consumers to create a new account to do so, though they may require the use of an existing account. 

Controllers also have obligations regarding deidentified and pseudonymous data, including taking measures to ensure deidentified data cannot reasonably be associated with an individual, refraining from reidentifying deidentified data, contractually obligating recipients of deidentified data to comply with the statutory requirements, and exercising reasonable oversight over disclosures of pseudonymous or deidentified data.

How is the law enforced?

The Alabama Attorney General may enforce violations of the Act. 

Before initiating an action, the Attorney General must issue a notice of violation to the controller. If the controller fails to correct the violation within 45 days after receipt of the notice, the Attorney General may bring an action for an injunction.

If the court finds a violation and failure to cure, it may assess a civil penalty of up to $15,000 per violation. If the controller cures within the 45-day period and provides an express written statement that the violations have been corrected and will not recur, no action may be initiated. 

If you have questions about Alabama’s new privacy law or related issues, please reach out to a member of our Privacy, Data, and Cybersecurity practice group to discuss.

Key Takeaways

  • Examines how AI-driven hiring and applicant screening tools interact with the CCPA’s new risk assessment requirements.
  • Identifies the CCPA risk assessment triggers most likely to apply—including automated decision-making and systematic observation of applicants.

Artificial intelligence has made significant inroads into the hiring process. Employers increasingly rely on AI-driven tools to screen resumes, analyze video interviews, administer automated assessments, and score candidates against job-fit models. These tools promise greater efficiency and, in theory, more consistent evaluation. They also collect and generate a substantial amount of personal information about job applicants—information that, under the CCPA’s updated regulations, may require a formal risk assessment before or during use.

If your organization is a “business” under the CCPA and is using AI-powered hiring or applicant screening technology, the following analysis will help you evaluate whether a risk assessment is required. If you have not yet confirmed that the CCPA applies to your organization, check out our CCPA FAQs which address this and other provisions of the CCPA.

What AI Hiring Tools Typically Do

AI-powered hiring tools span a wide range of functions. Resume parsing and ranking tools use machine learning to score applications against predefined criteria. Video interview platforms analyze candidates’ facial expressions, word choice, and vocal patterns to generate personality or culture-fit assessments. Automated chatbots conduct initial screening interviews and assess responses. Skills assessment platforms measure cognitive ability, personality traits, and job-relevant competencies through adaptive tests scored by AI. Across all of these tools, the common thread is that personal information about applicants is being processed automatically to evaluate them and, directly or indirectly, to inform hiring decisions.

CCPA Risk Assessment Triggers for Hiring AI

The updated CCPA regulations identify several processing activities that require a risk assessment. Employers using AI hiring tools should evaluate whether any of the following apply:

Automated Decision-Making Technology (ADMT). A risk assessment is required when a business uses ADMT to make or contribute substantially to “significant decisions” about consumers. The regulations expressly identify employment opportunities and compensation among the categories of significant decisions. Accordingly, an AI tool that ranks, scores, advances, or eliminates applicants may be using ADMT to contribute to significant employment decisions—a straightforward risk assessment trigger. Employers should not assume that a human reviewer at the end of the process eliminates this obligation; the regulations focus on meaningful contribution to the decision, not exclusive AI control.

Systematic Observation of Applicants. The regulations also require a risk assessment when a business profiles a consumer through systematic observation when the individual is acting in the capacity of a “job applicant.” Systematic observation expressly includes “video or audio recording or live-streaming” and “technologies that enable physical or biological identification or profiling.” The more popular AI notetaking tools, or even AI video interviewing platforms that records candidates and/or analyzes their facial expressions and speech patterns may satisfy these elements.

Sensitive Personal Information. To the extent a hiring tool processes biometric information—such as voice patterns or facial geometry—as part of its analysis, that processing independently triggers a risk assessment as processing of “sensitive personal information.” Biometric information is expressly included in the CCPA’s definition of sensitive personal information, and employers should not assume the human resources exception is broad enough to cover biometric processing in the hiring context.

Training AI on Applicant Data. A risk assessment is also required when personal information is processed to train ADMT for significant decisions, or to train facial recognition or biometric technology. Employers that allow their hiring platform vendors to use applicant data to train or refine their models should evaluate whether this use independently triggers an assessment obligation.

Other State Law Considerations

Several states have enacted laws specifically targeting AI in hiring. Illinois’s Artificial Intelligence Video Interview Act imposes consent and anti-discrimination requirements for video interview AI. New York City’s Local Law 144 requires, among other things, bias audits for automated employment decision tools used by covered employers. Maryland prohibits facial recognition in pre-employment interviews without consent. Colorado recently replaced its AI law which includes obligations to provide consumers (including job applicants) notice prior to using automated decision making technology that will materially influence a consequential decision. To help manage and comply with this growing patchwork of AI regulation, businesses using AI hiring tools should map their tools against each of these requirements, which may operate independently of the CCPA.

Next Steps for Employers

Employers should catalog each AI hiring tool in their technology stack, document the personal information each collects and processes, and assess the functionalities of these tools, such as whether they are making or contributing to significant employment decisions, conducting systematic observation of applicants, or processing biometric or other sensitive personal information. Where any of those conditions are met, a CCPA risk assessment may be required.

Part 2 of our post on CCPA risk assessments details the procedural requirements for completing the assessment, including what the risk assessment report must contain and the obligation to certify the assessment to the CPPA. The assessment must weigh the risks to consumer privacy against the benefits of the processing—a genuine balancing exercise, not a formality.

Service providers often receive or access a customer’s personal information when performing contracted services. In the employment context, service providers may include payroll processors, Human Resource Information System (HRIS) or Applicant Tracking System (ATS) platforms, outsourced IT support, data storage, AI tool providers, or security services.

Under the EU and UK General Data Protection Regulations (GDPR), an employer (data controller) is required to execute a written data processing agreement (DPA) with a service provider (data processor) who will receive or access employee personal data. The DPA is intended to protect the rights of employees and ensure that service providers process their personal data in a compliant manner.

A GDPR DPA must contain a meaningful description of the processing activities (i.e., the subject matter and duration, nature and purpose, categories of personal data, and data subjects) and specific non-negotiable provisions. These mandated provisions include, for example:

  • processing solely on the data controller’s documented instructions,
  • data breach notification obligations,
  • restrictions on sub-processor engagement,
  • processor reasonable safeguards,
  • authorization for onward transfers of data,
  • assistance with data processing impact assessments and data subject access requests,
  • deletion or return of data, and
  • audit rights.

In addition, if an employer transfers employee personal data from the EU or UK to a service provider in a third country that lacks an “adequacy decision” (e.g., the U.S.) or permits the service provider to access employee personal data in the EU or UK from a third country, the parties must use an appropriate “transfer mechanism”. This may require appending the EU Standard Contractual Clauses (SCCs) or UK International Data Transfer Agreement (IDTA) to the DPA and completing a documented Transfer Impact Assessment.

While a GDPR DPA requires specific provisions, the employer may incorporate additional terms tailored to its interests. Common additions include indemnification provisions and limitations on liability for data-specific risks such as the processor’s material breach of the DPA, violation of applicable data protection law, or a personal data breach. The parties may negotiate the implementation terms for certain mandated provisions, such as the window for breach notification; the scope, frequency, and cost allocation of an audit; the manner for approving sub-processors; or whether personal data will be returned or deleted upon completion of the services. Although the DPA terms must require a processor to implement appropriate security measures to safeguard personal data, the GDPR is not prescriptive about specific measures. As a result, the employer should specify the required technical safeguards, as appropriate to the sensitivity of the employee’s personal data and the processing activity.

Despite containing required provisions, every DPA should be tailored to the specific processing activity, the nature and sensitivity of the personal data, and the employer’s risk exposure. Without this tailoring, a GDPR DPA may be non-compliant or create unnecessary risk for the employer and its personal data. To help manage this risk and prevent delays in the contracting process, employers can prepare and maintain a DPA template that reflects their interests and specific requirements and can be tailored to the processing activity.

If you have questions about drafting, reviewing, or negotiating a DPA – under the GDPR or another data protection framework – please feel free to contact the Jackson Lewis Privacy, AI & Cybersecurity team.

If 2025 was the year website-tracking claims became impossible to ignore, 2026 is the year those cases began to mature. Courts are looking beyond whether a pixel, cookie, chat tool, or session-replay script was present on a site. Instead, they are focusing more closely on what data was collected, when it was collected, what disclosures users saw, whether consent was meaningful, and whether individualized browsing activity can support class treatment. At the same time, appellate activity in video privacy cases is keeping pressure on publishers and other businesses that embed video content alongside common tracking tools.

One insight this year comes from a publisher case in the New York federal court, where the court allowed tracking claims to proceed past the pleading stage. The allegations were familiar ones: a website allegedly shared visitor information with outside advertising or analytics partners through embedded code, without meaningful consent. What made the ruling notable was the court’s willingness to let the plaintiff proceed on theories that the tracking setup operated like a modern pen register and that data points such as IP address and device-linked identifiers could be enough to survive dismissal. For companies defending these cases, that is a reminder that some courts are still prepared to apply older wiretap-style statutes to modern website architecture, even when the technology looks routine from an operational perspective.

A second insight cuts in a different direction. In a case in the California federal court, the court rejected an effort to treat ordinary website cookies as illegal “trap and trace” devices. That decision is significant because plaintiffs have increasingly tried to repackage conventional ad-tech or analytics tools as something more sinister under statutes that were not written with websites in mind (or before websites even existed). The court was not persuaded that the mere use of cookies plausibly fit that theory, and it dismissed the claim. The takeaway is not that these claims are disappearing. It is that defendants still have room to argue that courts should not stretch mid-century surveillance statutes to cover every digital signal exchanged during ordinary website use.

A third insight from 2026 is procedural rather than doctrinal: class certification remains a major pressure point. In a recent tracking case, a California federal court denied class certification because individualized statute-of-limitations issues threatened to overwhelm common questions. That matters. Website-tracking complaints are often drafted to sound uniform, but actual user experiences can vary widely depending on visit dates, browser settings, consent interactions, logged-in status, and the particular code running at a given time. Plaintiffs may still survive a motion to dismiss, but converting those allegations into a certifiable class is far from automatic. For defendants, 2026 is reinforcing a familiar but important point: even when merits arguments are mixed, class defenses can materially change the settlement posture and potential resolution of a case.

Video privacy claims are also evolving in 2026. In January, the Supreme Court granted review in a case that will address who qualifies as a “consumer” under the Video Privacy Protection Act (VPPA), a question that has become increasingly important in suits involving websites that offer video content alongside newsletters, accounts, or other non-video services. At the same time, lower courts in February continued to diverge on a separate issue: when disclosed information is specific enough to count as personally identifiable information in pixel-based VPPA cases. That means businesses with embedded videos should expect continued uncertainty, not less, at least until appellate guidance becomes more settled.

Taken together, the 2026 cases show a litigation environment that is becoming more nuanced. Some courts are still receptive to aggressive tracking theories. Others are pushing back on attempts to make every cookie or identifier into a statutory violation. Meanwhile, plaintiffs and defendants are increasingly fighting over consent mechanics, privacy language, and class structure rather than abstract debates about whether web tracking exists at all.

A recent Inc. article highlights an unsettling controversy involving Delve, a Y Combinator-backed compliance startup, and allegations that strike at the heart of how organizations rely on SOC (System and Organization Controls) 2 reports which evaluate an organization’s internal controls over security, availability, and privacy.

According to the report, a whistleblower investigation alleges that Delve generated fraudulent audit reports, fabricated evidence of controls, and created the appearance of compliance for hundreds of customers. Delve has disputed aspects of these claims, and the situation is still unfolding. Regardless of the ultimate outcome, the incident offers an important—and uncomfortable—lesson for organizations that rely on SOC 2 reports as part of vendor due diligence.

Hopefully Not the Norm…

Let’s start with an important point: there is no way to tell how widespread these practices exist in the vendor management space. We suspect the allegations are not the norm. The SOC framework, when properly executed, remains a widely trusted and valuable tool as part of the process for assessing controls.

But “not the norm” is not the same as “impossible,” and there indeed may be critical and material gaps not adequately addressed in SOC 2 reports either by design or inadvertence. When managing cybersecurity risks—particularly where third-party vendors are involved—low probability events can still carry high impact consequences.

What the Allegations Reveal About Systemic Risk

The Delve situation, at its core, is not just about one company. It exposes structural weaknesses in how SOC 2 reports are often consumed:

  • Organizations may accept reports without scrutinizing scope or methodology.
  • Procurement teams may prioritize speed of certification over rigor and cost, particularly when correlated with a vendor that has a strong reputation or “must know what they are doing!”
  • Stakeholders may assume that a SOC 2 report equals real-time security assurance.

So, while organizations may have difficulty assessing a SOC 2 or similar report on its face, there are reasonable steps organizations can and should be taking to probe the representations in such reports. That effort, again, can and should correspond to the risk the vendor presents to the organization, a determination based on several factors, including the nature and volume of the data processed.

Key Questions Organizations Should Be Asking

Organizations need to shift from passive receipt to active evaluation of SOC 2 reports. These reports should trigger questions including:

  • What is actually in scope?
    Are the systems and services you depend on covered in the report—or carved out?
  • When did the testing occur?
    How stale is the observation period relative to current operations?
  • What has changed since the report was issued?
    New infrastructure, new security team, new vendors, new risks?
  • How independent was the audit?
    Who performed it—and did they have any evident conflicts of interest?
  • Do the findings make sense?
    “Zero incidents” across dozens (or hundreds) of organizations should invite scrutiny, or at least curiosity, not comfort.
  • What ongoing assurance exists?
    Is there continuous monitoring—or just a static document?

These are not theoretical concerns. As some observers have noted, if compliance attestations are flawed, liability may ultimately sit with the organizations that relied on them.  

We recently explored many of these themes on our We Get Privacy podcast –
Moving Beyond Checkbox Diligence with SOC Reports – joined by Eric Ratcliffe of 360 Advanced, an auditing firm that performs SOC 2 audits. One of the key takeaways: SOC 2 reports must be interpreted, not simply collected.

In a world of automation and AI-enabled compliance tooling, the temptation is to move faster—to treat certification as a milestone rather than a process. The Delve allegations suggest that mindset can create blind spots.

The ERISA Angle: Fiduciary Duty Still Applies

For ERISA plan fiduciaries, the implications are even more direct. The duty of prudence may require more than obtaining a SOC 2 report. Plan fiduciaries should be evaluating:

  • what the report actually covers,
  • whether controls align with plan risks,
  • gaps and inconsistencies, and
  • ongoing monitoring of risks to plan data, not one-time diligence.

Simply collecting a SOC 2 report—without evaluating its substance—may not satisfy that obligation of prudence.

The Bottom Line

SOC 2 reports remain an important tool. But they are just that—a tool.

The Delve incident is a reminder that:

  • A SOC 2 report is a point-in-time snapshot, not a guarantee
  • Not all reports are created equal
  • And most importantly, trust without verification is not risk management

Organizations should not abandon SOC 2 reports—but they should stop treating them as the finish line. Instead, they should be the beginning of a deeper conversation about risk, controls, and accountability.

When assisting businesses with the commercial aspects of the California Consumer Privacy Act, we advise them that this same law, with “consumer” in its name, also applies to data related to job applicants, employees, contractors, and other California state residents. Some are surprised, but we get to work addressing some nuanced issues, as some CCPA provisions do not neatly fit the employment relationship.

Fortunately, last month, the California Privacy Protection Agency (CPPA) issued an invitation for preliminary comments on potential updates to CCPA regulations addressing notices and disclosures and the handling of employee data. So, if you have questions or concerns about the CCPA’s application to employment information, you can submit that feedback by May 20.

The CPPA is considering whether to amend existing regulations or adopt new rules governing privacy notices (e.g., privacy policies, notices at collection, and rights notices) and their application to workforce data.  In short, the CPPA is seeking stakeholder input on both consumer-facing disclosures and employment lifecycle data practices, including hiring, active employment, and offboarding. Notably, the agency is offering this opportunity not only to businesses, but also to employees, applicants, and other consumers.

Key Areas for Consideration

Employee Notice Timing and Delivery: The CPPA asks when and how employees receive notices (e.g., at hiring, during employment, or at offboarding), highlighting uncertainty around optimal timing and format for workforce-specific disclosures.

Application of CCPA Rights in the Employment Context: The CPPA also is seeking input on a pain point for employers, namely managing the exercise of consumer rights under the CCPA. This includes questions about applicant and employees’ experiences exercising access, deletion, or correction rights suggesting a need for clearer rules on scope, verification, and operational workflows for HR data. An example of one question:

Have you exercised your CCPA rights as a job applicant or employee?

a. Describe your experience exercising your rights.

b. Describe any challenges you experienced when exercising your rights.

c. Do you have any suggestions on how to improve the experience?

In some cases, employers face challenges with the nature, scope, and purpose of such consumer rights requests from applicants and employees (including former employees as well as independent contractors).

Oversight of Service Providers and Contractors: The CPPA is probing how businesses monitor vendors’ compliance (e.g., audits, testing), indicating potential future guidance on accountability frameworks and due diligence expectations in the employment data ecosystem.

As noted, the CPPA is accepting preliminary comments through May 20, 2026, and feedback at this stage may shape future proposed regulations. Contact us if you would like to discuss how these developments may impact your organization or are interested in submitting comments to help shape the regulatory process to address your business needs.

Every so often a law that was passed years ago quietly becomes a present-day compliance reality. Section 24220 of the 2021 Infrastructure Investment and Jobs Act is one of those laws. Tucked into an eleven-hundred-page infrastructure bill with little public debate, the “kill switch law” as it has come to be known by some, awaits implementing regulations. The law has triggered debates in Congress seeking to defund the law, as well as lots of hand wringing around privacy and data governance questions that businesses, fleet operators, and their legal counsel are trying to answer before the technology becomes standard equipment in new vehicles.

What the Law Actually Requires

Section 24220 directs the National Highway Traffic Safety Administration (NHTSA) to require that all new passenger vehicles be equipped with what the statute calls “advanced drunk and impaired driving prevention technology.” In practical terms, the law contemplates two types of systems:

  • A passive performance-monitoring system that continuously observes a driver’s behavior and restricts or prevents vehicle operation if the system determines the driver may be impaired; or
  • A blood-alcohol detection system that prevents or limits operation when BAC meets or exceeds the legal limit of 0.08%.

Manufacturers can deploy either type, or a combination. The technology could involve cameras monitoring eye movement, sensors analyzing steering and braking patterns, or touch-based biometric readers built into the steering wheel or ignition surface. It also could leverage AI. NHTSA is still finalizing the technical standards — a detail that matters, because the specific data collection methods will drive (no pun intended) privacy and security compliance. Notably, many of these features and capabilities – often embedded in devices referred to as “dashcams” – have already become popular in fleet vehicles.

The January 2026 Vote — and What It Means That It Failed

Earlier this year, Representative Thomas Massie introduced an amendment to a budget bill that would have defunded Section 24220 entirely, blocking NHTSA from spending any funds on implementation or enforcement. The amendment failed 229–201, with 57 Republicans joining 211 Democrats in opposition. Repeal legislation (the No Kill Switches in Cars Act, H.R. 1137) remains stalled. Barring an unexpected reversal, the mandate goes forward.

Why Privacy Lawyers Are Paying Attention

Despite concerns about “Big Brother” and references to Orwell’s novel, 1984, the statute does not give the government a remote kill switch. No federal agency can log into your vehicle and disable it. The technology would operate through onboard software, and the decision to restrict operation is made by the vehicle’s own algorithms — not by a government operator.

That distinction is real and legally significant. But it does not exhaust the privacy concerns, not by a long shot. A decision is still being made other than by the driver to restrict operation of the vehicle.

Whether the system uses cameras, eye-tracking, biometrics, or driving pattern analysis, it is continuously collecting sensitive behavioral and physiological data about the driver. It is generated, stored — somewhere — and potentially transmitted. To whom? Under what retention schedule? With what security controls? The statute is silent. NHTSA’s rules are not yet final. The answers will depend heavily on what manufacturers build and what their privacy policies and terms of service say.

Additionally, new vehicles are networked, able to connect to manufacturer cloud infrastructure, and many connect to insurers, fleet management platforms, and dealership service systems. An open question raised during the funding debate, could insurance companies or law enforcement access impairment event data without the driver’s knowledge or a warrant. The Fourth Amendment analysis in that context is genuinely unsettled.

Beyond privacy concerns, some have raised the potential for fleet-wide attacks:

Unlike traditional vehicle theft or individual hacks, networked kill switch systems create the potential for mass-casualty cyberattacks. Research from Georgia Tech has modeled scenarios where:

Simultaneously activating kill switches on millions of vehicles could shut down entire transportation networks- Supply chain disruptions from disabled commercial vehicles could affect food, fuel, and medical supply delivery- A Consumer Watchdog report estimated a fleet-wide hack could cause approximately 3,000 deaths from a single coordinated breach.

The “kill switch jail” problem.

The statute contains no provision defining how a driver challenges or overrides a lockout once the system flags impairment. There is no appeal mechanism, no defined waiting period, no human review. A false positive — a sober driver whose steering pattern triggers the algorithm — could leave that person stranded with no clear recourse, raising significant liability, worker safety, and consumer protection concerns.

The fleet and employer liability problem.

Businesses that operate vehicle fleets — delivery companies, field services organizations, transportation providers — will have vehicles generating continuous data streams about their drivers, raising employment privacy considerations: What does the employer know? When do they know it? What state monitoring disclosure obligations apply? Will the technology trigger policy and consent obligations, such as in states with strong biometric privacy laws? Are risk assessments required?

What Businesses Can Be Doing Now

As the NHTSA continues its work on implementing regulations, a few action items worth considering:

  • If your organization currently leverages similar technology in vehicles used in the business, take a look at Dashcams: There’s More Risk To Manage Than You’d Expect.
  • Fleet operators should assess what data their vehicle management agreements and manufacturer privacy policies say about impairment event data — specifically who receives it, how long it is retained, and under what circumstances it is disclosed to third parties including law enforcement. Existing driver monitoring policies may need to be reviewed and updated.
  • HR and employment counsel should evaluate whether the passive monitoring and biometric data components of compliant vehicles trigger state-level employee monitoring notification laws (several states require advance notice before monitoring employees’ electronic activity) or biometric data statutes like Illinois BIPA. The analysis will vary by jurisdiction, but the risk of inaction is higher in states with private rights of action.
  • Privacy program managers should flag newly acquired vehicles as a data asset in enterprise data inventories. Vehicle-generated data — particularly behavioral and biometric data about identified individuals — may fall within the scope of state consumer privacy laws depending on how it is collected, processed, and shared.
  • Risk and compliance teams should watch NHTSA’s rulemaking closely. The final technical standards will determine which specific data elements are collected and by what methods.

The Broader Trend

Section 24220 is not an isolated development. It reflects a broader pattern of embedded sensors and passive monitoring becoming standard infrastructure in physical environments — vehicles, workplaces, commercial buildings — generating continuous data streams about individuals going about their ordinary daily activities. The challenge, which legislatures and regulators, and businesses, are only beginning to confront, is how to govern systems that never stop collecting.

The U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) recently announced a HIPAA enforcement action against an employer-sponsored group health plan. The action resulted in a payment to HHS of $245,000 and a two-year corrective action plan. While HIPAA enforcement is common in the healthcare sector, actions directly against employer-sponsored group health plans are not as common. This case, coupled with DOL guidance for ERISA fiduciaries concerning cybersecurity, underscores a growing regulatory focus not only on traditional healthcare entities, but also on the plans and ecosystems maintained by employers under ERISA.

Check out the full post in our Benefits Law Advisor.

In recent years, many organizations have installed dashcams in their vehicles to improve safety and compliance, reduce costs, and better understand what’s happening in the field.  Dashcams can be extremely useful for these purposes, giving organizations visibility into risky driver behaviors and misuse of company property.  They can also lower insurance costs and provide valuable evidence in litigation.  To provide these benefits, though, dashcams collect a lot of data—including data organizations didn’t intend to collect and/or that triggers legal obligations they didn’t intend to assume.

Why Organizations Are Using Dashcams

Dashcams serve a number of functions.  For example:

  1. Their use can lower insurance costs.  The video and audio recordings dashcams collect can help favorably resolve disputes and their AI-powered driver behavior monitoring capabilities can help flag risky activity before it results in costly incidents. 
  1. Dashcams can also help organizations monitor compliance with internal policies (e.g., no phone use while driving) and external requirements (e.g., hours-of-service rules in regulated industries).  They also create a record that can be useful in audits or investigations.
  1. When accidents occur, dashcam footage can help clarify fault, rebut inaccurate claims, and, in some cases, prevent litigation altogether or significantly reduce exposure.
  1. Many dashcams now incorporate AI tools that evaluate driver behavior and generate performance scores.  For some organizations, this information influences coaching, discipline, promotion, and compensation decisions. 

The Risks Dashcams Pose

To deliver these benefits, dashcams collect and process significant volumes of data, the management of which can be challenging.  For instance:

  1. In certain jurisdictions, prior consent is required to audio record communications.  Organizations that deploy dashcams without a clear process for obtaining and documenting consent may find themselves out of compliance.
  1. Some dashcams use facial recognition or similar technologies to identify drivers or monitor attentiveness.  Collection of this data can trigger notice and consent obligations—e.g. in California, Colorado, Illinois, and Texas—as well as obligations to maintain reasonable safeguards to protect the data from unauthorized access or acquisition.
  1. Dashcams capture extraneous information, such as employees’ discussions about medical conditions, religious beliefs, sexual orientation, or legal off-duty activities (like drinking or gambling), or the fact that, while using the vehicle, they visited their doctor or attended their AA meeting.  Collection of this information can complicate employment decisions—e.g., by imputing to an employer knowledge of an employee’s protected characteristics—and heighten the risk of invasion of privacy claims.
  1. Dashcams increasingly use AI to evaluate driver behavior or generate performance metrics.  In certain jurisdictions (e.g., California, Colorado, Illinois, New York City), the use of AI-generated performance data may trigger notification, risk assessment, and other compliance requirements. 
  1. Dashcams are typically deployed and managed by third-party vendors, which means the data they collect is often processed outside the employer’s information systems.  Nevertheless, the employer remains responsible for the protection and proper handling of that data.  If the vendor experiences a breach, or misuses the data, impacted employees and/or regulators will likely seek to hold the employer—not just the vendor—accountable.   

How To Manage Dashcam Risk

For many organizations, dashcams are a major value add.  And the good news is that the risks their use presents—though significant—are manageable, provided you have a solid program in place to do so.

Below are some practical steps to consider:

✔ Inventory Your Technology

  • Identify what dashcams are in use across the organization
  • Understand what features are enabled (e.g., video, audio, AI, facial recognition, geolocation tracking, etc.)
  • Confirm the approved use cases

✔ Map the Data

  • What data is being collected?
  • Where is it stored (including vendor environments)?
  • Who has access to it, both internally and externally?
  • How long is it retained?

✔ Address Notice and Consent Requirements

  • Implement clear notice to drivers and passengers
  • Obtain consent where required (e.g., before recording audio or colleting biometric data)

✔ Review AI Use

  • Determine whether AI is being used to evaluate employees
  • Assess whether applicable AI laws impose additional obligations
  • Confirm that outputs are being used appropriately in employment decisions

✔ Update Policies and Training

  • Develop or revise policies addressing dashcam use
  • Train employees on what is being collected and why
  • Provide guidance on appropriate use of company vehicles and equipment

✔ Minimize Data Collection and Retention

  • Disable unnecessary features (e.g., audio, facial recognition) where possible
  • Limit retention periods to what is actually needed
  • Avoid collecting data “just in case it’s useful at some point”

✔ Manage Vendor Risk

  • Conduct diligence on dashcam vendors’ privacy and security practices
  • Confirm where and how data is stored, processed, and transmitted
  • Understand whether the vendor uses data for product improvement, AI training, or other secondary purposes
  • Put clear contractual restrictions in place governing data use, retention, disclosure, breach notification, and risk allocation
  • Require appropriate security controls (e.g., encryption, access controls, incident response obligations)
  • Periodically reassess vendors to confirm ongoing compliance

A putative class action filed in December 2025 in the U.S. District Court for the Central District of Illinois offers a reminder that AI meeting assistant and transcription tools potentially carry significant legal exposure when organizations deploy them without appropriate governance guardrails in place. It also serves as a reminder to apply strong governance principles when evaluating and deploying these and similar technologies.

What the Fireflies.AI Complaint Alleges

The plaintiff in Cruz v. Fireflies.AI Corp., No. 3:25-cv-03399 (C.D. Ill.), alleges that she participated in a virtual meeting hosted by an Illinois nonprofit organization that had enabled Fireflies.ai — a popular AI meeting assistant that automatically joins Zoom, Microsoft Teams, and Google Meet sessions to record, transcribe, and analyze conversations. She alleges she never created a Fireflies account, never agreed to its Terms of Service, and never provided any written consent authorizing the collection of her biometric data.

Several states, most notably Illinois (under its Biometric Information Privacy Act (“BIPA”), regulate the collection and processing of biometric identifiers and information, creating significant compliance and litigation risk. Check out our summary of that regulation. 

The crux of the BIPA claims is straightforward: Fireflies’ “Speaker Recognition” feature, marketed as able to identify different speakers in meetings and audio files, necessarily generates voiceprints — biometric identifiers expressly covered by BIPA. The complaint alleges Fireflies violated BIPA in three distinct respects:

  1. failing to maintain and publicly publish a retention schedule and destruction policy for biometric data;
  2. failing to inform participants in writing that voiceprints were being collected, or of the purpose and duration of that collection; and
  3. collecting voiceprints without obtaining a written release from participants — including non-account holders who were simply present in recorded meetings.

The plaintiff seeks statutory damages of $1,000 per negligent violation and $5,000 per reckless or intentional violation, plus attorneys’ fees and injunctive relief.

Why This Matters For and Well Beyond the Fireflies Litigation

In the case of AI meeting and transcription tools, consider the following use cases along with the potential legal and other risks if, in fact, the tools are capturing biometric information:

  • Trainings. When multiple employees use the same workstation or conference room to join trainings using an AI transcription tool, voiceprints of each participant may be captured. Unless each individual has provided written consent, exposure compounds with each meeting and each attendee.
  • Witness and investigation interviews. HR professionals and corporate investigators increasingly use AI transcription tools to document and summarize interviews.
  • Applicant interviews. Talent acquisition teams using AI notetakers during candidate interviews may be capturing the voiceprints of applicants who are unlikely to have been informed their biometric data is being processed.
  • Patient and client encounters. Healthcare providers and other licensed medical professionals using AI transcription in clinical or counseling settings face layered risk — HIPAA, state privacy laws, and where applicable, biometric information protections.

Even beyond meeting assistant and transcription tools, as similar technologies are embedded into a myriad of devices and applications, questions about the collection of biometric information arise. Examples include performance management platforms and AI glasses, both of which can capture and record audio and video.

Clearly, the allegations in Cruz highlight a risk that extends far beyond any one technology, one use case, or the law in one state. AI meeting and transcription tools, like many emerging technologies, potentially can provide substantial productivity and other benefits to an organization. Compelling evidence of this is the rapid implementation and deployment for a wide range of use cases. Whether biometric identifiers or information are collected by Fireflies.AI remains to be seen. What we do know is rolling out technology without appropriate due diligence can expose an organization to significant compliance and litigation risk.

Governance Takeaways

  1. Adopt a team approach to due diligence. The data privacy and security challenges presented by complex and easily adaptable technologies cannot be solved by the IT department alone. Technology safeguards are critical, but they do not replace strong administrative, physical, and organizational controls, nor do they address the nuances certain applications bring. Organization executives, legal counsel, HR professionals, risk, and other key stakeholders should be at the table to ensure the right questions are being asked.
  2. Know your legal and contractual limitations, and the various ways they could apply. An organization’s compliance team need not and should not be comprised solely of lawyers. But it should maintain a keen awareness of the various legal and contractual limitations on the use of certain technologies, and their potential use cases.  
  3. Change management. It is increasingly common to vet and deploy a technology for one application, only to discover that it can easily address a number of other unrelated problems. Or, the vendor developing the technology significantly expands its functionality, which could be very beneficial to the organization beyond its current use. Will those pursuing the additional use cases or functionalities reopen the due diligence analysis? They should.
  4. Write it down. Even if the organization is checking off items 1-3 above, building some structure around the process can help to ensure it is ongoing and consistent.