Pause any direct reply, involve counsel immediately, and preserve the consent banner state, tag configuration, and tracker logs that existed on the dates cited in the letter. The first goal is to establish facts, not to negotiate. After that, compare the letter’s tracker list with what actually executed before consent and decide whether the alleged exposure is real or overstated.
What to do first after a wiretap demand letter
The first move is to stop improvising. Treat the letter as a legal and evidentiary event, not a product issue: route it to counsel, freeze the relevant record set, and create a clean snapshot of what your site was actually doing on the dates named in the demand. That is how you avoid overwriting the very evidence you may need to test the claim.
For website tracking disputes, the earliest factual question is whether the alleged trackers really executed before consent, on the pages and dates identified. That means preserving the consent banner logic, tag manager state, deployment history, and tracker or event logs exactly as they stood when the letter says the conduct occurred.
What evidence matters most when preserving the record
The useful evidence is the evidence that can prove what the browser, tag manager, and consent layer did before any remediation. Preserve banner text, consent defaults, cookie categories, tag firing rules, page templates, release notes, and any logs that show whether scripts loaded before a user accepted or declined consent. If those records are not captured immediately, later changes can blur the timeline and weaken your ability to answer the demand accurately.
Teams should also keep the scope narrow and date-bound. The point is not to preserve everything forever, but to preserve the specific configuration, logs, and runtime behavior tied to the letter’s allegations so counsel and technical owners can reconstruct the facts without guesswork.
How to separate real exposure from an overstated claim
Once the record is preserved, compare the letter’s tracker list to actual execution evidence. A demand may overstate exposure by naming tags that were present in code but not fired, scripts that were blocked by consent settings, or third-party tools that were configured differently on the cited dates. The practical test is simple: did the tracker run, when did it run, and under what consent state?
That comparison should be done against the live evidence, not memory. If the site has multiple templates, environments, or tag containers, verify each one independently because the same tracker name can behave differently across pages, releases, and regions.
Risk and Threat Considerations
A wiretap demand letter can create legal and operational risk if teams respond too quickly and alter the records that would show what actually happened. The main exposure is not just the allegation itself, but the possibility that banner settings, tag rules, or logs change before the facts are preserved.
Failure mechanism: Teams remediate or “clean up” tracking settings before counsel and technical staff have preserved the original state, which destroys the ability to verify whether pre-consent execution really occurred.
Impact: The organisation may lose the evidence needed to assess liability, rebut an overbroad allegation, or explain that a tracker never executed in the way the letter claims.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Preserving tracker and consent logs depends on protecting evidentiary records. |
| CM-2 — Baseline Configuration | The issue turns on the exact banner and tag state that existed on specific dates. | |
| Recommendation — Protect audit and tracker logs from alteration so the original runtime evidence remains trustworthy. Capture and retain the affected configuration baseline before making any changes. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | The answer relies on retaining logs that show whether trackers executed before consent. |
| Recommendation — Preserve and review logging records that show consent and tracker behavior. | ||
Practitioner Guidance
What to prioritise: Preserve the exact banner, tag, and log state first, then investigate. If the alleged conduct is time-bound, treat the cited dates as the evidentiary boundary and avoid any changes that could rewrite that history.
What to verify: Confirm whether the named trackers actually fired before consent on the cited pages, in the cited environments, and on the cited dates. If you cannot prove the runtime state from existing logs, capture what you can from deployment records and change history before making any further modifications.
Practitioner takeaway: The first job is fact preservation, not dispute resolution. Once the original tracking state is safely recorded, the team can decide whether the letter reflects a real control failure or an exaggerated reading of the site’s behavior.
Related resources from NHI Mgmt Group
- What do teams get wrong about first-time audits when they try to reach perfect compliance?
- What do teams get wrong about access control when they first deploy Snowflake?
- What should teams do first when they find high-risk Active Directory exposure?
- What do security teams get wrong about first-day access for new hires?
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 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org