Skip to main content

Received a CIPA Demand Letter? How to Verify Website Tracking Evidence Before the Site Changes

Receiving a CIPA demand letter can create immediate pressure to remove a pixel, disable analytics, change a cookie banner, call the developer, or start debating whether the allegation is legally valid.

Before technical changes make the current website state harder to reproduce, there is another question worth answering:

What did the website actually do during the type of session described in the allegation?

That question is narrower than determining whether the California Invasion of Privacy Act, commonly referred to as CIPA, was violated.

Finding a tracking technology does not automatically establish that it executed during the relevant session. Execution does not by itself establish what network requests occurred. A request occurring does not, by itself, establish exactly what information was transmitted or how that information should be characterized legally.

For businesses and counsel reviewing website-tracking allegations, the technical priority is therefore often to create a reproducible record of observable website behavior and preserve the evidence needed for qualified legal review.

This guide explains how that process can work and how a matter-specific technical investigation differs from relying only on a generic website scanner.

By Auditzo Updated October 01, 2026

October 2026 update: California Governor Gavin Newsom approved SB 690 on September 30, 2026. The measure amends Penal Code Section 637.2 by limiting who may bring an action under that section against a private actor for an alleged Section 638.51 violation arising from conduct on an internet website, online application, or mobile application. The bill does not amend Section 631. Because SB 690 is a non-urgency regular-session measure and does not specify a later operative date, the amendment is expected to take effect on January 1, 2027 under California's general effective-date rule. Existing matters should be evaluated by qualified counsel in light of the enacted text, including its retroactivity provision.

Technical scope note: Auditzo provides technical website evidence and remediation-oriented observations. We do not provide legal advice, determine whether CIPA has been violated, certify legal compliance, calculate legal exposure, or predict litigation outcomes. You can review our audit scope and limitations for additional context.


Received a CIPA Demand Letter Today? Start Here

If a CIPA or website-tracking demand letter has just arrived, the first few actions do not require deciding whether the allegations are right or wrong.

1. Preserve the letter and everything that came with it

Keep the original correspondence and any supporting material, including:

  • screenshots
  • HAR files
  • videos or screen recordings
  • request logs
  • technical reports
  • URLs
  • timestamps
  • cookie records
  • tracker lists
  • testing notes
  • supporting exhibits or attachments

Do not treat those materials as conclusive merely because they were included with the demand letter. They represent evidence or interpretations supplied by another party and can be technically reviewed.

2. Identify deadlines and route the matter to qualified counsel

A technical auditor should not advise a business whether to respond, settle, litigate, ignore a letter, or make a legal admission.

Those are legal decisions.

Counsel can determine what deadlines matter, what preservation obligations may exist, which legal theories are being asserted, and how technical evidence collection should fit into the overall response.

If counsel requires a deeper examination of the website's behavior, Auditzo provides technical website evidence support for law firms and legal teams.

3. Avoid undocumented website changes where preservation is relevant

There may be legitimate reasons to modify a website immediately, particularly for security, privacy, operational, or business reasons.

However, when a tracking allegation concerns the website's existing behavior, changing Google Tag Manager, a consent management platform, a pixel, analytics configuration, plugins, tracking rules, or third-party scripts without documenting the prior state can make later reproduction more difficult.

Where appropriate and under the direction of counsel, preservation and remediation should be treated as separate activities.

For a deeper treatment of this topic, see our Website Tracking Evidence Preservation Guide for Legal Review.

4. Identify exactly what the demand letter alleges

Do not begin with a broad instruction such as "scan the entire website for CIPA violations."

A better starting question is:

What does this particular letter claim happened?

5. Translate each allegation into a testable technical question

This is where a useful technical investigation begins.


What Is a CIPA Demand Letter?

A CIPA demand letter is generally correspondence alleging that website or application activity may implicate the California Invasion of Privacy Act and requesting some form of response, remediation, payment, preservation, or other action.

The precise statutory theory matters.

For example, California Penal Code Section 631 addresses specified conduct involving unauthorized connections and obtaining the contents or meaning of communications while in transit.

Sections 638.50 and 638.51 separately address statutory definitions and restrictions involving pen registers and trap-and-trace devices. Section 638.50 uses concepts involving dialing, routing, addressing, or signaling information and distinguishes those concepts from the contents of a communication.

That distinction is important for technical work.

A Section 631-oriented allegation and a Section 638.51 pen-register allegation can involve overlapping technologies while still raising different technical questions.

The demand letter should therefore help drive the technical scope of the investigation.

For more background on this specific technical area, review Auditzo's CIPA Section 638.51 website tracking assessment and our CIPA website tracking audit checklist.

Is a CIPA Demand Letter the Same as a Lawsuit?

No.

A demand letter and a filed lawsuit are different procedural situations.

A demand letter is correspondence asserting a claim or legal position. A filed complaint, summons, or other court document can create different procedural obligations and deadlines.

If you are unsure what you received, qualified counsel should review the documents promptly.

From Auditzo's technical perspective, the task remains narrower:

  • identify the technical allegations
  • preserve relevant evidence
  • reproduce what can reasonably be tested
  • separate observation from inference
  • provide traceable technical findings for counsel

Start With the Allegation, Not the Scanner

This is one of the most important principles in a CIPA demand-letter investigation.

A generic scanner can identify technologies, cookies, requests, scripts, or other technical signals.

It cannot automatically answer every question raised by a specific allegation.

CIPA demand letter workflow translating allegations into technical questions, evidence, and findings
A matter-specific review starts with the allegation, turns it into a testable technical question, and connects the answer to supporting evidence.

Examples of how an allegation can be translated into technical questions:

Example Allegation Technical Questions Worth Investigating
Meta Pixel transmitted visitor information Did the pixel load and execute? Which requests occurred? Which endpoints received them? What observable parameters were included? When did the request occur and what consent state existed?
Search text entered by a visitor was sent to a third party What interaction occurred? Which request followed it? Did the test value appear in a URL, query parameter, request body, event parameter, header, or another observable location?
Session replay captured user activity Did the replay technology load? Which event requests were generated? Which interactions triggered them? What browser-side data was observable? Were masking or exclusion behaviors technically observable?
Tracking occurred before consent Which requests occurred during a clean initial state? What changed after Accept? What changed after Reject or Decline? Did cookies or browser storage differ?
A third-party script collected identifying information Was the script merely present or did it execute? What network communications followed? Which observable values were included and where were they sent?

This approach is different from running a scanner and treating every detected technology as a conclusion.

For legal teams seeking deeper examples of evidence structure, see our guide to a CIPA tracking evidence report for law firms.


Preserve the Current Website State Before It Becomes Historical Evidence

Modern websites change constantly.

A tag-manager container can be republished. A consent rule can change. A marketing pixel can be removed. A plugin can update. A developer can change a script. A third-party vendor can modify its own technology.

Once that happens, a new audit may accurately document the website as it exists today while no longer reproducing the earlier state described by the demand letter.

Depending on the scope and available systems, potentially relevant evidence can include:

  • HAR and browser network captures
  • timestamped screenshots
  • screen recordings where appropriate
  • cookies
  • localStorage and sessionStorage
  • Google Tag Manager or similar container versions
  • consent-management platform configurations
  • available consent logs
  • deployment history
  • application or plugin versions
  • relevant server or CDN logs
  • third-party integration settings
  • historical consent or privacy configuration
  • technical evidence supplied with the demand letter

Not every matter requires every artifact.

The evidence scope should remain proportional to the allegation and, for legal matters, should be coordinated with counsel.

Auditzo's Evidence Handling and Data Retention page explains additional considerations around technical evidence and scoped artifacts.


Step 1: Define the Test Environment

A technical finding becomes more useful when another reviewer can understand how it was produced.

Record relevant context such as:

  • date and time
  • tested URL
  • browser and browser version
  • operating environment
  • approximate testing region where relevant
  • viewport or device where relevant
  • logged-in or logged-out state
  • clean or returning session
  • prior cookie and storage state
  • consent state
  • interaction performed

Website behavior can vary based on geography, browser state, previous consent, returning-visitor status, campaign configuration, A/B testing, login state, ad blockers, tag-manager rules, and other factors.

A screenshot stating that a tracker was detected is therefore much less informative than an observation tied to a defined session and supporting evidence.

Step 2: Capture the Initial Page State

Before clicking Accept, Reject, Decline, or another consent choice, observe the page as it initially loads.

Relevant questions may include:

  • Does a consent interface appear?
  • Which third-party domains receive requests?
  • Which scripts initialize?
  • Which cookies appear?
  • What is written to browser storage?
  • Do analytics, advertising, chat, session-replay, or other services contact external endpoints?
  • At what point in the session do those requests occur?

This creates a technical baseline for the initial state.

Where a website presents consent choices and those choices are relevant to the allegation, test the states separately.

Comparison of website tracking behavior during initial visit, consent acceptance, and consent rejection
Consent review is behavioral: compare requests, cookies, storage, and script activity across initial, Accept, and Reject states.

Initial state

Observe the website before the visitor has made a consent choice.

Accept state

Run a clean session and accept the available consent options that are relevant to the test.

Reject or decline state

Run another clean session and reject optional tracking where that choice exists.

GPC state, where relevant

If Global Privacy Control (GPC) is relevant to the website, jurisdiction, allegation, or agreed scope, run a separate clean session with the GPC signal enabled and without manually accepting or rejecting the banner first.

Document whether the signal is observable in the browser environment, whether the consent platform or site responds to it, and whether relevant requests, cookies, storage, or scripts behave differently from the comparable GPC-off state.

Then compare observable behavior across the sessions:

  • network requests
  • third-party endpoint domains
  • script activity
  • cookies
  • localStorage
  • sessionStorage
  • request timing
  • relevant event parameters

The important question is not simply whether a cookie banner is visible.

The more useful technical question is whether observable website behavior corresponds with the visitor's choice.

For related analysis, see our cookie consent audit methodology for ecommerce websites, which also illustrates why consent-state behavior matters beyond the visual presence of a banner.


Step 4: Examine Network-Level Evidence

For many website-tracking allegations, browser network activity is one of the most valuable sources of technical evidence.

Depending on the scope, a network capture may help establish:

  • whether a request occurred
  • the destination endpoint or domain
  • approximate timing
  • HTTP method
  • request URL
  • selected query parameters
  • request payload fields where applicable
  • initiator information
  • redirect activity
  • selected response information

This does not mean every available field should automatically be collected, retained, or exposed.

HAR and network records can contain sensitive or unnecessary information and should be handled carefully.

The objective is relevant and reproducible evidence, not maximum data collection.

What Is a HAR File and Why Does It Matter?

HAR stands for HTTP Archive.

A HAR capture records browser network activity generated during a defined session.

Depending on the capture, it may help answer questions such as:

  • Was a particular third-party service contacted?
  • What endpoint received the request?
  • When did the request occur?
  • Which page was being tested?
  • Did the request happen before or after a consent choice?
  • What observable parameters were included?
  • Did a search, form interaction, button click, or another event trigger additional requests?

A HAR file does not prove that a legal violation occurred.

It is a technical artifact that requires session context and interpretation.

What If the Demand Letter Includes a HAR File?

Do not automatically accept it as conclusive, and do not automatically dismiss it.

Review it systematically.

Questions worth asking include:

  • What URL generated the capture?
  • What date and time does it represent?
  • Can the browser or session environment be identified?
  • Which specific requests are being relied upon?
  • Which values are considered material to the allegation?
  • Can the apparent origin of those values be determined?
  • Was a consent interaction recorded?
  • Was the visitor in a clean or returning session?
  • Is the network capture complete?
  • Are screenshots, videos, or other artifacts available to establish context?
  • Can the claimed behavior currently be reproduced?

It is also useful to distinguish what a supplied HAR directly demonstrates from what someone has inferred from it.

Where included in an agreed scope, Auditzo can technically review supplied HAR or network evidence and compare it against independent controlled observations.


Step 5: Review Cookies and Browser Storage

Cookies can be relevant to a website-tracking investigation, but they are only one part of browser behavior.

A technical review may also examine:

  • first-party cookies
  • third-party cookies
  • localStorage
  • sessionStorage
  • relevant browser-accessible identifiers

The investigation should focus on context rather than only quantity:

  • When did the value appear?
  • Which technology appears to be associated with it?
  • Does it change between defined consent states?
  • Does it correlate with an observed network request?
  • Does the value persist across sessions?

A cookie inventory by itself may not answer the actual allegation.

Step 6: Reproduce the Actual User Journey

If a demand letter concerns a specific interaction, test that interaction rather than assuming homepage behavior represents every page or workflow.

Potential scoped journeys can include:

  • website search
  • lead forms
  • contact forms
  • chat interactions
  • product pages
  • shopping carts
  • appointment-request flows
  • account flows
  • location finders
  • quote requests
  • another interaction specifically identified in the allegation

When test data is necessary, controlled or synthetic values should be used where appropriate so the investigation does not unnecessarily introduce real personal information into the evidence.

Document the relationship between the user action and resulting browser behavior.

Action → Browser behavior → Supporting evidence


Detection Is Not Execution. Execution Is Not Transmission. Transmission Is Not a Legal Conclusion.

This distinction is fundamental to reliable website-tracking evidence.

Website tracking evidence stages showing detection, execution, transmission, technical interpretation, and legal interpretation
Detecting a tracker is only the first layer of evidence. Execution, observable transmission, technical interpretation, and legal interpretation are separate questions.

1. Detection

A scanner or reviewer identifies a script, tag, cookie, integration, domain, code reference, or technology signature.

This can establish presence or a technical indicator.

It does not necessarily establish what happened during the relevant browsing session.

2. Execution

The browser actually executes or initializes the relevant code.

This is stronger behavioral evidence, but execution alone still does not describe every resulting communication.

3. Network transmission

The browser makes an observable request to an endpoint.

At this stage, a reviewer may be able to examine:

  • destination
  • timing
  • request structure
  • relevant parameters
  • payload fields where visible
  • initiator
  • consent and session context

4. Technical interpretation

A technical reviewer evaluates what the observable artifacts demonstrate about browser behavior.

Even at this stage, limitations remain. Browser-side evidence may not reveal every process that occurs after information reaches an external server.

5. Legal interpretation

Qualified counsel evaluates technical findings against the asserted statute, relevant authority, consent issues, relationships between parties, procedural posture, defenses, exceptions, and other legally material facts.

These are different layers of analysis and should not be collapsed into one conclusion.

Finding a tracking technology is not the same as proving a statutory violation.


Can an Automated CIPA Scanner Answer a Demand Letter?

An automated scan can be useful for initial triage and discovery.

It can help surface signals such as:

  • third-party technologies
  • cookies
  • external requests
  • tracking endpoints
  • certain consent behaviors
  • areas that may require deeper investigation

But a demand-letter investigation can require substantially more.

Depending on the allegation, additional work can include:

  • allegation-specific test design
  • human-reviewed browser sessions
  • clean-session reproduction
  • initial, Accept, Reject, and GPC-state comparisons where relevant
  • HAR analysis
  • review of evidence supplied with the demand letter
  • specific user-interaction testing
  • historical configuration review
  • evidence indexing
  • screenshot validation
  • raw artifact preservation
  • technical interpretation and limitation analysis

This is why an automated website scan and a Manual Evidence Audit serve different purposes.

An automated scan helps identify potential signals.

A manual evidence review can be scoped around the technical questions raised by a specific matter.

If an initial technical baseline is all that is currently needed, businesses can also begin with Auditzo's website compliance checker before deciding whether deeper human-reviewed evidence collection is appropriate.


What If the Website Has Already Been Changed?

Do not represent a current test as proof of historical behavior unless the available evidence genuinely supports that conclusion.

A current audit can establish what is observable now.

Historical investigation may require different sources, including:

  • earlier HAR captures
  • screenshots
  • archived technical reports
  • deployment history
  • tag-manager version history
  • CMP records
  • server or application logs
  • previous code or configuration
  • vendor configuration records
  • other timestamped artifacts

Sometimes historical behavior can be reconstructed with reasonable technical support.

Sometimes it cannot.

A credible technical report should state which is true rather than implying certainty that the evidence does not support.

Build a Traceable Evidence Record for Counsel

A useful technical finding should connect the statement being made to supporting artifacts.

Example traceable technical evidence record linking a finding to session details, HAR evidence, screenshots, browser storage, and limitations
A useful technical finding should remain traceable from the observation back to the tested session, supporting artifacts, and stated limitations.

Instead of writing only:

Third-party tracking occurred before consent.

A stronger technical record can identify:

  • test or session ID
  • tested URL
  • timestamp
  • consent state
  • request or evidence ID
  • destination endpoint
  • screenshot reference
  • HAR or network reference
  • cookie or storage reference
  • relevant limitation

The evidence chain becomes:

Finding → Test context → Supporting artifact → Technical interpretation → Limitation

This structure makes the work easier for attorneys, developers, privacy teams, expert reviewers, or other technical personnel to understand and independently review.

You can also review Auditzo's sample website privacy audit report for an example of how structured technical findings can be presented.


Document Technical Limitations Explicitly

Technical evidence should state what it does not establish.

Examples of relevant limitations include:

  • Testing represents defined sessions rather than every historical visit to the website.
  • Current behavior may differ from historical behavior.
  • Geographic, browser, device, account, or consent differences may affect results.
  • Server-side processing after information reaches a third party may not be visible from browser evidence.
  • A vendor's general documentation does not establish what occurred during one specific tested session.
  • Technical testing does not determine whether consent was legally sufficient.
  • Technical testing does not determine whether a statutory definition, defense, exception, jurisdictional requirement, or other legal element is satisfied.

Clear limitations improve credibility because they prevent technical observations from being presented more broadly than the underlying evidence supports.

Auditzo's scope and limitations documentation explains this philosophy in greater detail.


Should You Remove the Pixel Immediately?

Auditzo does not decide whether a business should remove a tracking technology.

That decision can involve legal, operational, marketing, security, contractual, technical, and privacy considerations.

From an evidence perspective, however, two questions should remain separate:

  • Should this technology remain enabled?
  • Do we have a reliable record of its behavior before the configuration changes?

If remediation occurs, document the change and preserve the original evidence separately.

Website tracking evidence workflow showing original-state preservation, remediation, and post-remediation verification
Preserve the original technical record separately, document the remediation, and use a fresh controlled test to verify the post-change state.

Verification After Remediation

A remediation effort should not end with the statement that the developer changed the configuration.

Run a fresh controlled test.

Compare the post-remediation behavior against the original findings and check whether:

  • the targeted request still occurs
  • consent behavior changed
  • cookies or browser storage changed
  • relevant third-party connections stopped or changed
  • the specifically alleged workflow now behaves differently
  • unintended regressions were introduced

Keep the original evidence and post-remediation evidence separate so the timeline remains clear.

For a deeper methodology, see Auditzo's post-remediation verification process.


Why Does a CIPA Demand Letter Mention $5,000 Per Violation?

California Penal Code Section 637.2 contains a civil-damages provision referring to the greater of $5,000 per violation or three times the amount of actual damages, subject to the statute's requirements.

The statute also states, subject to its provisions, that actual damages are not a necessary prerequisite to an action under that section.

That language is one reason "$5,000 per violation" has appeared prominently in CIPA correspondence.

SB 690 changes the civil-remedy framework for a defined category of Section 638.51 claims.

Governor Gavin Newsom approved SB 690 on September 30, 2026. The measure adds subdivision (d) to Section 637.2. Under that provision, an action under Section 637.2 against a private actor for an alleged Section 638.51 violation arising from conduct occurring on an internet website, online application, or mobile application may be brought only by the California Attorney General.

SB 690 is a non-urgency regular-session measure. Under California's general effective-date rule, and because the measure does not specify a later operative date, the amendment is expected to take effect on January 1, 2027. The enacted text also states that the amendments apply retroactively to specified pending claims in actions commenced within two years before the legislation's operative date.

This change should not be generalized to every CIPA claim. SB 690 amends Section 637.2 with respect to the defined Section 638.51 category; it does not amend Section 631.

A technical auditor should not calculate a recipient's legal exposure or determine how SB 690 applies to a particular demand, lawsuit, claimant, or pending matter.

Questions such as what legally constitutes a violation, whether a claimant has a viable cause of action, whether the new limitation or retroactivity language applies, how damages should be analyzed, and which defenses or limitations apply belong to qualified counsel.

Auditzo's role is to help establish the technical facts underlying an allegation, not calculate statutory liability.


What Is a CIPA Pen Register or Trap-and-Trace Claim?

California Penal Code Section 638.50 defines a pen register using concepts involving dialing, routing, addressing, or signaling information transmitted from an instrument or facility and excludes the contents of a communication from that definition.

It separately defines a trap-and-trace device using incoming signaling concepts that are reasonably likely to identify the source of a communication, again excluding contents.

California Penal Code Section 638.51 restricts installation or use of a pen register or trap-and-trace device without the specified court order, subject to the provisions and circumstances contained in the statute.

SB 690 does not amend Section 638.51 itself. Instead, it amends the civil-remedy provision in Section 637.2 for a defined category of alleged Section 638.51 violations involving conduct on internet websites, online applications, and mobile applications.

Whether a particular website technology satisfies the statutory definitions, whether an exception applies, whether Section 638.51 applies to a particular claim, and what effect SB 690 has on a specific matter are legal questions.

The technical investigation can instead establish observable facts such as:

  • what technology was present
  • whether it executed
  • which requests occurred
  • what endpoints were contacted
  • what observable values were transmitted
  • when transmission occurred
  • which user interaction preceded it
  • which consent state existed

Auditzo's CIPA Section 638.51 technical assessment goes deeper into this type of browser-level evidence.

What About CIPA Section 631?

Section 631 uses different statutory language, including provisions addressing unauthorized connections and reading or attempting to learn the contents or meaning of a communication while it is in transit.

This is one reason a demand letter should be read carefully before deciding what technical testing is required.

A contents or interception allegation can raise different technical evidence questions from an allegation focused on routing, addressing, or signaling information.

Auditzo does not determine which legal theory succeeds.

We use the asserted allegation to help scope what should be observed and documented technically.


We Are Not Based in California. Does This Still Matter?

Receiving a demand letter does not itself establish that California law applies to the recipient or that the claim is legally valid.

Jurisdiction, statutory applicability, claimant status, geographic considerations, and other legal questions should be evaluated by qualified counsel.

From a technical standpoint, the same principle remains useful.

If the matter requires investigation, preserve relevant evidence and establish what the website actually did under defined conditions.


SB 690 Signed: What Changed for Section 638.51 Website Claims?

Last reviewed: October 1, 2026.

California Governor Gavin Newsom approved Senate Bill 690 on September 30, 2026.

The measure amends California Penal Code Section 637.2, the civil-remedy provision used for claims arising under the CIPA chapter.

Under the new subdivision (d), an action under Section 637.2 against a private actor for an alleged violation of Section 638.51 arising from conduct occurring on an internet website, online application, or mobile application may be brought only by the California Attorney General.

The enacted text also states that the amendment applies retroactively to a pending claim in an action commenced within two years before the legislation's operative date.

SB 690 is designated as a non-urgency measure and does not specify a later operative date. Under California's general rule for regular-session statutes, the amendment is expected to take effect on January 1, 2027.

What SB 690 does not change

SB 690 should not be described as eliminating CIPA, eliminating every website-tracking claim, or deciding whether a particular tracking technology is lawful.

The legislation does not amend Penal Code Section 631. Section 631 contains different statutory language and can present different legal and technical questions.

SB 690 also does not remove the need to understand the factual website behavior underlying a dispute, remediation project, privacy review, or counsel-directed investigation.

Why technical evidence can still matter after SB 690

Legal viability and technical fact-finding are separate questions.

Where website behavior remains relevant to a pending matter, another asserted legal theory, a privacy review, remediation, vendor governance, or counsel's analysis, the technical investigation can still establish facts such as:

  • which technologies were present
  • whether the relevant code executed
  • which network requests occurred
  • which third-party endpoints were contacted
  • what observable parameters or payload fields were transmitted
  • whether activity occurred before or after a consent choice
  • whether Reject or Decline changed observable behavior
  • whether a GPC signal changed observable behavior where relevant
  • which cookies or browser-storage values appeared
  • whether the alleged user journey can be reproduced
  • whether historical technical evidence is available

For an existing demand letter or lawsuit, counsel should determine what SB 690 means for the particular claim and procedural posture.

Auditzo does not determine whether SB 690 eliminates, limits, preserves, or otherwise changes a specific party's legal claim. Our role is to establish and preserve observable technical evidence for qualified legal and technical review.


CIPA Demand-Letter Technical Evidence Workflow

A counsel-directed technical review can generally be organized around the following sequence:

  1. Preserve the demand materials. Keep the letter, attachments, HAR files, screenshots, reports, and supporting evidence.
  2. Identify the legal allegations. Counsel determines which statutes, claims, and legal questions require attention.
  3. Translate allegations into technical questions. Define what can actually be tested or reproduced.
  4. Preserve relevant current-state context. Capture evidence before material configuration changes where appropriate.
  5. Reproduce the relevant pages and workflows. Do not limit testing to a generic homepage scan if the allegation concerns a specific interaction.
  6. Compare consent states. Test initial, accepted, rejected, GPC, or other relevant states separately where they are within scope.
  7. Review network and browser evidence. Analyze relevant requests, storage, cookies, screenshots, and supporting artifacts.
  8. Review evidence supplied with the demand. Separate direct technical observations from interpretation or assumptions.
  9. Organize evidence using traceable references. Connect important findings to their supporting artifacts.
  10. Document limitations. State clearly what the evidence cannot establish.
  11. Provide the technical record to counsel. Counsel determines legal significance.
  12. Preserve and verify remediation separately. Maintain a clear before-and-after evidence record.

How Auditzo Supports CIPA-Related Technical Evidence Review

Auditzo provides technical website evidence support for businesses, attorneys, law firms, privacy professionals, and technical teams reviewing website-tracking allegations.

Unlike a generic scanner-only approach, a Manual Evidence Audit can be scoped around the particular technical questions raised by a matter.

Depending on the agreed scope, the review may include:

  • human-reviewed browser sessions
  • clean-session testing
  • initial, Accept, Reject, and GPC consent-state comparisons where relevant
  • scoped user-journey testing
  • third-party request analysis
  • HAR and network evidence
  • cookie and browser-storage comparisons
  • timestamped screenshots
  • review of supplied technical artifacts
  • finding-to-evidence references
  • technical limitations
  • remediation-oriented observations
  • post-remediation verification

For legal matters, counsel can identify the allegation or technical question and Auditzo can design the browser-level evidence collection around that issue.

Law firms can review our technical evidence support for law firms, while businesses needing deeper human review can learn more about the Manual Evidence Audit.

What Auditzo Does Not Do

Auditzo does not:

  • provide legal advice
  • act as a law firm
  • determine whether CIPA was violated
  • certify legal compliance
  • determine whether a claimant's demand is legally valid
  • calculate statutory exposure
  • guarantee admissibility of evidence
  • predict litigation outcomes

Our role is narrower and deliberately technical.

We establish and preserve observable technical evidence so qualified counsel and technical teams have a clearer factual record to work with.


Frequently Asked Questions

What should I do first after receiving a CIPA demand letter?

Preserve the letter and supporting materials, identify any stated deadlines, involve qualified counsel, and determine whether relevant website evidence should be preserved before material technical changes are made.

The technical investigation should then focus on the specific allegation rather than relying only on a generic scanner.

Is a CIPA demand letter the same as a lawsuit?

No. A demand letter is not the same thing as a filed court action. If you are unsure which documents you received or what deadlines apply, qualified counsel should review them.

Should I immediately remove the tracking pixel?

That is a legal, technical, and business decision rather than one Auditzo should make.

From an evidence perspective, consider whether relevant behavior needs to be documented before the configuration changes, where appropriate and under counsel's direction.

Does finding Meta Pixel, Google Analytics, or another tracker prove a CIPA violation?

No.

Detection establishes that a technology or technical indicator was observed. It does not automatically establish execution, transmission, the complete contents of a request, or the legal significance of the behavior.

What evidence should be preserved?

Depending on the allegation, useful evidence can include HAR or network captures, screenshots, cookies, browser storage, consent-state observations, relevant configuration history, tag-manager versions, CMP information, logs, deployment records, and technical artifacts supplied with the demand letter.

The appropriate scope depends on the matter.

What is a HAR file?

A HAR file is a browser-generated record of network activity captured during a session.

It can help show which endpoints were contacted, when requests occurred, and selected technical details associated with those requests.

Because HAR files can contain sensitive information, they should be handled appropriately.

Can Auditzo review a HAR file or screenshots attached to a demand letter?

Yes, where those materials are included in the agreed technical scope.

Auditzo can review supplied HAR files, network evidence, screenshots, and other scoped technical artifacts and compare relevant observations with independently captured website behavior.

We do not determine the legal effect of the supplied evidence.

Is an automated CIPA scan enough for a demand-letter investigation?

It can be useful for initial triage and technology discovery.

A matter-specific investigation may additionally require human-reviewed sessions, controlled reproduction, consent-state comparisons, supplied-evidence review, specific workflow testing, raw artifacts, historical context, and structured evidence references.

Is having a cookie banner enough?

A banner alone does not establish how the website behaves technically.

Where relevant, compare the website's network requests, scripts, cookies, and browser storage before and after different consent choices.

Why should Accept and Reject states be tested separately?

Because the purpose is to determine whether observable website behavior changes based on the visitor's choice.

Testing only one consent state can miss differences that are technically important to the investigation.

What if the website has already been changed?

A current audit can document the current state.

Historical conclusions require historical evidence where available. Current behavior should not be represented as proof of earlier behavior unless the evidence supports that conclusion.

Can today's audit prove what happened months ago?

Not automatically.

Historical reconstruction may require earlier HAR files, screenshots, logs, configuration histories, deployment records, tag-manager versions, CMP records, or other timestamped evidence.

Why does the demand letter mention $5,000 per violation?

California Penal Code Section 637.2 contains a civil damages provision referring to $5,000 per violation or three times actual damages, whichever is greater, subject to the statute's requirements.

Auditzo does not determine how many legally cognizable violations occurred or calculate potential liability.

We are not located in California. Can we still receive this type of claim?

A company can receive a demand regardless of whether the claim ultimately succeeds.

Whether California law applies in the particular circumstances is a legal question for qualified counsel.

Can Auditzo tell us whether the demand letter is valid?

No.

Auditzo can investigate whether specific technical allegations can be observed or reproduced, document browser behavior, review scoped evidence, and explain technical limitations.

Counsel determines the legal validity and significance of those findings.

What does SB 690 change for Section 638.51 website claims?

Governor Gavin Newsom approved SB 690 on September 30, 2026. The measure amends Penal Code Section 637.2 so that an action under that section against a private actor for an alleged Section 638.51 violation arising from conduct on an internet website, online application, or mobile application may be brought only by the California Attorney General.

The enacted text also includes a retroactivity provision for specified pending claims in actions commenced within two years before the legislation's operative date.

Because SB 690 is a non-urgency regular-session measure and does not specify a later operative date, the amendment is expected to take effect on January 1, 2027 under California's general effective-date rule.

SB 690 should not be treated as eliminating every CIPA or website-tracking issue. It does not amend Section 631, and other legal theories or privacy obligations can involve different statutes, facts, and requirements.

Businesses facing an existing demand letter or lawsuit should have qualified counsel evaluate the effect of SB 690 on that particular matter. Auditzo's role remains limited to establishing, preserving, and explaining relevant technical website evidence.


Need to Establish What the Website Actually Did?

If your business or client has received a CIPA or website-tracking demand letter, Auditzo can scope a Manual Evidence Audit around the allegation rather than relying only on a generic website scan.

The investigation can be designed around:

  • URLs identified in the matter
  • technologies named in the allegation
  • specific user journeys
  • initial, Accept, Reject, and GPC consent states where relevant
  • HAR and browser network activity
  • cookies and browser storage
  • screenshots or technical artifacts supplied with the demand
  • current-state evidence
  • available historical technical context
  • post-remediation verification

For attorneys and legal teams, Auditzo provides technical evidence support for counsel's review rather than legal conclusions.

If you are still evaluating the scope, review our website audit use cases, evidence-handling approach, or technical evidence preservation methodology.

Before conclusions are made, establish what the website actually did.

Share: