Does Your Privacy Policy Name the Tools Your Site Actually Loads?
Most privacy policies were written once, from a template, before half the current stack existed. Meanwhile the site loads analytics, a session recorder, a chat widget and a font CDN — each of which receives visitor data. Here is how to check the two against each other.
By ShipReady
Every third-party script, pixel, font and embed your site loads receives your visitor’s IP address, and usually a persistent identifier too — which makes those companies recipients of personal data. Under GDPR Article 13(1)(e) you have to tell people about recipients, either by naming them or by describing categories of recipient. Naming is the clearer option and the one regulators point at as the default. The check is simple and almost nobody runs it: list what your site actually loads, then read your policy and see whether the two agree.
As with anything in this area: this is a technical article about keeping a document and a website in sync. It is not legal advice, and ShipReady’s checks are observations rather than compliance determinations. What obligations you have depends on where your visitors are and what you do with their data.
What the law actually asks for
Worth being precise, because this is routinely overstated in both directions.
GDPR Article 13(1)(e) requires you to tell people about "the recipients or categories of recipients of the personal data". The word "or" is doing real work — naming every vendor is not strictly mandatory, and a policy that says "we use analytics providers" is not automatically defective.
The nuance is in the guidance. The Article 29 Working Party’s transparency guidelines, endorsed by the EDPB, take the position that the default should be to name recipients, and that a controller choosing to describe categories instead should be able to justify that choice and make the categories as specific as possible — what type of processing, what industry, what location. "Third parties" on its own is not a category in any useful sense.
So the practical standard is: name them unless you have a reason not to. For a small SaaS with eight vendors, there is no reason not to, and naming them is less work than defending a vague description.
Build the actual inventory
Do this from the deployed site, not from memory and not from your package.json. What matters is what a visitor’s browser contacts.
- Open your site in a private window with developer tools open and the Network panel recording.
- Load the homepage, then the pricing page, then a page with a form, then the app itself if it is public. Different routes load different things.
- Sort the requests by domain and write down every domain that is not yours.
- Repeat for one page with an embed — a demo video, a map, a chat widget — because those load lazily and will not appear otherwise.
The list is usually longer than expected. A typical AI-scaffolded SaaS ends up with something like:
| Category | Common examples | What it receives |
|---|---|---|
| Analytics | Google Analytics, Plausible, PostHog, Vercel Analytics | IP address, page views, usually a persistent identifier |
| Advertising | Meta Pixel, Google Ads, LinkedIn Insight | IP address, conversion events, an advertising identifier |
| Session replay | Hotjar, FullStory, LogRocket, Clarity | Recordings of what the visitor did, potentially including form input |
| Error tracking | Sentry, Bugsnag | IP address, stack traces, whatever context you attach |
| Support chat | Intercom, Crisp, Tawk | IP address, conversation content, often an identity |
| Fonts and CDN | Google Fonts, jsDelivr, unpkg | IP address, user agent, referring page |
| Payments | Stripe, Paddle, Polar | Payment details and identity — handled by them, not you, which is the point |
| Embeds | YouTube, Vimeo, Google Maps, Calendly | IP address, and frequently cookies of their own |
The categories people forget are the last two rows. A font loaded from a third-party CDN transmits your visitor’s IP address to another company on every page view — ShipReady reports Google Fonts loaded from a third party as an observation for that reason, and self-hosting removes the question entirely. Embedded players and schedulers routinely set cookies of their own before anyone has agreed to anything.
Now read the policy
Open your privacy policy next to the list and check both directions. Both matter, and the second is the one nobody checks.
- Forward: is every service on your list mentioned in the policy, by product name or by the company behind it? A policy that names Google but not Hotjar has a gap.
- Reverse: does the policy name services you no longer use? A generator template that mentions Mailchimp on a site that moved to Resend two years ago is inaccurate in a way that is easy to fix and slightly embarrassing to be asked about.
While you are there, check the policy has a route to contact you about data — under Articles 15 to 22 people have rights they need to be able to exercise, and a policy with no address or form is a dead end. ShipReady reports a privacy policy with no contact route. And confirm the address it gives can actually receive mail, which is its own silent failure.
What a good section looks like
It does not need to be elaborate. A table with four columns beats three paragraphs of prose:
| Service | Purpose | Data it receives | Their policy |
|---|---|---|---|
| Plausible Analytics | Aggregate site analytics | Page URL, referrer, country, device type. No cookies. | Link to their policy |
| Sentry | Error monitoring | IP address, browser, error context | Link to their policy |
| Stripe | Payment processing | Name, email, payment details | Link to their policy |
Two habits keep it accurate. Add the row when you add the vendor — it takes a minute during the integration and an afternoon six months later. And revisit the list whenever you do the consent check, since both start from the same inventory.
Two decisions worth making explicitly
Some vendors deserve a deliberate choice rather than an inherited one, because they collect qualitatively more than page views.
- Session replay records what people actually did on your site, which can include text they typed into forms. Every serious tool offers input masking; it is not always on by default. ShipReady flags a session replay script so the choice is at least visible.
- Device fingerprinting identifies a browser without storing anything on it, which is why it is sometimes pitched as a privacy-friendly alternative to cookies. It generally is not treated that way by regulators. ShipReady flags a fingerprinting script on the same basis.
Neither finding says you must remove the tool. They say the tool is there, which is information you need before writing a policy that describes your site accurately.
How ShipReady checks this
ShipReady identifies the third-party services a page loads, finds your privacy policy among the pages it crawled, and checks whether each service appears in it by product name or by the name of the company behind it. When one does not, it reports a privacy policy that does not name a service the site uses, listing the services in question.
This is a site-scoped check for a structural reason: the policy is on one page and the trackers are on another, so it is the only scope that can hold both at once. It is rated low severity deliberately. Naming recipients individually is one of two options the regulation permits, so a policy using well-drawn categories may be perfectly adequate and still trigger this — the finding is ShipReady’s observation that two things on your own site disagree, not a legal verdict. It also reports no privacy policy at all and no terms of service, which are simpler facts.
Scan your site free to get the inventory built for you, or read the Compliance and Privacy pillar for everything in this area a passive scan can see.
Frequently asked questions
- Do I have to name every vendor, or are categories enough?
- Article 13(1)(e) permits either. Regulatory guidance treats naming as the default and expects a controller using categories to justify that and to make them specific. For a small product with a handful of vendors, naming them is simpler than defending the alternative.
- Does a template privacy policy cover me?
- It gives you structure. It cannot know what your site loads, which is exactly the part this article is about — a generated policy describes a generic site, and the gap between it and yours grows every time you add a script.
- Is my hosting provider a recipient?
- Generally yes, as a processor acting on your instructions. Hosting, CDN and infrastructure providers are usually listed, and many companies keep a separate subprocessor page for them and link it from the policy.
- What if I only use cookieless analytics?
- You still transmit an IP address to that provider, so they remain a recipient and belong in the policy. What changes is the consent question, since nothing is stored on the device.