Blog
11 min readVisitTrack Team

GDPR for Site Owners: A Practical Guide, No Legal Jargon

What you concretely need to do as a small or mid-sized site operator to be GDPR compliant — from lawful basis and your privacy policy to DPA agreements with your vendors and visitors' access or erasure requests.

GDPR isn't just the cookie banner your visitors see — that's the visible tip of a much broader set of obligations for anyone collecting data about people through a website. This guide is written for the site operator without a legal department: what you concretely need to do, in what order, and what you can safely put off.

1. Find out what data you're actually collecting

The first step, before any legal text, is a real inventory. Most sites collect more categories of data than they think: email addresses from a contact form or newsletter, traffic data from analytics, payment data from your card processor, possibly account data if you have authentication. For each category, note down: what you collect, why, how long you keep it, and who else has access to it (your hosting provider, email provider, analytics provider, payment processor).

This inventory is the foundation for everything that follows — you can't write an accurate privacy policy, respond to an access request, or sign the right agreements with your vendors if you don't know exactly what you have.

2. Establish the lawful basis for each type of processing

GDPR requires an explicit lawful basis for any processing of personal data. In practice, for a typical site, almost everything falls into one of three categories:

  • Consent — for anything that isn't strictly necessary: newsletters, advertising pixels, marketing cookies. It must be an affirmative action, easy to withdraw, and never pre-checked.
  • Performance of a contract — the data needed to deliver what the customer ordered (shipping address, invoice, access to a paid account). You don't need separate consent for this.
  • Legitimate interest — aggregate traffic statistics, fraud prevention, site security. You need to be able to justify why your interest doesn't override the visitor's rights, and the visitor needs a way to opt out.

Aggregate traffic analytics, without cross-site tracking cookies, typically falls under legitimate interest rather than consent — we go into exactly why in our article on cookie-free analytics. A contact form falls under performance of a contract or legitimate interest, depending on the context. Marketing emails almost always need explicit consent (opt-in), not just a pre-checked box.

3. Write a real privacy policy, not a generic template

Your privacy policy needs to reflect the inventory from step 1, not text copied from another site. At minimum, it should contain:

  • Who the data controller is (your name / your company's name, contact details).
  • What categories of data you collect and through what means (forms, analytics, cookies, payments).
  • The lawful basis for each category.
  • How long you retain each category of data.
  • Who you share the data with — including your technical vendors (hosting, email, analytics, payment processor).
  • How a visitor can exercise their rights (access, rectification, erasure, portability, objection) and what contact address to use.
  • Whether you transfer data outside the European Economic Area, and on what legal basis (typically standard contractual clauses).

4. Sign a DPA with every vendor that processes data on your behalf

If a technical vendor (hosting, analytics, transactional email, payment processor) processes personal data on your behalf, GDPR requires a Data Processing Agreement (DPA) — a contract separate from the usual commercial terms, which sets out what the vendor can and can't do with your data. Most reputable vendors have a standard DPA available on request or directly in your account; check the legal/GDPR page of every vendor you use. You don't need a DPA for a vendor that never sees personal data at all (for example, a CDN that only serves static files, with no cookies or visitor logging).

5. Minimize retention — delete what you no longer need

The data minimization principle means, in practice: don't keep data “just in case we need it someday.” Set an explicit retention period for each category (for example: raw traffic data for 14-24 months, then aggregate only; newsletter email addresses until unsubscribe; server access logs for 30-90 days) and set up automatic deletion wherever your vendor supports it.

6. Be ready to respond to visitor requests

Any visitor or customer has the right to request access to their data, its rectification, its erasure, or a portable copy — and you're obligated to respond within 30 calendar days at most. For a small site, that doesn't mean a complex automated system: a clear process (a dedicated contact address, an internal workflow to search + export/delete across every system where you hold data about that person) is enough. What matters is not ignoring the request — failing to respond is itself a violation, regardless of how little data is involved.

7. Have a minimal plan for security incidents

If a security breach occurs that exposes personal data (a compromised database, a publicly exposed backup, an email mistakenly sent to an entire list in CC), you're obligated to notify the supervisory authority within 72 hours of becoming aware of it, if the breach poses a risk to the affected individuals' rights. You don't need a 20-page plan — you just need to know in advance who decides, how to contact the authority, and how to notify affected individuals if the risk is high.

What you can safely put off

For a small site without sensitive data (no medical data, detailed financial data, or data about minors), the biggest practical risk isn't an out-of-the-blue fine — it's a complaint from an unhappy visitor or an audit triggered by an incident. Prioritize your data inventory, an accurate privacy policy, and a reasonable response process for requests — the rest can be built incrementally.

Note: this is a practical guide, not personalized legal advice. For a case involving sensitive data, a large volume of users, or complex international transfers, consulting a lawyer specialized in data protection is still recommended.