Privacy policy, cookie banners, and GDPR/CCPA for a small business site

Do you legally need a privacy policy?

There is no single American law that says every website must have a privacy policy. That fact gets repeated a lot, usually by someone about to argue they do not need one. It is technically true and practically useless, because the obligation arrives through four separate doors and you only have to walk through one of them.

The first door is state law. California's Online Privacy Protection Act has required a conspicuously posted policy since 2004 from any commercial website that collects personally identifiable information about California residents. It has no revenue threshold and no size test. If a Californian can fill in your contact form, you are inside it. The newer generation of state privacy statutes all carry a similar notice requirement, and Nevada and Delaware have long had their own versions.

The second door is European law, which reaches across borders in defined circumstances covered in the GDPR section below. The third door is federal consumer protection law: the Federal Trade Commission treats a false or misleading statement about your data practices as a deceptive practice under Section 5 of the FTC Act, which is exactly why publishing an inaccurate policy is worse than publishing none.

The fourth door is the one nearly everyone has already walked through without noticing. The tools on your site require a policy contractually. Google's terms for Analytics and Ads require you to publish one and to disclose your use of cookies. Meta's business terms say the same for the Meta Pixel. Mailchimp, Stripe, Calendly, and every embedded booking widget you have ever installed carry equivalent clauses. You agreed to all of them at signup.

What on your site is collecting data

Before you can write an accurate policy you need an inventory, and most owners underestimate theirs by a wide margin. Data collection on a website falls into three buckets, and the third one is where the surprises live.

The first bucket is obvious. Someone types their name and email into a form and presses send. You know that happened because the email arrives. Under every privacy law on earth that is personal information and it needs to be disclosed, retained on a defined schedule, and deleted on request. Nothing subtle here.

The second bucket surprises people. Every web server keeps access logs, and an IP address is personal data under GDPR and personal information under most of the US state statutes. You are not doing anything wrong by keeping logs, since security and abuse prevention are legitimate reasons to keep them, but you do need to say so and you do need a retention period rather than keeping them forever by accident.

The third bucket is where sites get into trouble, because third party code collects data on page load whether or not anyone touches it. An embedded YouTube video contacts Google before a visitor presses play. An embedded Google Map does the same. A hosted web font pulls from a font provider and hands over the IP address to do it, which is exactly what a German court found against a site owner in the widely cited Google Fonts decision. A live chat widget usually sets its own cookies. A review carousel from a third party platform loads their tracking with it.

Auditing this takes about twenty minutes and no special tools. Open your site in a private browsing window, open your browser's developer tools, look at the network tab, and reload the page. Every domain in that list other than your own is a third party receiving data about your visitor. Then check the storage tab for cookies. Most small business sites that have been running for a few years turn up between six and fifteen outside domains, and the owner can usually explain about half of them. If you want the same inventory for measurement specifically, the analytics guide walks through what each tag is actually doing.

GDPR: when a US business is actually in scope

GDPR is the source of most of the panic and most of the bad advice. The panic comes from the penalty ceiling, which is up to 20 million euros or 4 percent of global annual turnover, whichever is higher. The bad advice comes from consultants who tell every American business that a website reachable from Europe puts them in scope. That is not what the regulation says.

Article 3 extends GDPR to organisations outside the EU in two situations: when you offer goods or services to people in the EU, whether or not you charge for them, and when you monitor the behaviour of people in the EU. Recital 23 then says directly that the mere accessibility of a website from the EU is not sufficient to establish the first one. The test is whether it is apparent that you envisage offering services to people there.

So a roofing contractor in Tulsa with a five page site, a contact form, and no analytics is not in scope under any sensible reading. Add Google Analytics and a Meta Pixel and the picture gets muddier, because you are now profiling everyone who visits, including the occasional European. Sell a downloadable product to anyone with a card, and you are in scope without ambiguity.

If you are in scope, the obligations that bite hardest for a small business are the transparency notice, having a lawful basis for each purpose you process for, honouring access and deletion rights inside one month, and reporting a personal data breach to a supervisory authority within 72 hours of becoming aware of it. That last one is worth internalising, because 72 hours is not long enough to start figuring out what your site stores. Knowing that in advance is part of what basic website security buys you.

CCPA and the rest of the US state laws

The United States has no comprehensive federal privacy law, so the obligations come state by state. Roughly twenty states have comprehensive consumer privacy statutes in force as of 2026, and more take effect each year. They rhyme with each other without being identical, which is the whole problem.

California came first and remains the strictest. The California Consumer Privacy Act, as amended by the California Privacy Rights Act, applies to a for profit business doing business in California that meets at least one of three thresholds.

Statutory penalties under CCPA start at $2,500 per violation and rise to $7,500 for intentional violations or violations involving a minor, with the California Privacy Protection Agency adjusting those figures for inflation. Per violation means per consumer, which is how the arithmetic gets alarming quickly for a company that clears the thresholds.

Most small businesses clear none of the three tests and are simply out of scope in California. That is a real answer and you are allowed to rely on it. Two things stop it from being the end of the story.

First, the other states set their own bars. The common pattern, which Virginia established and Colorado, Connecticut, and most of the rest copied, is 100,000 residents' data in a year, or 25,000 residents' data combined with deriving a meaningful share of revenue from selling it. Florida's threshold is enormous and aimed at large platforms. Texas went a different way entirely: it applies to anyone doing business in Texas who processes personal data and does not qualify as a small business under the federal Small Business Administration definition, with no revenue or volume floor. If you are genuinely an SBA small business you are outside it, but the test is your size and not your data volume, which is a meaningfully different question.

Second, the rights themselves are converging even where the thresholds differ. Access, deletion, correction, portability, an opt out of targeted advertising and of the sale or sharing of data, opt in consent for sensitive categories, and a ban on retaliating against someone for exercising any of them. If you decide to honour those rights voluntarily, you have built a posture that satisfies most states at once, and you have removed the need to re-audit your obligations every time another legislature passes a bill.

One mechanism deserves specific attention: the Global Privacy Control. It is a signal a visitor's browser sends automatically to say they are opting out of the sale and sharing of their information. California and Colorado require covered businesses to honour it, and it arrives silently in the request headers rather than through your banner. A business that answers banner clicks but ignores GPC has an opt out mechanism that only works for people who did not bother to configure one. Our own do not sell or share page exists for exactly this reason, even though we do not sell anything.

Cookie banners: what they must do, what most get wrong

Cookie banners have become the most visible and least understood part of web privacy. The great majority of them are decorative. They appear, the visitor clicks whatever makes them go away, and nothing about the site's behaviour changes. That is not a neutral outcome, because the banner is a written record that you knew consent was required.

Start with what does not need consent. Strictly necessary cookies are exempt everywhere: the session cookie that keeps someone logged in, the shopping cart that remembers what they added, the security token that stops form submissions from being forged, the load balancer cookie that keeps them on the same server. You never need permission for these and you should never put them behind a banner.

Everything else needs handling. Analytics cookies, advertising and retargeting pixels, social media embeds, session recording and heat mapping tools, A/B testing scripts, and most chat widgets are all non essential. Under the EU ePrivacy rules, consent must be obtained before those trackers are set, not after the page has loaded them.

• Reject is as easy as accept. Both choices on the first screen, same visual weight. Burying rejection two clicks deep behind a settings panel is the single most cited banner failure in European enforcement.
• Nothing is pre-ticked. The Court of Justice of the European Union settled this in the Planet49 case: a pre-checked consent box is not consent.
• Scripts genuinely wait. The tracking code does not run until the visitor says yes. This is a build detail, not a banner setting, and it is where most implementations fail.
• Withdrawal is as easy as giving. A persistent way to change the answer later, usually a small link in the footer.
• The banner has categories rather than one all-or-nothing switch. Not strictly required everywhere, but expected under EU practice and a good idea regardless.
• You keep a record of who consented to what and when. Under GDPR you must be able to demonstrate consent, which means logging it, not just acting on it.
• A banner with only an accept button, or one that says continued use of this site means you agree. Neither is consent under any European reading, and both are common on US small business sites.
• A banner sitting on a page whose analytics fired on load. This is the most common configuration in the wild and the least defensible.

There is a strategic decision hiding underneath the implementation detail. Every consent banner is a conversion cost. It covers your page before the visitor has read a word, it adds a rendering delay, and a meaningful share of visitors bounce rather than deal with it. If you are running advertising retargeting and building lookalike audiences, that cost may be worth paying. If your analytics stack exists because someone installed it during the build and nobody has opened the dashboard since, you are paying a real price in speed and conversions for data you do not use. Removing the trackers removes the banner requirement along with them, and it improves your Core Web Vitals as a side effect, since third party scripts are usually the heaviest thing on a page.

Two other implementation notes. If you advertise with Google and have any EEA traffic, Google Consent Mode v2 is a requirement rather than an option, and your consent tool needs to be passing those signals or your audience features stop working. And if you run a consent management platform, remember it is itself a third party that sees every visitor. Disclose it in your policy like any other vendor.

What belongs in your privacy policy

A privacy policy is not a legal shield. It is a factual statement about how your business handles data, and its usefulness depends entirely on being true. The clause list below is the floor. Getting the list right is the easy part. Keeping it accurate is the part that actually fails.

• What you collect, by category. Contact details, payment information, booking details, device and usage data, and anything you infer. Categories rather than an exhaustive field list.
• Where it comes from. Directly from the visitor, automatically from their browser, or from a third party such as an advertising platform or a lead source.
• Why you collect it. One stated purpose per category. Under GDPR you also name a lawful basis for each: consent, contract, legal obligation, or legitimate interests.
• Who you disclose it to. Categories of recipients, and in practice it helps to name the actual vendors. Your host, your email provider, your payment processor, your analytics provider, your booking tool.
• How long you keep it. A real schedule, per category. Form submissions for two years, server logs for 30 days, invoices for seven years because tax law says so.
• What rights people have and how to use them. A working email address or form, not a mailing address that nobody checks. Say how long you will take to respond.
• How you handle children's data. If your site is not aimed at children under 13, say so. COPPA is a separate federal statute with its own teeth.
• Where the data goes geographically. If your host, your CRM, or your email provider is in another country, say so. International transfer disclosure matters under GDPR and increasingly under state law.
• A last updated date and a change process. Undated policies read as abandoned, and a dated one is evidence of maintenance.

Now the part that fails. Almost nobody gets caught out by a missing clause. They get caught out because the policy describes a website that no longer exists. It mentions cookies the site stopped setting three years ago, says nothing about the booking system added last spring, promises deletion within 30 days when nobody has a process for deletion at all, and lists a privacy contact address that bounces because it belonged to an employee who left. Every one of those is a false statement about your data practices, and false statements about data practices are the FTC's actual enforcement lane.

This is why copying someone else's policy is a bad idea in a way that goes past the copyright problem. Copied text is a description of another company's vendors, retention periods, and legal bases, published under your name as though it were true. Template generators are better, but only as good as the inventory you fed them, and most people complete the questionnaire once at launch and never revisit it. Whichever route you take, the input is the inventory from the inventory section above, and the policy needs rechecking whenever the inventory changes.

Publish the policy at a stable, linkable address, link it from the footer of every page, and link it next to every form that collects information. You can see the pattern on our own privacy policy, and the same discipline applies to the other legal pages a site accumulates. Reviewing them is a normal part of what website maintenance includes, not a separate annual project.

When a data request arrives

Sooner or later someone emails to ask what you hold about them, or to demand you delete it. The requests are usually polite and rarely adversarial. What makes them stressful is that the deadline started running the moment the email arrived, and most owners spend the first two weeks working out where their data even lives.

The clocks are short and they differ. Under GDPR you have one month from receipt, extendable by two further months for genuinely complex requests provided you tell the person inside the first month. Under CCPA you must confirm receipt within 10 business days and substantively respond within 45 days, extendable by another 45 with notice. Most other US state laws land at 45 days with a 45 day extension. Assume 45 days and one acknowledgement inside 10 business days and you will satisfy nearly all of them.

1. Log it the day it lands day 0

   Date received, who from, what they asked for, and which law they invoked if they said. One row in a spreadsheet is enough for a small business. Every deadline runs from receipt, not from the day you noticed the email under a pile of quote requests.

2. Verify who you are talking to days 1–5

   You are obliged to verify, and equally obliged not to over-collect while doing it. Proportionality is the rule. For a newsletter unsubscribe, replying to the address on file is enough. For an account containing payment history, ask for confirmation of a detail only the account holder would know. Never demand a government ID for a low sensitivity request. Collecting sensitive identity documents to process a privacy request creates a new privacy problem of its own.

3. Find every copy days 5–20

   This is the step that consumes the time. Your form submission inbox, your CRM, your email marketing list, your booking system, your accounting software, your payment processor, your support tool, and your backups. If you already built the data inventory, you know where to look. If you did not, this is where the 45 days goes.

4. Apply the exemptions you are entitled to

   Deletion rights are not absolute. Records you must retain for tax, accounting, warranty, product safety, or legal defence purposes generally survive a deletion request, as do records needed to complete a transaction the person asked for. You do not delete a paid invoice because the customer asked you to. You do stop marketing to them, and you do say clearly what you kept and why.

5. Act, then write back describing exactly what you did

   Specific beats vague. Say which systems you searched, what you found, what you deleted or exported, what you retained and under which exemption, and what happens next. A precise answer closes the matter. A vague one invites a follow up, and a follow up to a regulator is how a small request becomes a large one.

6. Keep the record

   Store the request, your verification steps, what you did, and your response. Under GDPR you must be able to demonstrate compliance, and the same is true in practice under the state laws. The file is the proof, and it costs nothing to keep.

One thing worth deciding before a request arrives: whether you will honour requests from people outside the jurisdictions that legally cover you. Running two processes, one for Californians and one for everybody else, costs more than running one. Most small businesses find it cheaper and better for the relationship to answer everyone the same way, and it eliminates the need to work out where a requester was standing when they hit send. It is the same argument as keeping ownership of your own accounts: one clean arrangement is cheaper than several conditional ones.

Building a site so compliance stays cheap

Everything above gets cheaper or more expensive depending on decisions made when the site is built. Privacy compliance is mostly an architecture problem wearing a legal costume. Data you never collect cannot be breached, cannot be requested, cannot be deleted incorrectly, and does not need a paragraph in your policy.

That last point is the practical reason platform choice matters here. A page builder or plugin heavy stack loads third party code you did not choose and cannot inspect, and each plugin update can change what the page sends and to whom. That is a moving compliance target, and it is a large part of the argument in the WordPress versus custom comparison. A hand built site loads exactly what it was told to load, and the list of outside domains it contacts is a list you wrote on purpose. Our own custom PHP builds start at $1,200 for a single page and $2,800–$5,000 for a small multi page site, and a substantial part of what that buys is an inventory you can actually enumerate.

Where you host matters too, for two reasons that are easy to miss. Server log retention is a privacy setting whether or not anyone treats it as one, and the location of the server is a disclosure under GDPR. Managed hosting where somebody sets and documents both is worth having: our hosting plans start at $60/mo flat, and log retention and backup lifetime are configured deliberately rather than left at whatever the default was. If you would rather see how the numbers add up across a build, pricing and the cost guide break it down.

If you take one build decision away from this guide, make it this one: sites that collect and share the least are the cheapest to keep compliant, the fastest to load, and the least damaging when something goes wrong. Privacy, speed, and security stop being three separate projects once you notice they are the same decision viewed from three angles. The same is true of accessibility compliance: it is far cheaper as a build standard than as a retrofit. And if you are launching soon, the legal pages belong on your launch checklist alongside the redirects and the analytics, not in a follow up you never get to.

Website privacy questions

See all FAQs →