Preserve scripts, consent logs, policy versions, and vendor records immediately, then engage counsel familiar with wiretap litigation before changing technical controls. The goal is to avoid spoliation, understand the claim theory, and decide whether settlement or challenge is the better path.
What teams should preserve and why the first hours matter
A tracking demand letter is as much an evidence-preservation event as it is a legal one. Teams should stop normal deletion, preserve the scripts and tag manager configuration in use, and lock down consent records, policy text, vendor contracts, and change history so the record reflects what was actually deployed when the claim arose.
That preservation step matters because disputes often turn on whether a tracking script was present, what data it sent, and whether notice and consent matched the site’s configuration at the time. If teams keep only the current version of the site, they can lose the context needed to evaluate exposure, defend a claim, or narrow the disputed period.
Teams should also preserve related operational records, including deployment logs, consent platform exports, CDN or edge changes, and screenshots of the user flow where notice or preference capture occurred. Those records help reconstruct the technical and governance posture without relying on memory or on a later, cleaned-up site state.
How to assess exposure before making technical changes
Before changing anything, teams should identify the tracking stack and the data flows it created. That means determining which scripts, pixels, session replay tools, analytics tags, or advertising integrations were active, what categories of data they could observe, and which vendors or processors received the information.
The practical question is not only whether a tool existed, but whether the letter appears to target collection, disclosure, or consent practices tied to a specific implementation. The more precisely the team can map tool behavior to site pages, user journeys, and consent states, the faster counsel can judge whether the issue is a configuration problem, a disclosure problem, or something more serious.
Evidence preservation should also include versioned proof of notice and consent, because that is often where teams discover the biggest mismatch between the intended policy and the real implementation. If the site used A/B tests, embedded widgets, or third-party tag updates, those changes can matter as much as the primary analytics code.
How to respond without making the situation worse
The safest next move is usually to coordinate through counsel before removing scripts or altering consent logic. Once a demand letter arrives, changing controls without a record of what changed, when, and why can look like concealment, even when the intent was to reduce risk.
Teams should treat vendor records as part of the defensive file, not just the procurement file. Contracts, data processing terms, configuration notes, and support tickets can help show what the vendor was supposed to do, what the business believed was enabled, and whether the site owner had a reasonable basis for the deployed setup.
If the issue is material, teams may need to freeze relevant service tickets, deployment pipelines, and admin access history so counsel and technical staff can separate the original implementation from later remediation. That keeps the record useful if the dispute becomes a litigation hold, settlement negotiation, or forensic review.
Risk and Threat Considerations
A tracking demand letter creates immediate preservation risk because the easiest way to defend the claim is often the same action that destroys the evidence. If scripts, consent states, or vendor configurations are changed before capture, the organisation may lose the ability to show what users experienced or what data collection actually occurred.
Failure mechanism: Normal retention and release processes continue after notice, or the team remediates the site before documenting the baseline state, causing spoliation risk and weakening the factual record available to counsel.
Impact: The organisation can lose legal leverage, complicate settlement posture, and make it harder to prove either compliant consent flow or a narrower factual scope than the letter alleges.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Preserving deployment and consent records supports later auditability of the tracking state. |
| CM-2 — Baseline Configuration | The dispute hinges on reconstructing the baseline site and tracking configuration. | |
| IR-4 — Incident Handling | A demand letter needs coordinated preservation and response handling to avoid evidentiary loss. | |
| Recommendation — Retain and review audit evidence that shows what tracking controls were active and when. Establish and preserve the relevant configuration baseline before making changes. Coordinate the preservation and response workflow through a formal incident-handling process. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Consent logs, policy versions, and vendor records are sensitive evidence that must be protected. |
| RC.RP-01 — Recovery Plan is Executed | Teams need a disciplined response-and-recovery sequence after the demand letter arrives. | |
| Recommendation — Protect preserved evidence and related records against unauthorized change or deletion. Execute a documented response plan that preserves evidence before remediation. | ||
Practitioner Guidance
What to prioritise: Preserve the live evidence set first, then validate the technical facts second. The first decision is not whether the tracking practice was good or bad, but whether the team can still prove what existed before any remediation.
What to verify: Confirm the exact scripts, consent banners, policy versions, deployment timestamps, and vendor settings that were active on the relevant dates. If you cannot reconstruct that baseline from logs and exports, treat the record as incomplete and escalate the evidentiary risk.
Decision rule: If the site can still collect or disclose user data through active tracking code, involve counsel before altering production controls; if the issue is already contained, preserve the historical state first and then remediate under direction.
Practitioner takeaway: The winning sequence is preserve, reconstruct, then remediate, because once the technical record is overwritten, the legal problem becomes much harder to defend.
Related resources from NHI Mgmt Group
- What should teams do first when they receive a wiretap demand letter about website tracking?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org