Quick answer: A website privacy policy is compliant only when all three are true:
- It describes what your site actually collects and shares, not what a template assumed.
- It satisfies every law that reaches your visitors: GDPR, CCPA/CPRA, and 20 US state laws in 2026.
- It gives users a working way to act on their rights.
Most policies fail the first test. Use the privacy policy compliance checklist below, then fix tracking with our GDPR cookie consent guide.
Key takeaways
- A policy that exists is not a policy that complies.
- In 2025, Honda ($632,500), Todd Snyder ($345,178), and Tractor Supply ($1.35M) were fined for gaps between their policy text and their live sites.
- You do not pick your laws. Your visitors’ locations and your data flows pick them.
- Start with a data map, not a template.
- For most small businesses, the real threat is a lost deal or a tracker lawsuit, not a regulator.
Why “we have a privacy policy” is the wrong test
Honda paid $632,500 to the California Privacy Protection Agency in March 2025. Todd Snyder settled for $345,178. Tractor Supply agreed to $1.35 million.
None were caught selling medical records. They were penalised for dull failures: an opt-out link broken for 40 days, a rights form demanding too much ID, tracking wired up wrong. Their policies read fine and just did not match the websites.
GVM Technologies runs this same check on almost every website development project we take over, and the gaps repeat.
What a compliant privacy policy actually requires
A clause list is the easy part. Three conditions matter more.
1. It matches what your website really does today
A generator assembles clauses from your answers. It cannot see the Meta pixel marketing added last quarter or the CRM your form posts to.
2. It covers every law that reaches your users
“Pick GDPR or CCPA” is outdated. Build to GDPR’s disclosure standard first, then add the CCPA links and state-law rights on top.
3. Every right it names has a working channel
This is where Honda and Todd Snyder lost. The policy promised an opt-out; the mechanics did not deliver one.
The 90-second self-check
Two or more failures means the policy needs work before anything else.
- Read your “what we collect” section. Can you name a live tool it never mentions? Analytics, chat widget, heatmap, ad pixel.
- Find the “last updated” date. Older than 12 months fails CCPA and signals that nobody is watching.
- Test your request channel. Email the address in your policy. A dead inbox is a promise you cannot keep.
- Check the California links. Is “Do Not Sell or Share My Personal Information” present, and does your site honour the Global Privacy Control signal?
- Check every page footer. The link must be persistent, not buried in checkout.
Which privacy laws apply to your website
Mark every row that matches. The laws stack; they do not replace each other. If you sell online, layer PCI compliance for e-commerce on top of this.
| If this is true | Law that applies | Key policy additions |
|---|---|---|
| Visitors or leads in the EU/EEA or the UK | GDPR / UK GDPR + PECR | Lawful basis per purpose, retention periods, transfer mechanism, EU or UK representative if you have no local office |
| California residents, above CCPA thresholds (~$26.6M revenue, 100,000+ consumers, or 50%+ revenue from data) | CCPA/CPRA | “Do Not Sell or Share” link, “Limit Sensitive Data” link, honour Global Privacy Control, two request methods |
| Users in Virginia, Colorado, Texas, and 17 more states | State privacy laws | Rights to access, delete, correct, and opt out of targeted ads and profiling, plus an appeal path |
| Data from children, or any health, biometric, or location data | COPPA / GDPR Art. 8 and 9 | Verifiable parental consent or an extra legal condition, often explicit consent |
1. GDPR follows your users, not your address
“We are a US company, so GDPR does not apply” is the most common mistake we hear.
GDPR applies to whoever’s data you process. Run analytics on EU visitors and you are in scope, wherever your company sits.
2. The US state patchwork is the harder problem
Twenty states have comprehensive laws in force, with Indiana, Kentucky, and Rhode Island live from 1 January 2026. There is no “GDPR certified” badge to buy: compliance is a data map, written lawful bases, retention limits, and a review cycle.
The privacy policy compliance checklist
Go section by section through your live policy. Mark each item present, missing, or present-but-wrong.
| Section | Must include |
|---|---|
| Identity | Legal entity name, address, privacy contact, one named owner |
| Data collected | Every category in plain terms, sensitive data flagged, a purpose for each |
| Lawful basis | The GDPR basis per purpose (consent is one of six, and the weakest) |
| Collection methods | Direct, automatic (cookies, pixels, logs), and third-party sources |
| Sharing | Named vendors or categories, whether you “sell” or “share” under CCPA, processor agreements |
| Transfers | Destination countries and the mechanism (adequacy, SCCs, Data Privacy Framework) |
| Retention | A period or method per category, and what happens at the end |
| User rights | Access, correction, deletion, portability, objection, opt-outs, withdraw consent, each with a channel |
| CCPA specifics | Homepage “Do Not Sell or Share” link, GPC honoured, Notice at Collection, “Do Not Track” statement |
| Security | Plain safeguards, a 72-hour breach commitment, no “100% secure” claims |
| Children | Minimum age, parental consent, deletion route |
| Automated decisions | The logic, significance, consequences, and a human-review route |
| Housekeeping | Real “last updated” date, change notices, regulator to complain to, separate from Terms |
1. Consent is the weakest lawful basis, not the default
For core service delivery, “performance of a contract” is usually the correct GDPR basis. Over-using consent creates withdrawal obligations you never needed.
2. The California links must actually work
A missing “Do Not Sell or Share” link is a standard enforcement finding. Your site must also detect the Global Privacy Control signal and act on it automatically, not just claim to. This is exactly the kind of thing our QA testing catches before launch.
The test every checklist skips: does your policy match your site?
Every published checklist tells you what to include. Almost none tell you how to confirm it is true. Build a three-column comparison: what the policy claims, what the site does, what your records prove. Any row where they disagree is a gap.
1. Run the 5-minute browser check
You do not need a developer for this.
- Open your site in a fresh browser profile with no extensions.
- Press F12, open the Network tab, and reload.
- Note every external domain contacted before you click anything.
- Check the Storage tab for cookies set on load.
- Click “reject” on your banner and repeat. Anything still firing is a problem.
A scanner can flag a tag that fires before consent. It cannot judge whether your lawful basis holds or whether deletion reaches your backups.
2. Build a one-page data map
This is the highest-value hour you will spend. In a spreadsheet, answer:
- What personal data do we collect, and on what lawful basis?
- Where is it stored, and in which country?
- Which vendors and sub-processors touch it?
- Who can access it internally, and when is it deleted?
GDPR calls the formal version a Record of Processing Activities. You do not need the formal template to get the value.
Cookies, pixels and embeds: the usual contradiction
Each of these sends user data, including the IP address, to a third party, often before consent:
- Google Fonts loaded from Google’s CDN instead of self-hosted
- Google Maps and YouTube embeds
- “Sign in with Google, Facebook, or Apple” buttons
- reCAPTCHA, live chat, heatmaps, session-replay tools
- Ad pixels: Meta, LinkedIn, TikTok, Google Ads
Your disclosures must name these, and your consent gating must hold them until the user agrees. The banner mechanics that make this work are in our GDPR cookie consent guide.
If you outsourced your build, put this requirement in writing to your agency. We explain why in software development contract red flags, and the cost of adding third parties later in the hidden costs of API integration.
The deletion-request fire drill
A data subject access request is where your policy gets tested. Run it on yourself first: have a colleague email your privacy contact asking what data you hold and to delete it. Then score yourself.
| Checkpoint | A pass looks like |
|---|---|
| Request reached a monitored inbox | Acknowledged within one business day |
| You know everywhere that data lives | Listed from your data map, no guessing |
| You can export and delete it everywhere | Covers app DB, CRM, email, analytics, support tool, backups |
| You did not over-verify identity | ID checks proportionate to the request |
| You logged the request and response | A dated record exists |
Most teams fail on “you know everywhere the data lives.” That is a data-mapping problem, not a wording problem.
Backups and the “right to be forgotten”
You are not expected to restore every historical backup to remove one person inside the response window.
- Delete the person’s data from all production systems within the deadline.
- Put backup copies “beyond use”: encrypted, access-controlled, not restored for any live purpose.
- Keep a suppression list of deleted identifiers, and re-run deletions if you ever restore.
- Keep backup retention short. A 30-day rotation clears the problem in a month.
Tell the user exactly this, and document it. Our pre-launch security checklist covers backup rotation in depth.
Server logs are the blind spot. If your app logs full request bodies on form errors, you are writing names and emails into storage nobody treats as a database.
Whose job is compliance: developer, marketer or founder?
- The founder is the data controller. Legal responsibility sits here and cannot be delegated.
- Marketing creates the exposure. New pixels, new tools, new data.
- Developers control the mechanics. Logging, consent gating, whether deletion reaches every system.
Compliance breaks when each group assumes another owns it. Assign one accountable owner with visibility into both sides.
Mistakes we see on almost every pre-launch review
- Treating the generated policy as finished. Length is not accuracy.
- Assuming GDPR is only the cookie banner. It governs your CRM and email list too.
- Choosing “consent” as the basis for everything.
- A cookie banner that returns true or false and blocks nothing.
- Copying a larger company’s policy and inheriting commitments you cannot meet.
- Shipping the pixel and the updated policy on different sprints.
Generator, lawyer or DIY: how to choose
Match the approach to your data risk, not your revenue.
| Approach | Good fit when | Watch out for |
|---|---|---|
| Paid generator | Standard stack, and you have a data map | Reflects your inputs, not your live site |
| DIY from a regulator checklist | One or two data flows, zero budget | Misses CCPA link rules and state-law language |
| Lawyer from scratch | Sensitive data, fundraising, or many countries | $1,500 to $5,000+, and still needs your data map |
| Hybrid: generate, then lawyer-review | Most funded startups | You must flag the risky parts yourself |
We recommend the hybrid path: data map, generated draft, then counsel on the lawful-basis, transfer, and retention sections.
The risk that should actually worry a small business
Founder debate swings between “one mistake and I am bankrupt” and “nobody enforces this.” Both are wrong.
| Your business | Most likely consequence of a weak policy |
|---|---|
| Small B2B SaaS, no data sales | A stalled or lost enterprise deal after a vendor security review |
| US consumer site with ad pixels | A private lawsuit over undisclosed trackers or session replay |
| E-commerce selling into the EU | A complaint and an order to fix, sometimes a modest fine |
| Any business, after a breach | Your security claims become evidence in a misrepresentation case |
For most B2B companies, the work pays for itself by not losing the next contract.
GVM’s development and QA testing processes run against ISO 27001:2022, 20000-1:2018, and 9001:2015 certified frameworks. That is often what clears a client’s security review.
How often to review your privacy policy
Re-check it against your data map on a fixed schedule:
- At least every 12 months, which CCPA requires.
- When you add or remove a vendor that touches personal data.
- When you launch a feature that collects new data.
- When you enter a new state or country, or after any breach.
Get your policy and your site to match
If you worked through this privacy policy compliance checklist and found gaps, the cause is almost always the same. The policy is a generated draft that no longer matches a site that outgrew it, and it surfaces at the worst time: mid-deal, mid-audit, or post-breach.
That is the exact work GVM Technologies does for founders every week:
- A technical inspection of what your site sends, and to whom
- A one-page data map of every system holding personal data
- A privacy policy rewritten to match, with the CCPA and state-law language your regions need
- Consent gating that actually holds trackers until the user agrees
Our processes are ISO 27001:2022, ISO 20000-1:2018, and ISO 9001:2015 certified, which is often what clears a client’s next security review.
Book a privacy and cookie audit with GVM Technologies →
FAQs
1. Is a privacy policy legally required for a small website?
Yes, in almost every case. If you collect anything that identifies a person, including a newsletter email or an IP address in server logs, at least one law requires a privacy policy. Audience size changes your enforcement risk, not the requirement.
2. Does a privacy policy generator make my site compliant?
No, it produces a draft. A generator cannot see your live site, so the output is compliant only if it happens to match your real practices. Build a data map first, then audit the result against your site.
3. Do I need a cookie banner if I only use essential cookies?
No banner, but you still need disclosure. Strictly necessary cookies can be set without consent, though you still describe them in a cookie section. Add analytics or ad pixels and you need prior consent plus a banner that actually blocks them.
4. Do US businesses need to follow GDPR?
Potentially yes. GDPR applies based on whose data you process, not where your company is registered. Offer a service to people in the EU or run analytics on EU visitors, and you are in scope even with no EU office.
5. What happens if my privacy policy is not compliant?
It depends on your business. A B2B company usually loses an enterprise deal, a US consumer site faces a lawsuit over undisclosed trackers, and an EU store gets an order to fix. After a breach, an overclaiming security section becomes evidence.
6. Can I copy another company’s privacy policy?
No. Their policy describes their vendors, transfers, retention, and lawful bases, so copying it makes yours confidently wrong. You also inherit commitments you may not meet, such as a named DPO or a specific response time.
