What a privacy policy has to say if you collect anything

A privacy policy has to say what you collect, why you collect it, who else sees it, how long you keep it, and how someone can ask you to delete or correct it. If you run analytics, a contact form, cookies, or login accounts, you collect personal data — and the policy is the legal document that discloses it.

Key Takeaways

• A privacy policy is a disclosure document, not a consent tick-box — it must match what your site actually does.
• The core requirements are the same across most laws: what you collect, why, who receives it, retention, and user rights.
• GDPR, UK GDPR, CCPA/CPRA and similar laws apply to Nepali businesses that serve visitors in those regions.
• If your policy lists data you don't collect, or omits analytics that do run, you create a misleading statement — and that itself is a breach.
• Cookies, analytics and third-party embeds like maps, video and payments all count as data collection.
• You need a process to keep the policy current, not a one-time document you publish and forget.
• A template is a starting point, never the finished policy — it must be checked against the live site.

What a privacy policy actually is (and is not)

A privacy policy is a public statement of how your website handles personal data. It is not a terms-of-service page, and it is not the cookie banner itself. The banner asks for consent; the policy explains what that consent covers, what data you collect, why you hold it, and what rights the visitor has over it.

Why a misleading policy is worse than none

A policy that lists data you don't collect, or omits analytics that do run, creates a false statement about your data practices. Regulators treat misleading disclosures as a separate breach from the underlying data collection. You can face a fine for the gap between your policy and your actual tracking, even if the tracking itself was lawful. In practice, a vague but accurate policy beats a detailed one that does not match the live site.

When you actually need a privacy policy

You need a privacy policy the moment your website collects personal data. That includes a contact form, an analytics script, a cookie, a login system, a payment form, or an embedded map or video. A purely static page with no scripts, no forms and no third-party calls may not collect anything — but that describes very few real sites. If you build sites for clients, this is a core part of website design in Nepal, not an afterthought.

The core disclosures every policy must include

Most data-protection laws converge on the same core disclosures. Your policy must state what personal data you collect, why you collect it, the lawful basis under GDPR or UK GDPR, who you share it with, how long you keep it, and the user's rights to access, correct, export or delete their data. If any of those is missing, the policy is incomplete.

How the data flow maps to the policy

The policy is a map of your data flow. Visitor data moves from the browser to your server, then to third parties such as analytics providers, payment processors and hosting services. Each hop is a disclosure. If your policy does not name a processor that actually receives data, the map is wrong. Consent mode in tools like Google Tag Manager is a separate control that changes what fires, but the policy must still describe the default behaviour before consent is given.

Step-by-step: document before you write

Document the data inventory before drafting any policy text. Walk through each form, script and embed on the live site, and record what it sends and to whom. You cannot write an accurate policy from memory; you need to inspect the actual requests the browser makes. Here is the sequence we follow on real projects.

1. List every input field, cookie, script and third-party embed on the site.
2. For each item, write down the data categories it collects — name, email, IP address, device type, page URL, purchase amount.
3. State the purpose for each category: reply to an enquiry, measure performance, process a payment, personalise ads.
4. Identify the lawful basis under GDPR or UK GDPR for each purpose — consent, legitimate interest, contract, or legal obligation.
5. Name every third party that receives the data, including analytics, hosting, payment and email providers.
6. Define a retention period for each category and how deletion requests will be handled.
7. Write the disclosures in plain language, date the policy, and schedule a review every six months or after any site change.

Here is what a minimal data inventory looks like before it becomes policy prose:

- Contact form: name, email, message
  Purpose: reply to enquiry
  Basis: consent
  Retention: 12 months, then deleted
  Third party: hosting provider, email relay

- Google Analytics: page views, device, IP
  Purpose: site performance
  Basis: legitimate interest
  Retention: 26 months
  Third party: Google

Jurisdiction requirements that change the wording

GDPR, UK GDPR, CCPA/CPRA and the ePrivacy Directive share the same core disclosure duties but differ on specific rights. GDPR and UK GDPR require a lawful basis for each purpose. CCPA/CPRA adds a right to opt out of the sale or sharing of personal information for advertising. The ePrivacy Directive governs cookie consent before non-essential scripts run.

Law	What it demands beyond the basics	Who it applies to
GDPR	Lawful basis per purpose, data subject rights, breach notification	EU residents
UK GDPR	Same core duties as GDPR after Brexit	UK residents
CCPA/CPRA	Right to opt out of sale or sharing, limits on sensitive data	California residents
ePrivacy Directive	Cookie consent, rules for electronic communications data	EU/UK visitors

How to verify the policy matches the live site

Verification means comparing the policy against the actual browser traffic. Open your own site with developer tools, watch the network tab, and list every third-party domain that receives a request. Then check that each one appears in the policy under the sharing or processors section. If you find a domain in the traffic that is not in the policy, or a named processor that never fires, fix the mismatch before publishing. This is exactly the kind of ongoing check we include in website maintenance services.

Failure modes and how to debug them

The most common failure is drift: the site gains a new script and the policy does not. A second failure is the blanket statement. Saying "we do not share data" while loading Google Fonts, an embedded YouTube video or a payment iframe is false, because those services receive IP addresses. Debug the policy the way you debug a release: diff the declared data against the observed traffic, find the gap, and either remove the script or update the disclosure.

Cost and operational overhead (qualitative)

The cost of a privacy policy is driven by how much data you actually collect and how many jurisdictions you serve. A simple brochure site with a contact form needs less legal review than an e-commerce site with analytics, advertising pixels and payments. Ongoing effort comes from keeping the disclosure current as the site changes — every new plugin, script or integration forces a review. Confirm current legal fees with the provider; our team can help you scope the technical inventory that feeds the legal text, and we route that work through our contact page.

Security considerations

A privacy policy promises retention and deletion. You can only honour those promises if your systems support them. If you say you keep form submissions for twelve months, the database needs a deletion job. If you promise encryption, the transport actually has to use TLS. The policy is not a security control, but it creates obligations your infrastructure must be able to meet — otherwise the disclosure becomes another form of drift.

Common mistakes we see in real projects

The most frequent mistake is copying a template verbatim without checking it. Templates often list data categories your site does not collect, or omit the analytics and embeds you do use. A second mistake is treating the policy as a publish-once document with no dated version history. A third is handing the site to a new owner without including the policy in the website handover checklist, which leaves the next team guessing what the site actually tracks.

A concrete scenario: the e-commerce site that grew

A Kathmandu-based shop starts with a brochure page and a generic privacy policy. Six months later it adds Google Analytics, a Meta Pixel, a contact form and Stripe checkout. The policy still says "we do not share data with third parties." That is now false, and a single EU customer complaint can trigger an inquiry. The fix is not a new template — it is a full data inventory, a rewritten policy that names each processor by purpose, and a consent banner that matches. The site owner also needs to decide who actually owns the data flows, which is a question covered in our guide on who owns website code.

Alternatives compared

You have four realistic options: a generic free template, a paid privacy-policy generator, a lawyer's review, or a policy drafted by the engineer who built the site. The right choice depends on how much data you collect and how much regulatory exposure you carry.

Approach	Risk if unchecked	Effort	Best for
Free template	High — often lists wrong data	Low	Static site with no third parties
Paid generator	Medium — needs manual checking	Low	Simple site, few data types
Lawyer review	Low	Medium	Multi-jurisdiction e-commerce
Engineer-drafted	Medium-low	Medium	Site where the builder knows the stack

In short

A privacy policy is a disclosure, not a disclaimer. It has to say what you collect, why, who sees it, how long you keep it, and how a visitor can exercise their rights. If the policy does not match the live site, the policy itself becomes the problem. Inventory the data, name every processor, date the document, and review it every time the site changes. That is the entire job — and it is an operational task, not a one-off legal chore.

People also search for

• Who owns website code and data when you hire a developer
• What a website handover checklist must include
• Should I rebuild my website or fix what I have
• What a cheap website is actually costing you
• How a web development quote is broken down
• WordPress vs a custom website for your business

If your site collects data and the policy has not kept up with the scripts and forms actually running, our team can help you build a data inventory, match the disclosure to the live site, and set a review schedule so the two never drift apart again. Start with a review through our contact page or see how we handle website maintenance services.