You added Google Analytics, set up a contact form, and installed a cookie banner. You found a privacy policy template online, filled in your site name, and called it done. That template almost certainly does not satisfy GDPR.
A generic privacy policy covers the broad strokes of data collection. A GDPR-compliant policy does something more specific: it names a data controller, assigns a legal basis to each type of processing, lists all eight user rights with instructions for exercising them, names every third-party service receiving personal data, and discloses where that data goes when it leaves the EU. Most templates skip most of these.
The privacy policy generator handles GDPR-specific requirements automatically when you configure it for EU users. This guide explains what GDPR actually requires, why the requirements exist, and what each section of your policy needs to say to satisfy them.
This article is for informational purposes only and does not constitute legal advice. For complex compliance situations or high-risk data processing, consult a qualified privacy lawyer.
What GDPR Is and Which Websites It Applies To
The General Data Protection Regulation is an EU law that governs how organizations collect, store, and use personal data of people in the European Union and European Economic Area. It came into force in May 2018 and applies in all EU member states without needing to be passed into national law.
The territorial scope is the part most non-EU website owners miss. GDPR applies based on where your users are, not where you are. A US-based business with EU visitors is subject to GDPR. An Australian app used by German customers is subject to GDPR. A Canadian blogger with subscribers in France is subject to GDPR. Your server location does not matter. Your business address does not matter. The location of the person whose data you process is what matters.
Personal data under GDPR is defined broadly. Names and email addresses qualify, obviously. But so do IP addresses, cookie identifiers, device fingerprints, behavioral data, location data, and anything else that can be linked back to a specific individual, even indirectly. The moment your analytics tool logs the IP address of a visitor from Berlin, you are processing personal data under GDPR.
The practical conclusion for most websites: if you have any international traffic, treat GDPR as applicable. Building compliance into your policy costs an afternoon. Rebuilding your legal exposure after a data protection complaint costs considerably more.
What a GDPR Privacy Policy Must Include
Under GDPR Articles 13 and 14, when you collect personal data, you must provide specific information to the person whose data you are collecting. For websites, this disclosure happens through the privacy policy. These are the required elements.
Identity of the data controller. The data controller is the person or organization that decides why and how personal data is processed. For most websites, that is you. GDPR requires your full name or business name, your address or country of establishment, and a contact email specifically for data protection requests. "The company" or "we" without identifying details does not satisfy this requirement.
Categories of personal data and the source. List every type of personal data you collect and how you collect it. Contact form data, analytics data, newsletter subscription data, account registration data, payment data. State whether it comes directly from users or is collected automatically.
The purpose and legal basis for each type of processing. This is where most generic policies fail. You must state why you process each category of data and which of the six legal bases applies to each purpose. Analytics processed under legitimate interests requires different disclosure than newsletter data processed under consent.
Third-party recipients. Every organization that receives personal data from your site must be named. Your analytics provider, email marketing platform, payment processor, cloud hosting provider, and any embedded third-party widgets. Describe what data each receives and why.
International data transfers. If any data is transferred outside the EU or EEA, disclose the destination and the safeguard mechanism. Most US-based services are covered by the EU-US Data Privacy Framework or Standard Contractual Clauses.
Retention periods. How long you keep each category of data before deleting or anonymizing it.
All eight data subject rights. What each right is, the conditions under which it applies, and how users can exercise it.
Contact information for data requests. An email address users can write to with access requests, deletion requests, and other rights-related queries.
The 8 GDPR Data Subject Rights You Must Acknowledge
Your privacy policy must list all eight rights. These are not optional disclosures. They are legally enforceable entitlements your users hold against you.
Right to be informed. Users have the right to know what data you collect and how you use it before or at the time of collection. The privacy policy is how this right is satisfied for website visitors.
Right of access. Any user can submit a Subject Access Request asking for a copy of all personal data you hold about them. You have one calendar month to respond, free of charge. Your policy must state how to submit such a request and who to send it to.
Right to rectification. Users can request correction of inaccurate data you hold about them. You must comply within one month. Particularly relevant for sites with user accounts or stored profiles.
Right to erasure. Users can request deletion of their personal data under specific conditions: the data is no longer needed for the original purpose, they withdraw consent, they object to processing, or the data was processed unlawfully. Your policy must explain how to make this request.
Right to restrict processing. Users can request a pause on processing while they contest accuracy or pending a determination of legitimate grounds. Processing restriction means the data is stored but not actively used.
Right to data portability. Where processing is based on consent or contract, users can request their data in a machine-readable format (such as CSV or JSON) to transfer to another service. Applies to any structured data you hold in a user profile or account.
Right to object. Users can object to processing based on legitimate interests, including profiling and direct marketing. If they object to direct marketing, you must stop immediately with no balancing test. For other legitimate interests processing, you must stop unless you can demonstrate compelling grounds.
Rights related to automated decision-making. Users have the right not to be subject to solely automated decisions that produce significant effects on them. This applies to automated credit scoring, algorithmic hiring systems, and similar. For most small websites it is not triggered, but the right must still be disclosed.
Legal Bases for Processing: Which One Applies to Your Site
GDPR Article 6 prohibits processing personal data unless at least one of six legal bases applies. This is not a formality. You must identify the specific basis for each category of processing and state it in your policy.
Consent. The user has given freely given, specific, informed, and unambiguous consent through a clear affirmative action. Newsletter signups with a deliberately unchecked opt-in box are the standard example. Pre-ticked boxes and implied consent do not satisfy GDPR's consent standard. Consent must be as easy to withdraw as to give.
Contract. Processing is necessary to perform a contract with the user, or to take steps before entering a contract at their request. An e-commerce site processing a delivery address to fulfill an order uses this basis. A software provider processing account data to deliver a paid service uses this basis.
Legal obligation. Processing is necessary to comply with a legal requirement you are subject to. Retaining invoices for the required period under tax law is a common example. This basis only applies where law specifically requires the processing.
Vital interests. Processing is necessary to protect someone's life. This applies in genuine emergency health situations. For standard website operations it almost never applies.
Public task. Processing is necessary for a task in the public interest or for an official authority function. Applies primarily to public sector bodies and organizations carrying out official responsibilities. Most private websites cannot rely on this basis.
Legitimate interests. Processing is necessary for your legitimate interests, provided those interests are not overridden by the user's fundamental rights. This is the most commonly applicable basis for typical website analytics, security monitoring, fraud prevention, and standard business communications. It requires a legitimate interests assessment: identify the interest, confirm processing is necessary for it, balance it against user rights.
One practical note: many websites set all processing to consent by default because it sounds the safest. It is not. Consent requires you to stop processing the moment it is withdrawn, and you must maintain records of each consent given. Legitimate interests, applied correctly to analytics and functional monitoring, creates fewer operational complications for most small sites.
Data Breach Notification Under GDPR
GDPR imposes a 72-hour notification requirement for personal data breaches. If a breach is likely to result in a risk to users' rights and freedoms, you must notify your supervisory authority within 72 hours of becoming aware of it. If the breach poses a high risk to individuals, you must also notify the affected users directly without undue delay.
A data breach under GDPR is broader than most people assume. It includes not just unauthorized access by external attackers but also accidental loss, destruction, or unauthorized alteration of personal data. Accidentally sending a newsletter to a list that includes a segment it should not have reached is a data breach. Losing a laptop containing customer data is a data breach. Accidental deletion without backup is a data breach.
Your privacy policy does not need to describe your breach response procedures in full detail. It should confirm that you maintain appropriate technical and organizational security measures to protect personal data, and that you will notify affected users when a breach creates a high risk to their rights.
The 72-hour window is strict. Know which data protection authority covers your situation before an incident happens. For businesses established in the EU, it is the authority in your member state. For non-EU businesses with EU users and no EU establishment, the situation is more complex. GDPR technically requires non-EU businesses processing EU data to appoint an EU representative, which is a step many small websites skip.
International Data Transfers and US-Based Tools
Most small websites use at least one US-based service. Google Analytics, Mailchimp, AWS, Stripe, Cloudflare. All of them involve transferring personal data of EU visitors to the United States, which GDPR treats as a transfer to a third country requiring specific disclosure and safeguards.
The main safeguard mechanisms your policy should reference:
EU-US Data Privacy Framework. The European Commission adopted this framework in 2023 to allow certified US companies to receive EU personal data. Google, Meta, Microsoft, and most major enterprise software providers are certified. Your policy can state that a service "relies on the EU-US Data Privacy Framework" for transfers to the US.
Standard Contractual Clauses (SCCs). EU Commission-approved contractual provisions between data exporters (you) and data importers (the US service). Many services not covered by the Data Privacy Framework use SCCs. Their data processing agreements will state which mechanism they rely on.
Adequacy decisions. The EU Commission has recognized certain countries as providing adequate protection equivalent to GDPR: the UK, Switzerland, Japan, Canada (for commercial organizations), and others. Transfers to these countries need no additional safeguard.
For most small websites, the disclosure looks like: "We use [Service Name] to process [type of data]. [Service Name] is based in the United States. Data is transferred under the EU-US Data Privacy Framework. You can review [Service Name]'s privacy policy at [link]."
You need one of these disclosures for every US-based service that handles personal data from your site.
How to Create a GDPR-Compliant Privacy Policy Free
A GDPR-compliant privacy policy is not a document you can copy from another site. It needs to reflect your specific data practices: which tools you use, what data they collect, which legal basis applies to each type of processing, and how long you retain each category. Generic templates fail because they describe someone else's site, not yours.
Before using the privacy policy generator, audit what your site actually does:
- List every form that collects data and what fields it includes
- List every third-party service installed (analytics, advertising, email, payments, chat, CDN)
- Note whether you have EU users (assume yes if you have any non-local traffic)
- Identify how long you realistically keep each type of data
- Confirm whether any processing involves consent as the legal basis, and whether your consent mechanism actually satisfies GDPR's standards
The generator takes these inputs and produces a complete policy with GDPR-specific language configured to your disclosed practices. Configure it accurately. A policy stating you do not use analytics when Google Analytics is installed creates worse legal exposure than no policy at all.
For everything else the site needs alongside a privacy policy, the documents section has a terms of service generator and a disclaimer generator in the same place. The terms of service generator guide explains which site types need terms and what they should cover. Most sites handling user content, accepting payments, or providing any kind of service need both a privacy policy and a terms document. Neither is optional for a site that takes compliance seriously.
