A privacy company's policy is the one document where its own data practices are written down and binding. PrivacyHawk's opens with a strong statement of principle: "Protecting privacy is the reason our company exists — and we start with how we handle your data ourselves," followed by commitments to data minimization and "We do not sell personal data or share it for cross-context behavioural advertising."
Those commitments are real and worth acknowledging. What follows is what the rest of the document describes, quoted as written. Their policy is public at privacyhawk.com/privacy; every quote below can be checked against it.
This is opt-in and tied to a specific feature, which the policy is clear about. Two things are still worth noting. First, the data uploaded is other people's phone numbers — your contacts never agreed to anything. Second, "one-way encoded" describes hashing, and the strength of a hash depends on details the policy does not give. If the numbers are hashed without a secret key, a phone number is recoverable by hashing every possible number and comparing, because the space is only about 10 billion. If they use a keyed hash, that attack does not work. The policy does not say which, so neither can we.
The limits here matter and we state them plainly: this happens only if you turn SMS filtering on, and only for senders who are not in your contacts. Messages from people you know are not uploaded.
Within those limits, though, message bodies from unknown senders do reach their servers. A text from a delivery service, a clinic, a bank's fraud line or a two-factor code is a message from a sender not in your contacts. That is the trade a spam filter of this design requires, and it is worth understanding before enabling it.
Two separate clauses govern email, and reading only one of them gives the wrong impression. The inbox scan itself is narrow:
That is a genuinely privacy-preserving design, and the parenthesis is an explicit commitment not to read message content during a scan. A separate clause, however, covers full message text in two named cases:
The first case is defensible: if a company sends you an opt-out confirmation, reading it is how anyone verifies the opt-out worked. We read broker replies for the same reason, in a mailbox of our own.
The second case is broader. "Emails that our automated systems have determined to be security threats, fraud risks, or scams" is a category their system defines, and once it decides, the full text is collected. The policy states the purpose — notifying you, improving the system — but not the criteria, nor whether a classification can be reviewed. That is the clause we would want tightened.
A tracking pixel is an invisible image that loads from the sender's server when a message is opened, reporting the time, the device and the IP address it was opened from. It is standard practice across the email industry, and it is on by default in most email delivery platforms — which is exactly why it is worth asking whether a privacy product should inherit that default rather than turn it off.
The policy lists "IP address, browser type, device type, OS, date/time of requests, and how you interact with our Services," along with usage data, and location described as "Approximate location derived from IP (not stored)." The parenthesis is theirs and it matters: they say the location is derived but not retained. Their website also loads Google Fonts from Google's servers and runs Intellimize, a third-party personalization and testing service, both of which see visitors' IP addresses.
Section 16 governs PrivacyHawk Enterprise separately and limits it explicitly:
gmail.metadata and a read-only directory scope, and "From the headers available to us, we extract and retain only the sender's domain and the message timestamp. We do not retain subject lines, recipient lists, or any message content."
The section also commits to Google's Limited Use requirements, states that enterprise data is encrypted in transit and at rest, promises deletion within 30 days of revocation, and notes a completed SOC 2 audit. Anything said above about contacts, texts or message content applies to the consumer app, not to this product.
Section 12, the security section, reads in full: "We use highly secure, industry best practices to protect personal data and take security extremely seriously. No system is completely secure, but we work hard to minimize risks." For consumer data there is no statement of how data is encrypted at rest, or whether it is. The enterprise section is specific on exactly this point, which makes the silence in the consumer sections more noticeable.
We requested their homepage from our own server on 19 September 2026 and recorded the response headers. We report the values rather than a third-party grade, for the reason set out in our security header audit: a header can be present and inert.
| Security Header | PrivacyHawk | Vigilant Privacy |
|---|---|---|
| Content-Security-Policy | Present, but frame-ancestors 'self' only — no script control | Full policy with script-src, no unsafe-inline on scripts |
| Strict-Transport-Security | ✓ one year | ✓ one year + includeSubDomains |
| X-Frame-Options | ✓ SAMEORIGIN | ✓ DENY |
| X-Content-Type-Options | ✗ absent | ✓ nosniff |
| Referrer-Policy | ✗ absent | ✓ strict-origin-when-cross-origin |
| Permissions-Policy | ✗ absent | ✓ set |
Their CSP prevents clickjacking and nothing else: with no script-src or default-src, it places no restriction on scripts. Their site is built on Webflow, which limits how much of this a site owner controls. Asset URLs on the page reference a privacyhawktest.webflow hostname, which is how Webflow staging subdomains routinely appear on published sites; we draw no conclusion from it.
PrivacyHawk's site advertises "Complete data removal from 100+ brokers and 10,000+ companies." Those are two different measures and we will not restate them as one number.
Our catalog holds 1,468 active data brokers. Of those, 1,068 have a working role-based contact address, which is the number we can send a CCPA deletion demand to by email. The rest we cover through opt-out forms and portals, some of which still need a person to complete a CAPTCHA.
PrivacyHawk is a real company with a real product, a SOC 2 audit and a policy that is more specific than most. Their enterprise design — metadata scope only, sender domain retained, nothing else — is a good one, and their consumer email scan is narrower than people assume.
The question their policy raises is about the consumer app's other features. Spam call blocking wants your address book. Spam text filtering wants the text of messages from unknown senders. Threat detection wants the full text of anything its classifier flags. Each is defensible on its own; together they mean the app holds a good deal more about you than the brokers it removes you from ever did.
Our own approach, stated so it can be checked: we never ask for your contacts or your text messages, and our service does not read your mailbox. Our emails carry no tracking pixels and no rewritten click-tracking links: both were on by our email provider’s default until we turned them off on 19 September 2026, which is the same default we question above. Subscriber personal data is encrypted at rest with AES-256-GCM. Our website loads no analytics or advertising trackers on any page — no Google Analytics, no Google Fonts, no session recording — which you can verify in your browser's network tab. We send CCPA deletion demands to 1,068 brokers by email and cover the rest through their opt-out forms.
1,468 brokers covered. CCPA legal demands. No contact uploads. No message reading. No tracking pixels in our emails. $9.95/month.
Start Your Free 7-Day TrialNo credit card required for the trial. Cancel anytime. We never sell your data.
Methodology. Every quotation above is from PrivacyHawk's Privacy Policy, effective 1 September 2026, read at privacyhawk.com/privacy on 19 September 2026, and is cited to the section it appears in. Coverage figures are quoted from each company's own marketing rather than converted into a single number. Security headers were recorded by requesting each homepage over HTTPS from a single US host on 19 September 2026 with a desktop browser user-agent, following redirects; we report header values, not a scanner's grade, and headers can differ by path, by region and over time. Readers are encouraged to check the policy themselves. If PrivacyHawk changes its policy or practices, we will update this analysis and say what changed.