For data protection leads, trustees and site owners
GDPR Article 32 — the part a regulator can check without asking.
Article 32 asks for appropriate technical measures and deliberately does not list them. A handful are visible from outside your organisation, and those are the ones anyone can test for themselves.
Article 32 of the UK and EU GDPR requires 'appropriate technical and organisational measures' to keep personal data secure. It deliberately does not list them, which is what makes it hard to self-assess. A handful of those measures are visible from outside your organisation, and those are the ones a regulator, a customer or a journalist could check without asking your permission. This page explains which they are and how to close the common gaps.
Who it applies to
The UK GDPR applies to organisations established in the UK, and the EU GDPR to those established in the EU — and both reach organisations elsewhere that offer goods or services to, or monitor the behaviour of, people in those territories. Size is not a threshold. A charity with a mailing list, a school with a parent portal and a sole trader with a contact form are all processing personal data and all fall under Article 32.
- There is no employee-count or turnover exemption from Article 32
- A website contact form and a newsletter are both personal-data processing
- Serving UK or EU residents can bring you in scope wherever you are based
Why 'appropriate' is the difficult word
Article 32 asks for measures appropriate to the risk, taking account of the state of the art and the cost of implementation. That is deliberately flexible, and it means nobody can hand you a definitive checklist. What it does not mean is that anything goes: measures that are inexpensive, widely adopted and directly protective of the people whose data you hold are difficult to argue against — and those are exactly the ones an outside observer can see.
- Cheap, standard and protective is the combination that is hard to justify skipping
- Anything visible from outside is visible to a complainant as well as to you
- Documenting a decision not to do something is worth more than silence
What an outside check can see — and what it cannot
Most of Article 32 is internal: access control, staff training, processor contracts, retention schedules, breach procedures, encryption at rest. None of that is externally verifiable and none of it appears here. What is visible is how personal data travels between a visitor and your website, and whether the public-facing signals of a well-run service are present.
- Visible: transport security, privacy information, consent mechanism, page composition, disclosure route
- Not visible: data processing agreements, retention, staff access, internal encryption, breach procedures
- A clean external result is a starting point for a Record of Processing, not a substitute for one
What this check looks at
Each item is read from your public website without any intrusive testing, and each maps to something an outside party could reasonably expect to find.
- HTTPS redirect — personal data submitted over plain HTTP travels unprotected, and a form that loads insecurely undermines everything after it
- Privacy policy reachable — people have a right to information about how their data is used, and it has to be findable
- Cookie consent mechanism — where consent is required, there has to be a genuine mechanism for giving and refusing it
- Mixed content — a secure page that pulls in insecure resources weakens the protection the padlock implies
- Vulnerability disclosure route — a documented way for someone to report a problem to you, so a finder is not left guessing
- Third-party trackers — what else loads on the page, because every embedded service is another recipient of your visitors' data
Where organisations usually fall short
The recurring gaps are rarely the result of a decision. A privacy policy exists but sits behind a link that broke in a redesign. A consent banner is present but loads trackers before anyone has answered it. A site enforces HTTPS on the main pages and not on an old subdomain that still has a form on it. None of these are difficult to fix; they are difficult to notice from the inside.
- Check the forgotten subdomains — old campaign sites and staging hosts often still collect data
- Look at what loads before consent is given, not just whether a banner appears
- Re-check after every redesign; policy links break quietly
Common questions
›Does Article 32 apply to a small charity or a sole trader?
Yes. There is no size threshold. What changes with size is what counts as 'appropriate' — the measures expected of a two-person charity are not those expected of a bank — but the obligation itself applies to anyone processing personal data.
›Is a clean result here the same as being GDPR compliant?
No, and it would be misleading to treat it that way. This checks a small, externally visible subset of Article 32 only. It cannot see your processing agreements, retention practices, access controls or breach procedures, and it says nothing about lawful basis, data subject rights or any other part of the regulation.
›We use a consent banner. Is that enough?
A banner is the mechanism, not the outcome. What matters is whether refusing is as straightforward as accepting, and whether anything that requires consent actually waits for it. A banner that appears while trackers have already loaded is a common and visible failure.
›Why does a vulnerability disclosure route matter for GDPR?
Because a security researcher who finds a problem with your site needs somewhere to send it. Without a published route, reports go to whatever address they can find, or nowhere — and a vulnerability you were never told about is harder to argue you took appropriate measures against.
Advisory only. This is an external technical check of a small, externally visible subset of GDPR Article 32. It is not a compliance assessment, not legal advice, and it does not evaluate organisational measures, processing agreements, lawful basis or data subject rights.
Also useful: our own GDPR commitment.