Privacy regulations used to sit outside the threat intelligence job. Breach data was treated as already public, dark-web collection as fair game, and the work was to warn victims as fast as possible. US regulators no longer buy that split. CCPA and a growing set of state privacy laws now sit inside every decision a vendor makes about collection, storage, enrichment, and disclosure. Legal can advise. Engineering has to build it.
The legal baseline
Threat intelligence sits between two legitimate goals: protecting organizations from attack, and protecting individuals from having their data collected and used without a disclosed purpose. Regulators are less willing to let the first swallow the second.
The US patchwork is what most vendors have to satisfy
The United States has no single federal privacy law. What it has is a stack of state statutes, sector-specific rules, and the FTC's authority over unfair and deceptive practices. For vendors that ingest global infostealer logs, the question is not whether US privacy rules apply. It is which records they apply to, and for which customers.
The obligations that matter most:
- Legitimate, disclosed purpose: Every collection and use should map to a specific, defensible purpose such as fraud prevention or breach detection, and that purpose should be documented and disclosed. "Because we could scrape it" is not a purpose a regulator will accept.
- Sensitive personal information: Under CPRA and most state laws, data revealing credentials, financial account details, precise geolocation, health, or similar categories gets heightened protection. Breach dumps routinely contain this data, and your handling of it has to meet a higher bar.
- Breach notification: Every US state has a breach-notification statute, layered with sector rules like HIPAA and GLBA. If your own ingestion pipeline mishandles a dataset, you can trigger your own notification obligations.
- Consumer rights: Access, deletion, correction, and opt-out rights apply to threat intel data just as they apply to marketing databases.
A legitimate purpose is not a free pass
A legitimate business purpose is the foundation most threat intelligence providers rely on, but it is conditional. You should be able to demonstrate three things, on paper, before the feed is ingested:
- The purpose being pursued is genuine and specific (preventing fraud, detecting compromise)
- The processing is necessary to achieve that purpose, and no less intrusive option exists
- The individual's rights and reasonable expectations do not override the purpose
"We found your data on the dark web so we can do whatever we want with it" is not a defensible position. US regulators and courts have been clear that the public availability of data does not erase its status as personal information. If anything, the harm caused by further propagation can be a reason against processing.
CCPA and the US patchwork
The United States still has no single federal privacy law, and the state-level patchwork now carries real enforcement risk. Teams that treated US collection as unregulated have a domestic compliance problem, and it is already in the contract language.
California
CCPA's definition of "personal information" in California Civil Code section 1798.140 is broad. It covers identifiers, internet activity, geolocation, professional information, and inferences drawn from any of the above. Breach data obviously qualifies. CCPA grants consumers rights to know, delete, correct, and opt out of the sale or sharing of personal information.
CPRA (the 2023 amendment) adds the concept of sensitive personal information and gives consumers explicit control over that category. Credentials, financial account numbers, precise geolocation, and health data all fall inside the sensitive bucket.
Texas, Virginia, Colorado, and beyond
The second wave of state laws is broadly consistent in structure but varies in detail:
- Texas HB 4 (Texas Data Privacy and Security Act, effective 2024) applies to organizations conducting business in Texas that process the data of Texas residents, with narrower small-business exemptions than some peers.
- Virginia VCDPA introduced the first post-CCPA comprehensive state law and established the opt-out plus data protection assessment model most states have copied.
- Colorado CPA is notable for its rulemaking detail, especially around universal opt-out mechanisms and required privacy impact assessments.
- Additional states: Connecticut, Utah, Oregon, Montana, Delaware, Iowa, Tennessee, and others have passed laws in the same family, with staggered effective dates through 2026.
For a threat intel vendor, one ingestion pipeline has to honor an overlapping set of state obligations. "We only serve US customers" is not the same sentence as "we are unregulated."
Running a privacy impact assessment on threat intel ingestion
Several US state laws, including Colorado, Virginia, and others in the same family, require a data protection or privacy impact assessment for high-risk processing. Threat intel ingestion almost always qualifies because of the volume, sensitivity, and sourcing of the data. Even where a statute does not force it, the assessment is how you show your work when a buyer, an auditor, or a regulator asks.
What a good assessment covers
- Processing description: Sources, data categories, retention periods, recipients, and where the data is stored.
- Necessity and proportionality: Why this processing, why these fields, why this long.
- Risk to individuals: Re-identification risk, propagation risk, incorrect attribution, discrimination, and secondary harm to already-breached individuals.
- Mitigations: Minimization, pseudonymization, access controls, retention caps, and objection handling.
- Residual risk rating: An honest assessment of what remains after mitigations.
Do not file the assessment and forget it. Each new data source or enrichment needs a pass over the relevant section. That includes new stealer-log feeds and new breach-lookup corpora, not just a one-time review of the original pipeline. Our own approach is summarized in the privacy section of the API documentation.
Data minimization and anonymization techniques
Data minimization is required or strongly encouraged by nearly every modern US state privacy law. For threat intelligence that means collecting only what you need to warn victims and detect threats.
Practical techniques
- Field-level minimization: Drop data fields that do not serve a warning or detection purpose. Many raw stealer logs contain browser history, screen resolution, and timezone data that no customer ever queries.
- Hashing for search: Store one-way hashes of identifiers for matching, and reveal the underlying value only when the affected individual's organization requests a disclosure.
- Pseudonymization: Replace direct identifiers with tokens mapped in a separate, access-controlled table. This limits linkability within your platform.
- Anonymization: True anonymization is a high bar. If a data set can be re-identified with reasonable effort, regulators will still treat it as personal information. Be honest about which of your data is truly anonymized and which is merely pseudonymized.
- Retention limits: Define and enforce maximum retention windows per data category. Indefinite retention is rarely defensible.
- Access logging: Every query against sensitive data should leave an audit trail that can be surfaced in a consumer access request.
Disclosure and the "we found your data" problem
The assumption that finding data on the dark web gives you a free hand to disclose it is legally dangerous and ethically sloppy.
Rules of engagement
- Provider-to-organization disclosure: Warning a customer that their employees' credentials have been exposed is typically defensible as a legitimate security purpose. Publishing the same data to a wider audience is not.
- Victim notification: Notifying an identified individual directly requires care. Some jurisdictions expect that notifications come from the organization that holds the relationship, not a third-party platform.
- Redaction in reports: Public threat reports should redact personal data that is not strictly necessary for the technical narrative.
- Law enforcement requests: Respond through formal channels with documented legal process. Informal cooperation can expose you to liability.
Conclusion
Privacy rules are not ending threat intelligence. They raise the bar for how the pipeline is built. Documented purpose, minimization, and disclosure discipline belong in the codebase and the runbooks, not the sales deck. Buyers already ask about privacy impact assessments, retention policies, and handling of sensitive personal information before they sign. Those answers are part of the product.
Tighter scoping produces cleaner data. Honest retention policies cut liability. Documented purposes make the enterprise deal less painful. Compliance and quality point the same direction; you do not get extra credit for treating those as separate projects.
Building threat intel that can survive a privacy review? Start with the API docs for how Revealer.US scopes collection, then run a data breach lookup and see what a minimized result set actually returns.
Frequently asked questions
Does CCPA apply to dark-web or already-public breach data?
Yes. Public availability does not strip personal information of that status under CCPA or most state laws. Credentials, emails, and other identifiers in a dump are still personal information, and further processing still needs a disclosed, defensible purpose.
What counts as a legitimate purpose for processing stealer logs?
Fraud prevention, incident response, and notifying an organization that its users' credentials are circulating are the purposes most vendors can actually defend. Broad "research," resale, or publishing raw logs to a wider audience is much harder to justify. Document the purpose before you ingest the feed.
Do threat intel vendors have to honor deletion and access requests?
In states with consumer rights statutes, yes, subject to the same exemptions that apply to other processors (for example, some security and legal-hold exceptions). Build the workflow now: identity verification, scoped search, redaction of other people's data, and an audit trail. Do not invent the process the first time a request arrives.
What should a privacy impact assessment cover for threat intel ingestion?
Sources, data categories, retention, recipients, necessity, risk to individuals (re-identification, wrong attribution, further propagation), mitigations, and residual risk. Revisit it when you add a source, not once a year as a formality.
Is hashing credentials enough to treat them as anonymized?
Usually no. One-way hashes of emails or passwords are often still personal information if they can be matched back to a person with reasonable effort, which is the entire point of a lookup. Treat hashed identifiers as pseudonymous, keep the mapping access-controlled, and do not claim anonymization you cannot defend.
How should a US-only vendor think about the state patchwork?
A single pipeline that honors the strictest overlapping rule (typically California sensitive-PI rules plus any state that requires impact assessments) is cheaper than forking logic per state. "We only serve US customers" is not an exemption.