Part II - Publication and compliance notes
Internal only: This section is for Deleteme’s counsel, privacy, product, security, and content owners. Do not publish it as customer-facing copy without review.

Why the taxonomy was changed
The supplied draft mixed collection methods, intelligence disciplines, platforms, and risk types. It also described breach and stealer-log material as if it were simply ‘public.’ The revised taxonomy uses five customer-readable source categories and reserves enhanced controls for cybersecurity exposure intelligence.

Original label | Recommended treatment
OSINT | Keep as a general concept only where useful; the public taxonomy describes actual source families instead of intelligence jargon.
Human Intelligence | Remove unless Deleteme truly conducts a documented, lawful human-source program. User submissions are described separately and require authority and provenance checks.
Counter Intelligence | Remove. The term is ambiguous and may imply investigative or governmental functions inconsistent with the website’s current positioning.
Internal Intelligence | Replace with ‘internal security telemetry’ only if the Privacy Policy accurately describes the data, purpose, lawful basis, retention, and recipients.
Deep/Dark Web | Retain only as a subcategory of restricted cybersecurity exposure intelligence. Do not equate it with public data or publish operational links.

Minimum publication controls
1. Confirm the page describes actual collection and product behavior. Under U.S. consumer-protection principles, privacy promises must match practice.
2. Maintain a source register with category, source name/domain, access class, purpose, data types, lawful basis, retention, owner, last verification date, and whether a direct public link is permitted.
3. For EU/EEA and UK individuals, document the lawful basis for each purpose. If relying on legitimate interests, maintain a purpose-specific assessment and a clear objection process.
4. Give Article 14-style information when data is obtained indirectly: categories of data, purposes, legal basis, recipients, retention, rights, and sufficiently precise source information. If individual notice is not provided because it is impossible or disproportionate, document that assessment and make the notice easy to find.
5. Apply additional controls to special-category data and data relating to criminal convictions or offences. Do not assume that public posting removes GDPR protection.
6. Do not scrape login-only areas, defeat CAPTCHA or other access controls, or ignore a source’s technical or contractual restrictions without specific legal approval.
7. Do not store or display usable passwords, session cookies, access tokens, financial-authentication data, malware, or other secrets. Prefer one-way matching, masking, hashing, or source-level exposure indicators where feasible.
8. Set category-specific retention periods. Raw exposure material should have the shortest justified retention and the strictest access controls.
9. Maintain suppression, correction, deletion, objection, and access workflows that propagate to relevant systems and vendors, subject to lawful exceptions.
10. Enforce product-level FCRA restrictions technically and contractually; a disclaimer alone is not sufficient if the product is actually used for regulated eligibility decisions.
11. Review state privacy, biometric, protected-address, data-broker, breach-notification, and sector laws for each relevant jurisdiction. California is an important baseline, not a complete U.S. rulebook.
12. Review intellectual-property, database-right, confidentiality, and platform-terms issues for each automated collection source.
13. Reassess international transfers and processor/vendor contracts; do not state reliance on a transfer mechanism unless the relevant entity and recipients are actually covered.