GDPR compliance guide for a small site or app (2026)
The GDPR applies to far more than EU companies. Under Article 3, it reaches any controller or processor that offers goods or services to, or monitors the behaviour of, people in the EU/EEA — regardless of where the business is based (European Commission — rules for businesses). A free newsletter, euro pricing, or an EU-language option is enough to pull a non-EU site into scope. This guide maps the core duties a small site or app actually owes, in the order regulators tend to check them. For the cookie-specific rules, see the cookie consent best-practices guide; for the data-map side, the data inventory / RoPA guide.
1. Lawful basis: you need one before you collect (Art. 6)
Every processing activity — a contact form, analytics, a mailing list — must rest on one of six lawful bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests (GDPR.eu — Art. 6). You pick the basis before you start, and you document it. For special-category data (Art. 9) you also need a separate Art. 9 condition. "We need the data" is not a basis. Consent must be freely given, specific, informed, and unambiguously withdrawal-capable — and is often the wrong choice when contract or legitimate interests fit better, because it creates ongoing withdrawal and re-consent overhead.
2. Transparency: a real privacy notice (Arts. 12–14)
At the point of collection you must tell people who you are, what you collect, why, your legal basis, retention, recipients, transfers, and their rights — in plain language, easily accessible (footer link on every page) (ICO — UK GDPR guidance). Copy-pasted boilerplate that doesn't match what you do is non-compliant. In 2026 the EDPB's CEF enforcement focus is squarely on transparency (Arts. 12, 13, 14), so mismatches between your notice and your actual data flows are a live risk.
3. Accountability records and data-subject rights (Art. 30; Arts. 15–22)
Maintain a Record of Processing Activities (RoPA) — the central accountability document supervisors ask for first (GDPR.eu — Art. 30; see the RoPA best-practices guide). Build working workflows for the eight data-subject rights (access, rectification, erasure, restriction, portability, objection, withdrawal of consent, and rights around automated decisions), most answered within one month. If you process on a scale or with technology that is likely to be high-risk, a DPIA / privacy risk assessment may also be required.
4. Security and breach response (Art. 32; Arts. 33–34)
Article 32 requires "appropriate technical and organisational measures" proportionate to the risk — encryption, access control, pseudonymisation, patching, MFA. You do not need perfect security, but you must show reasonable, documented steps. If a personal data breach occurs, notify your supervisory authority without undue delay and within 72 hours where it risks individuals' rights (Art. 33), and notify affected individuals directly if the risk is high (Art. 34). Keep an internal breach log even for breaches you don't escalate. The data breach prevention checklist expands this.
5. A pragmatic 8-step checklist
- Map your data collection points (forms, accounts, analytics, pixels) — see PII detection methods.
- Assign a lawful basis to each activity and write it down.
- Publish a tailored privacy notice linked in the footer of every page.
- Stand up valid cookie consent before non-essential scripts load.
- Build a RoPA (data inventory) and review it when anything changes.
- Sign Data Processing Agreements with every vendor that touches personal data (Art. 28).
- Implement security measures and a breach-response plan (Art. 32; Arts. 33–34).
- Check for DPIA triggers before launching high-risk features.
Decision-support note. PrivScan surfaces likely GDPR gaps on a live site or app — missing or weak consent banners, undisclosed trackers, and data-collection points — and returns a prioritized checklist you can hand to a developer or counsel. It is a scanner, not an auditor, and does not certify compliance.