GDPR and your website: what you are responsible for as the owner

A contact form, a newsletter sign-up, an appointment booking, a customer account in your shop. Each of them collects a name, an email address, sometimes a phone number. Under GDPR that is personal data, and your business is its controller.

Many owners assume that because an agency built the site and a hosting company runs the server, security is their problem. It does not work that way. The developer and the host have duties of their own, but you, as the controller, answer to the regulator and to your customers.

Here is what the rules expect from you as the owner, in plain language. This is not legal advice, so for anything unusual, ask a lawyer or your data protection officer.

Who is who on your website

GDPR splits the people involved into two roles. The controller decides why and how the data is collected. That is your business. A processor handles the data on your behalf: the hosting company whose server holds the database, the developer or agency with access to the admin panel, the newsletter tool, the booking system.

This has practical consequences. If the agency neglects updates and someone steals the form submissions, you report the breach, tell your customers and answer the regulator's questions. You settle things with the agency afterwards, under your contract, if you have one.

Article 32: security that matches the risk

Article 32 does not tell you which plugin to use or how long a password should be. It asks for "appropriate technical and organisational measures", meaning measures that fit the risk. It gives a few examples: encryption, keeping data confidential and available, being able to restore it quickly after an incident, and regularly testing whether your security actually works.

On a small business website that translates into fairly down-to-earth things:

• the whole site runs on HTTPS, and no form sends data over plain http,
• the CMS, theme and plugins are updated on a schedule, not whenever someone remembers,
• only people who really need the admin panel can log in, and they use two-factor login,
• backups are stored away from the website's server, and someone has checked that a restore works,
• old form submissions are not kept in the database for years without a reason,
• every so often someone checks the site from the outside, for example with a security scanner, and writes down the result.

The last point is the easiest to skip, yet it answers the "regular testing" requirement directly. If the regulator ever asks how you look after security, a note saying "tested on 3 March, two issues, fixed on 10 March" beats any assurance that the site is probably fine.

72 hours to tell the regulator

A personal data breach does not have to be a dramatic hack. It can be an export of form submissions that anyone could download from a public address. A hijacked admin account. An email to all your customers sent with their addresses in CC instead of BCC.

Article 33 says the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. In Poland that authority is UODO, in the UK the ICO (UK GDPR kept the same rule), in Ireland the Data Protection Commission. These are clock hours, so a weekend does not pause them. You only skip the notification when the breach is unlikely to result in a risk to the people whose data it is.

Two things should make this less daunting. You do not need the full picture straight away: the rules let you provide information in phases, so it is better to report what you know on time and add the rest later than to wait for a complete report from your developer. And most authorities take notifications through an online form on their website.

A late notification has to explain the delay. So agree with whoever looks after your site that you hear about any suspected leak on the same day. A processor must tell you without undue delay, but the decision to report is yours, and so is the deadline.

When you have to tell your customers

Article 34 goes one step further. If a breach is likely to result in a high risk to the people affected, you must tell them too, again without undue delay. In plain language: what happened, what the likely consequences are, what you have done, and what they should watch out for, such as emails pretending to come from your business.

High risk means things like leaked passwords to customer accounts, national ID numbers, health information from a clinic's registration form, or a law firm's client list with notes about their cases. An email address from a newsletter sign-up usually weighs less, but the assessment always depends on the situation.

There are exceptions. You do not have to notify people if the data was encrypted so that no outsider can read it, or if you acted straight away in a way that makes the high risk unlikely to materialise. Where contacting everyone individually would take disproportionate effort, a public announcement can be used instead.

A processing agreement with your host and developer

Anyone who handles personal data on your behalf should have a data processing agreement with you (Article 28). It does not have to be a thick document. Larger hosting companies and newsletter tools usually have a ready-made DPA in their dashboard or terms of service. You accept it and keep a copy.

With freelancers and small agencies, often nobody has thought about it. The agreement says, among other things, that they process data only on your instructions, keep it secure, help you if there is a breach, and delete or return the data when you stop working together. Add the practical details: who the contact person is, which channel they use to report an incident, and how quickly.

What to keep in writing

GDPR is built on accountability. Complying is not enough, you have to be able to show it. For a business website that means one folder, on paper or on a shared drive:

1. Processing agreements with your host, your developer or agency, and every tool that receives data from your forms.
2. A short description of your security: what gets updated and by whom, where the backups are, who has admin access.
3. The results of periodic checks on the site, and a note of what was done about them.
4. A breach log. Article 33 requires you to document every breach, including those you decide not to report: what happened, what the effects were and what you did. For unreported ones, note why you decided not to report them.
5. A record of processing activities, if it applies to you. The exemption for organisations with fewer than 250 employees is narrower than it looks: it does not cover processing that is more than occasional, and a form that brings in enquiries every week is hard to call occasional.

None of this needs a big budget. It needs a clear agreement on who does what before anything happens. During an incident, 72 hours go very quickly, especially if you spend the first day working out who has access to the server.