What a DPO can check on a client's website without IT

If you work as a data protection officer or a GDPR consultant, you know the moment. The records of processing are in order, the privacy notices are written, the processor agreements are signed. Then you reach the website, and the review notes say "to be verified by IT". The client has no IT person, and the agency that built the site does not reply.

Yet the website is often the only system your client runs that accepts personal data from anyone on the internet: a contact form, a newsletter sign-up, an appointment booking. You can assess a good part of it yourself, with no admin access and no technical background. Here is how, and how to write it down.

What Article 32 asks of a website

Article 32 of the GDPR requires the controller and the processor to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk". Among its examples are encryption, the ongoing confidentiality, integrity, availability and resilience of systems, restoring data in a timely manner after an incident, and "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing".

For a public website that turns into a handful of concrete questions. Is form data encrypted on its way to the server? Is the software kept up to date? Could a stranger download files containing personal data? Does the site pass visitors' data to third parties without a legal basis? And does anyone check all this regularly and keep a record?

The last question ties in with accountability. Under Article 5(2), the controller is responsible for the principles in Article 5(1), including integrity and confidentiality, and must "be able to demonstrate compliance" with them. Article 39(1)(b) lists among a DPO's tasks monitoring compliance with the GDPR, including the related audits. A dated website review fits there comfortably. For the controller's side of things, including the 72-hour breach notification, see GDPR and your website.

What you can check yourself in 20 minutes

Everything below is what any visitor can do, so you need no access. If you want to run automated scanning tools against the site, ask the client first. Take a screenshot at each step, with the site address and the date visible.

1. The padlock and the certificate. Click the icon next to the site address and open the certificate details. Note who issued it and when it expires. Then type the address by hand with http:// instead of https://. The site should move to the https version on its own. If it stays on http, form data may travel unencrypted. The free SSL certificate checker covers the rest, including outdated protocol versions.

2. The privacy policy. Is there a link in the footer of every page and next to each form? Does it work, or does it lead to a 404? Does the policy name the controller that actually runs the site, and does it mention the tools you can see on it? A policy written years ago easily drifts away from a site that has since gained a chat widget or an advertising pixel.

3. Forms. Open every page that has a form and check for the padlock. A form embedded from another service, such as a booking system or a newsletter tool, is another recipient of the data and needs a processor agreement with the client. Check that a short privacy notice sits next to it, and that the form does not ask for more than its purpose needs. A national ID number field on a contact form is a conversation to have. Your contact form is a way in covers what else can go wrong with forms.

4. Cookies before consent. Open the site in a private window and leave the cookie banner alone. Press F12, go to the Application tab in Chrome or Edge, or Storage in Firefox, and open the cookie list. If analytics or advertising cookies are already there before you click anything, for example _ga from Google Analytics or _fbp from the Meta pixel, tracking starts without consent. Then click "Reject", reload, and see whether they disappear. The prior-consent rule comes from Article 5(3) of the ePrivacy Directive (2002/58/EC), as written into each country's law, rather than from the GDPR itself. The personal data those tools collect is a GDPR matter. For a quick first pass without F12, the cookies before consent check lists the cookies the server sets and the trackers in the page code. Cookies that scripts write later only show up in the browser.

5. Email on the domain. Put the client's domain into the SPF, DKIM and DMARC check. Without DMARC, anyone can send email that looks like it comes from your client, including to your client's own customers, asking for personal details or a payment. That is a breach risk which starts outside the website but uses the same domain.

6. Visible software versions. Press Ctrl+U to view the page source and search (Ctrl+F) for generator. You will often find something like WordPress 6.x. Compare the number with the current release on wordpress.org. A visible version number is not a vulnerability by itself, but an old version suggests nobody is updating the plugins either. If the tag is missing, that proves nothing, because it can be hidden.

What you cannot see from the outside

A browser review has limits, and your notes should record them just as they record the findings:

• backups: whether they exist, where they are kept and whether anyone has restored the site from one,
• admin accounts: who has administrator access and whether they use two-factor login,
• plugin versions that do not show in the page code, and who keeps them updated,
• what happens to a submission after it is sent: whether it stays in the database, for how long, and which inbox it lands in,
• server configuration, logs and how the database is protected,
• where the hosting is located and whether data leaves the EEA.

Turn these into questions for the client or their web developer, and write down who answered and when. No answer is a result too, and it goes into the notes.

How to record the review

A review note should hold up when someone asks a year later how you knew. Keep to one format:

1. Date and time, the site address, who checked and in which browser.
2. The list of items checked, each marked as fine, needs fixing, or could not be checked.
3. Screenshots for every item that needs fixing.
4. Who received the findings, when, and in what form.
5. The fix deadline agreed with the controller and the date of the follow-up check.

A record like this works for both sides. The client has evidence of the regular testing that Article 32(1)(d) asks for. You have evidence that you monitored and passed on your recommendations. The fix itself is the responsibility of the controller and whoever builds their website.

Repeat the review at least once a year and after any major change, such as a new web agency or a new online shop. Two dated reports show whether your recommendations were acted on.

When you have many clients

With a dozen or more clients, a manual review of every website starts to eat whole days. The outside part can be automated with ShieldWave. It checks each site the way anyone on the internet sees it, including exposed files, security headers and known vulnerabilities in software versions, and gives you a dated PDF report with a GDPR mapping. The technical part goes to the client's developer as it is, with no translation needed. The Pro plan costs $12 a month for up to 25 websites. It does not certify GDPR compliance and does not look inside the admin panel, so the questions in the section above are still yours to ask.