A recent federal court decision offers important lessons for businesses that use cookies, pixels, and other tracking technologies on consumer-facing websites. Although the court dismissed one federal wiretap claim with leave to amend, it allowed other privacy claims to proceed, including claims under California’s pen register statute and common law intrusion upon seclusion.

The case involved allegations that a company’s website began collecting visitor data immediately upon a user landing on the site, before the user had a meaningful opportunity to reject non-essential cookies via a consent banner. The plaintiff alleged that, despite selecting “reject,” certain information had already been collected and transmitted to third parties, including browsing activity, website interactions, device information, session data, user identifiers, and geolocation data.

The court found that these allegations were sufficient, at the pleading stage, to establish a concrete privacy injury for damages. Importantly, the court emphasized that privacy harms may depend on the sensitivity and nature of the information collected. Browsing history, user interactions, identifiers, and location-related information may, in some instances, be enough to support standing when allegedly collected without consent.

The decision also highlights that a plaintiff’s status as a privacy “tester” does not automatically defeat standing. While courts may scrutinize whether a tester genuinely expected privacy and indeed have declined standing when a tester’s expectations that their information would be accessed, recorded, and disclosed are met, this court accepted the allegation that the user had expressly rejected non-essential tracking, which supported a reasonable expectation that tracking would not occur.

For businesses, the most practical lesson is that cookie consent tools must work as promised. A banner that allows users to reject non-essential cookies may create risk if tracking begins before a user has an opportunity to review the banner or make a selection, or if third-party technologies continue to operate despite a rejection. Businesses should not assume that having a banner alone is enough; they should test whether it is operating as intended or represented.

The decision also underscores the need to understand what data third-party tools collect. Courts are increasingly willing to consider whether website tracking technologies may fall within older privacy statutes, including laws originally written for telephone-era tracking devices. That means businesses should carefully evaluate pixels, analytics tags, advertising scripts, session replay tools, and related technologies.

If you have questions about web tracking and privacy issues for your business, contact a Jackson Lewis attorney to discuss.

Key Takeaways

  • Analyzes whether recording customer service and sales calls triggers the CCPA’s new risk assessment requirements.
  • Identifies the specific CCPA triggers most relevant to call recording, particularly when AI analytics are applied to recordings.
  • Notes related obligations under state wiretapping laws and other state privacy frameworks.

Recording customer calls is among the most common data collection practices in business. Contact centers, healthcare providers, financial services firms, and countless other industries record customer interactions for quality assurance, training, compliance, and dispute resolution. The familiar “this call may be recorded for quality and training purposes” disclosure has become almost reflexive. But with the CCPA’s new risk assessment requirements now in effect, businesses subject to the CCPA should revisit this practice—particularly where call recordings are analyzed using AI or used in ways that go beyond simple storage and retrieval.

Our earlier posts on CCPA risk assessment basics discuss when the CCPA risk assessment requirement applies and the general requirements for conducting and reporting a risk assessment. This post focuses specifically on the call recording context.

How Businesses Use Customer Call Recordings

At its most basic level, call recording captures audio of a conversation between a customer service representative and a customer, stores that recording, and makes it available for later playback. Many businesses, however, now use AI-powered speech analytics tools to extract additional value from those recordings. These tools can transcribe calls, identify topics discussed, detect customer sentiment and emotion, flag compliance concerns, score agent performance, and generate profiles of individual customers based on their communication patterns, expressed preferences, or emotional responses across multiple interactions.

It is this AI-enhanced use of call recordings—rather than simple storage—that raises the most significant, but not the only CCPA risk assessment questions.

CCPA Risk Assessment Triggers for Call Recording Programs

Businesses should evaluate at least the following potential risk assessment triggers in connection with their call recording programs:

Sensitive Personal Information. Call recordings frequently capture sensitive personal information. Under the CCPA, sensitive personal information means personal information that reveals information about a consumer, such as: SSN, driver’s license number, passport number, precise geolocation, racial or ethnic origin, citizenship or immigration status, religious or philosophical beliefs, union membership, genetic data, biometric information for the purpose of uniquely identifying a consumer, and information about a consumer’s sex life or sexual orientation. This is not an exhaustive list, but no doubt information that could be captured on a recorded line.

Customers who call healthcare providers, pharmacies, or health insurance companies for example, routinely disclose such information. But remember, the CCPA excludes certain categories of personal information including protected health information covered under the Health Insurance Portability and Accountability Act and medical information under the California Confidentiality of Medical Information Act. Importantly, not all health and medical information is covered under these laws, and could be covered by CCPA!

If a business uses voice biometrics—either to verify a caller’s identity or as part of a speaker analytics program that analyzes vocal patterns to identify individuals—it is processing biometric information, which is sensitive personal information under the CCPA. Even a speech analytics platform that generates a persistent voice profile of a customer may implicate this category. A risk assessment may be required for processing of that kind.

Systematic Observation. The CCPA risk assessment regulations require an assessment when businesses profile consumers through systematic observation. Automated processing of information obtained from call recordings could be used to infer or extrapolate a consumer’s intelligence, aptitude, performance at work, economic situation, behavior, location, etc. based upon systematic observation. When this occurs in connection with a consumer acting in their capacity as an educational program applicant, job applicant, student, employee, or independent contractor for the business, a risk assessment may be needed.

Automated Decision-Making. Where call recording analytics feed into automated systems that make significant decisions about consumers—such as creditworthiness determinations, insurance coverage decisions, or healthcare recommendations—the ADMT risk assessment trigger may be engaged.

State Wiretapping and Consent Laws

Separate from the CCPA risk assessment requirements, businesses recording customer calls must comply with state wiretapping and call recording consent laws. California’s Invasion of Privacy Act (CIPA) requires all-party consent for recording telephone calls. Several other states—including Florida, Illinois, Maryland, Massachusetts, Montana, New Hampshire, Pennsylvania, and Washington—also require all-party consent. Businesses that record calls involving customers in those states without proper consent face significant litigation exposure. The wiretapping consent requirement and the CCPA risk assessment obligation are independent—satisfying one does not satisfy the other.

What Businesses Should Do

Businesses that record customer calls should document the full lifecycle of those recordings: what is captured, where it is stored, how long it is retained, who can access it, and whether any AI or analytics tools are applied to the recordings. Where recordings capture sensitive personal information or are analyzed by AI to generate profiles or inform significant decisions about customers, a CCPA risk assessment should be considered by businesses covered under the CCPA.

For the procedural requirements of completing a risk assessment—including the required contents of the risk assessment report and the certification obligation to the CPPA—Part 2 of our risk assessment series provides the relevant guidance.

Employers are increasingly using artificial intelligence and other algorithmic tools to support workplace decisions, including recruiting, screening, interviewing, promotion, workforce planning, and performance management. These tools can improve efficiency and consistency, but they also introduce important compliance, reputational, and employee-relations considerations. Two concepts that often arise in AI governance are bias audits and validation testing. Although related, they serve different purposes.

A bias audit generally evaluates whether the use of a tool is associated with materially different outcomes across protected or demographic groups. Depending on the jurisdiction and the tool at issue, a bias audit may be legally required before use. For example, New York City’s automated employment decision tool law requires certain employers and employment agencies to obtain a bias audit within one year before using covered tools and to provide related notices and disclosures. And other states have laws that affect the need for bias testing or are considering such requirements. Even where no specific audit law applies, employers may decide that an audit is appropriate as part of responsible AI governance, particularly when a tool affects access to job opportunities or advancement.

Validation testing, by contrast, focuses on whether a selection procedure is job-related and appropriately measures what it is intended to measure. This concept is not new. The Uniform Guidelines on Employee Selection Procedures provide a long-standing framework for evaluating employment tests and other selection procedures used in employment decisions in compliance with Title VII of the Civil Rights Act. In the AI context, a validation study may be especially important where an algorithm ranks, scores, recommends, or screens individuals based on characteristics that are intended to predict job success. If an employer’s use of an AI tool is challenged, a validation study may be critically important to the employer’s defense.

As a general governance matter, employers should consider bias audits and/or validation testing before deploying an AI tool that materially influences employment decisions. They should also consider reassessment when the tool is modified, used for a new role or population, applied in a new jurisdiction, or when the employer’s own workforce or applicant data materially changes. Ongoing monitoring is critical because a tool that performs acceptably at one point in time may produce different results as business practices, labor markets, or applicant pools evolve.

The need for testing should be assessed early in the procurement process. Employers should ask vendors what the tool does, what data it uses, whether it has been audited or validated, what assumptions underlie the model, and what documentation is available. Employers should also avoid assuming that a vendor’s general statements about fairness, accuracy, or compliance are sufficient for the employer’s particular use case.

A practical AI governance program typically includes an inventory of AI-enabled employment tools, a risk-based review before deployment, appropriate legal and human resources oversight, documentation of decision-making, and periodic reevaluation.

If you have questions about AI governance for your business, contact a Jackson Lewis attorney to discuss.

State breach-notification laws continue to evolve, and legislatures are using 2026 sessions to tighten consumer protections and shift the civil liability landscape that often follows a cyber event.

For businesses, the practical takeaway is that incident response planning increasingly needs to account not only for “whether notice is required,” but also for hard timelines, regulator-facing deliverables, and the cost of consumer support services.

Several state laws have died without passing out of the legislature, including bills in Connecticut, Hawaii, and Oklahoma. However, we continue to watch two pending state laws on the East Coast.

New Jersey – Assembly Bill 1852

New Jersey’s pending proposal is more about standardizing notice practices and ensuring ongoing consumer access to credit reporting.

As introduced, the bill narrows permissible notice methods to written notice or electronic notice. It removes the existing substitute-notice pathway that many companies rely on when notice costs are high or when contact information is incomplete.

The proposal is also more prescriptive about content. It requires breach notices to include contact information, including a toll-free telephone number, of a customer representative of the business or public entity who shall be available to give the customer information on:

  • What information has been compromised, and potential consequences of the breach of security
  • How the company or public entity is addressing the breach
  • What steps the customer may take to safeguard their information, and
  • Notification that the customer has access to free credit reports

The toll-free telephone number would be a larger lift than most state breach notice requirements.

Beyond disclosure, the bill would impose a substantive consumer-support obligation: for six months after notification, the business or public entity must provide access to independent credit reports from a consumer reporting agency and pay the associated fees for the access cadence described in the bill.

Finally, the bill includes a cost-allocation provision under which a third party maintaining records on behalf of another entity would be responsible for reimbursing the principal for notification and credit-report access costs, which will be significant for businesses that outsource data processing.

New York – Senate Bill 3078

New York’s proposal is comparatively targeted, but it could have meaningful cost implications after incidents, especially for consumer-facing organizations. The bill would require that, when the notifying person or business was the source of the breach, the notice must include an offer of appropriate identity theft prevention and mitigation services at no cost for at least 12 months, along with the information necessary for the individual to accept the offer. If passed, New York would join several other states, including California, Connecticut, Delaware, Maryland, Pennsylvania, and the District of Columbia, that require such services.

In practice, businesses should expect that determining whether they were “the source” may require careful factual analysis in multi-party ecosystems, including vendor-hosted environments and shared platforms, and should consider establishing internal criteria for that determination.

Jackson Lewis will continue to track these and other pending legislation related to cybersecurity and data breaches. If you have questions about developing an incident response plan or related issues, contact a Jackson Lewis attorney to discuss.

Takeaways

Educational Institutions use Software as a Service platforms to facilitate operations, but doing so carries significant risk that needs to be carefully managed. Strong vendor oversight, tight contracts, and incident response planning are critical to protecting personal data down the chain.

Related links

Five Privacy Issues Higher Education Institutions Should Consider Monitoring

FAQs for Schools and Persons Affected By the PowerSchool Data Breach

An EdTech vendor whose platform is used by thousands of educational institutions recently experienced a significant cybersecurity incident impacting millions of students.  The incident left customers of the platform legally and reputationally exposed—and answering difficult questions in their local communities.  This incident is not unique and highlights the importance of vendor management to effective data protection programs.

  1. The Education Technology Sector Is a High-Value Target

Lesson: Educational institutions possess a wide range of data and have become trendy targets for attack.

Educational institutions maintain large volumes of personal data related to their students and their families, as well as their teachers and other employees. These troves of data—which may be subject to federal laws like The Family Educational Rights and Privacy Act (FERPA), as well as state reasonable safeguard and breach notification laws—have made educational institutions attractive marks for cyber attackers.  So too has their reputation for underinvesting in their data security programs.  

  1. Third‑Party Contractor≠ Reduced Liability

Lesson: Educational institutions remain legally and reputationally exposed even when their vendor stores data on their behalf.

While engaging a vendor can, in some ways, simplify the process of protecting data—because the vendor handles the logistics and incurs the costs of maintaining administrative, physical, and technical safeguards to secure that data—this is not a set it and forget it situation.  Even if the vendor stores all of the data at issue, the educational institution will be the party statutorily obligated to notify and report in the event of a breach and will likely be a defendant or subject of ensuing litigation or regulatory investigation. In other words, educational institutions can outsource the function of handling their data but cannot outsource the consequences if it’s handled improperly.

  1. The Scope of Data Covered by Data Protection Laws Is Broad

Lesson: Even breaches of less “sensitive” data create meaningful risk.

Reports indicate that the data accessed in the recent breach included names, email addresses, student IDs, and messages.  Although these data elements are less “sensitive” than SSNs, financial account information, or medical information, their breach may still trigger notification and reporting obligations under state data protection laws, like New York Education Law § 2-d.  Thus, educational institutions cannot safely assume that the disclosure of “lower risk” data eliminates legal or operational exposure.  Instead, they must conduct a thorough analysis of the incident and carefully assess resulting obligations.

  1. Operational Resilience is Necessary to Avoid Operational Disruption

Lesson: Operational disruption is a key privacy risk multiplier.

The breach occurred around final examinations for many educational institutions, disrupting students and educators alike.  It also forced operational staffs to rapidly navigate technological, availability, and continuity challenges. Operational resilience, like data backups and well-crafted and -rehearsed incident response plans, are essential to minimizing the harm caused by these incidents.

  1. Strong Risk Management Requires Continuous Vendor Monitoring

Lesson: Constant diligence is required.

Vetting vendors prior to engaging them is critical to an effective management program.  So too is carefully reviewing vendor agreements to ensure they include key data protection provisions.  But vendor management doesn’t end at the time of engagement.  Instead, it’s an ongoing process that should include, among other things, exercise of audit rights, monitoring of vendor subcontractors, and periodic revisiting of vendor agreements.  Use of vendors is unavoidable, as are vendor breaches.  Where educational institutions have control, though, and can mitigate risk, is through diligent oversight of those vendors.

***

For additional information about managing the vendors that manage your data, please contact Jackson Lewis’ Privacy, AI & Cybersecurity team.

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.