How does GDPR affect website security?

GDPR affects website security by turning it from a good habit into a legal obligation. If your website collects personal data from people in the EU (or the UK, under UK GDPR), you are required to protect that data with "appropriate technical and organisational measures", collect only what you need, control who can access it, and report serious breaches to your regulator within 72 hours. In practice, that means patching, encryption, access control, logging, and a breach response plan are no longer optional extras.

Many site owners think of GDPR as cookie banners and privacy policies. Those matter, but the security side of the regulation is where the real risk sits, because a hacked contact form database or a leaked customer list is exactly the kind of event GDPR was written to address. This article explains which parts of GDPR relate to security, what they mean for a typical website, and the concrete steps you can take on a WordPress or custom-built site to stay on the right side of the rules.

Note: this article is practical guidance, not legal advice. If you process sensitive data or operate at scale, talk to a data protection professional.

What Is GDPR and Who Does It Apply To?

The General Data Protection Regulation (GDPR) is the European Union's data protection law, in force since May 2018. The UK kept an almost identical version, known as UK GDPR, after leaving the EU. Both apply to any organisation that processes personal data of people in their territory, regardless of where the organisation itself is based.

For a website, "personal data" covers far more than you might expect:

• Names, email addresses, and phone numbers submitted through forms.
• IP addresses stored in server logs, comment records, or security plugin logs.
• Account usernames, hashed passwords, and profile information.
• Order histories, billing addresses, and shipping details.
• Cookie identifiers and analytics identifiers that can single out a visitor.

If your site has a contact form, a newsletter signup, user accounts, comments, or an online shop, and you have visitors from Europe, GDPR almost certainly applies to you.

Which Parts of GDPR Cover Security?

GDPR is a long document, but a handful of articles do most of the work when it comes to security.

Article 5(1)(f): Integrity and Confidentiality

One of GDPR's core principles is that personal data must be processed "in a manner that ensures appropriate security", including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage. This is the foundation: security is a principle of lawful processing, not an add-on.

Article 25: Data Protection by Design and by Default

You are expected to build privacy and security into your systems from the start. For a website, that means choosing plugins and services with security in mind, collecting the minimum data by default, and not leaving optional data fields switched on just because they exist.

Article 32: Security of Processing

Article 32 is the most directly relevant section. It requires "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk, and it names examples:

1. Pseudonymisation and encryption of personal data.
2. Confidentiality, integrity, availability, and resilience of your systems and services.
3. The ability to restore availability and access to data in a timely manner after an incident.
4. A process for regularly testing and evaluating the effectiveness of your security measures.

Notice that the law does not list specific tools. "Appropriate" is judged against the state of the art, the cost of implementation, and the risk to the people whose data you hold. A small blog with a contact form is not held to the same bar as a health clinic's patient portal, but both are expected to do what is reasonable.

Articles 33 and 34: Breach Notification

If you suffer a personal data breach that is likely to result in a risk to people's rights and freedoms, you must notify your supervisory authority within 72 hours of becoming aware of it. If the risk to individuals is high, you must also tell the affected people without undue delay. You are required to document all breaches internally, even ones you decide not to report.

Article 28: Processors

Your host, email provider, form service, analytics tool, and backup service are likely "processors" acting on your behalf. GDPR requires a written agreement (a Data Processing Agreement, or DPA) with each of them, and you are expected to choose processors that provide sufficient security guarantees.

Article 83: Fines

The highest tier of fines can reach up to 20 million euros or 4% of worldwide annual turnover, whichever is higher. In reality, most enforcement against small organisations involves warnings, orders to fix problems, or much smaller penalties, but the reputational damage of a publicised breach can be significant on its own.

What "Appropriate Security" Means for a Typical Website

Because GDPR does not give you a checklist, it helps to translate Article 32 into everyday website tasks.

Encryption in Transit and at Rest

• HTTPS everywhere: Every page, especially forms and login screens, should load over TLS. Redirect all HTTP traffic to HTTPS and enable HSTS once you are confident everything works.
• Encrypted backups: Backups contain full copies of your personal data. Store them encrypted and off-server, with restricted access.
• Encrypted storage for sensitive fields: If you store anything more sensitive than a name and email, consider encrypting those fields in the database rather than relying only on disk encryption.

Access Control

• Give each person their own account. Shared admin logins make it impossible to know who did what.
• Assign the lowest role that gets the job done. An editor does not need administrator access.
• Turn on two-factor authentication for every account that can see personal data.
• Remove accounts promptly when staff, freelancers, or agencies stop working with you.

Patching and Maintenance

Running a plugin with a publicly known vulnerability is one of the easiest ways to fail the "appropriate measures" test. A regulator is unlikely to be sympathetic if a breach happened through a flaw that had a patch available for months. Keep WordPress core, themes, plugins, PHP, and your server packages up to date.

Logging and Monitoring

You cannot report a breach within 72 hours if you never find out about it. Keep login logs, file change monitoring, and server logs so you can detect suspicious activity and investigate afterwards. Be aware that logs themselves contain personal data such as IP addresses, so set a sensible retention period.

Resilience and Recovery

Article 32 explicitly mentions restoring data after an incident. Regular, tested backups and a documented restore process count as a security measure under GDPR, not just a convenience.

Regular Testing

The law asks for a process for testing and evaluating your measures. For a small site, that can be as simple as a quarterly review of users, plugins, and backups, plus periodic vulnerability scans. Larger sites may commission a penetration test.

Data Minimisation Is a Security Control

The data you never collect cannot be stolen. GDPR's data minimisation principle (Article 5(1)(c)) is one of the most effective security controls available to you, and it costs nothing.

Ask these questions about every form and data store on your site:

• Do you need this field? If a contact form only needs an email and a message, remove the phone number and address fields.
• How long do you need it? Contact form entries from three years ago are a liability, not an asset.
• Does it need to live on the website at all? Many form plugins can email submissions and skip storing them in the database, or forward them to a CRM with stronger controls.

Stop Storing Commenter IP Addresses

WordPress stores the IP address of every commenter by default. Unless you rely on it for spam handling, you can stop saving it. Add this to a custom plugin or your child theme's functions.php:

<?php
/**
 * Do not store commenter IP addresses.
 */
function sajjad_remove_comment_ip( $ip ) {
    return '';
}
add_filter( 'pre_comment_user_ip', 'sajjad_remove_comment_ip' );

Be aware that some anti-spam services use the IP for scoring, so test that spam filtering still works after the change.

Automatically Delete Old Form Entries

If your form plugin stores entries as a custom post type, you can prune old ones on a schedule. The example below assumes entries are stored as a post type called sajjad_form_entry. Change it to match your plugin, and take a backup before you run anything that deletes data.

<?php
/**
 * Delete form entries older than 12 months, once per day.
 */
function sajjad_schedule_entry_cleanup() {
    if ( ! wp_next_scheduled( 'sajjad_delete_old_entries' ) ) {
        wp_schedule_event( time(), 'daily', 'sajjad_delete_old_entries' );
    }
}
add_action( 'init', 'sajjad_schedule_entry_cleanup' );

function sajjad_delete_old_entries() {
    $old_entries = get_posts(
        array(
            'post_type'      => 'sajjad_form_entry',
            'post_status'    => 'any',
            'posts_per_page' => 200,
            'fields'         => 'ids',
            'date_query'     => array(
                array(
                    'before' => '12 months ago',
                ),
            ),
        )
    );

    foreach ( $old_entries as $entry_id ) {
        wp_delete_post( $entry_id, true );
    }
}
add_action( 'sajjad_delete_old_entries', 'sajjad_delete_old_entries' );

Many popular form plugins, such as Gravity Forms, WPForms, and Fluent Forms, have their own entry retention or "do not store entries" settings. Use the built-in option where one exists, since it will handle the plugin's own database tables correctly.

WordPress Tools That Help With GDPR

WordPress core includes several privacy features that support your GDPR obligations:

• Settings > Privacy: Create or select your privacy policy page. WordPress also provides a policy guide with suggested text from core and participating plugins.
• Tools > Export Personal Data: Generate a file containing the data WordPress and compatible plugins hold about a given email address, to answer access requests.
• Tools > Erase Personal Data: Remove or anonymise the data associated with an email address, to handle erasure requests.

These tools only cover plugins that register with the WordPress privacy exporters and erasers, so check that your form, shop, and membership plugins support them.

Security plugins can help too. Wordfence, Solid Security, and Sucuri Security provide firewalls, login protection, and file change detection, all of which support Article 32. Be mindful that security plugins log IP addresses and may send data to their vendor's servers, so mention them in your privacy policy and check whether a DPA is available.

Working With Your Host and Third-Party Services

Most of the personal data on your website actually lives on infrastructure you do not control. GDPR still holds you responsible for choosing processors wisely.

1. Sign a DPA: Reputable hosts, email platforms, and SaaS tools offer a standard Data Processing Agreement. Accept it and keep a copy.
2. Check data location: If data is transferred outside the EU or UK, confirm the provider relies on a valid transfer mechanism, such as the EU-US Data Privacy Framework or Standard Contractual Clauses.
3. Review their security: Look for encryption, access controls, backups, and a published security or trust page. Certifications such as ISO 27001 or SOC 2 are a helpful signal.
4. Limit what you share: Only send each service the data it needs. Your analytics tool does not need email addresses.
5. Keep a record: A simple spreadsheet listing each service, the data it receives, and its DPA status goes a long way towards your record of processing activities (Article 30).

Security Headers and Third-Party Scripts

Every third-party script on your pages can read form fields and cookies. A compromised analytics or chat widget could leak personal data without your server ever being touched. To reduce that risk:

• Remove scripts you no longer use.
• Load scripts only on pages that need them.
• Use a Content Security Policy to restrict which domains can run scripts and receive data.
• Add basic headers such as Strict-Transport-Security, X-Content-Type-Options, and Referrer-Policy.

A minimal example for Nginx, placed inside your server block:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Test with nginx -t before reloading, and only enable includeSubDomains if every subdomain supports HTTPS.

What to Do If You Have a Data Breach

GDPR defines a personal data breach broadly: any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. A hacked database, a lost laptop with customer exports, or an email sent to the wrong list can all qualify.

When you discover one, work through these steps:

1. Contain the incident: Stop the leak. Take the affected system offline if necessary, reset credentials, and close the vulnerability.
2. Assess the risk: What data was involved, how many people, and how likely is harm? Encrypted data with a safe key usually carries far lower risk.
3. Decide on notification: If there is a risk to individuals, notify your supervisory authority within 72 hours of becoming aware. If you do not have all the facts yet, you can report in phases.
4. Tell affected people if the risk is high: Explain what happened, what data was involved, and what they should do, such as changing passwords.
5. Document everything: Record the facts, your reasoning, and the actions you took, even if you decide not to report.
6. Fix the root cause: Update your controls so the same thing cannot happen again.

Having a short written plan before anything goes wrong makes those 72 hours far less stressful.

A Practical GDPR Security Checklist

If you want a starting point, work through this list and note the date you completed each item:

• All pages served over HTTPS with HSTS enabled.
• WordPress core, themes, plugins, and PHP on supported, updated versions.
• Every user has their own account, the lowest suitable role, and two-factor authentication.
• Unused plugins, themes, and user accounts removed.
• Forms collect only necessary fields, with a defined retention period.
• Backups encrypted, stored off-site, and restore-tested.
• Firewall and login protection in place.
• Logs kept for a defined period and reviewed.
• DPAs signed with host, email, form, and analytics providers.
• A written breach response plan with regulator contact details.
• A scheduled review, at least every few months, of all of the above.

---

FAQ: GDPR and Website Security

---

Conclusion

GDPR makes website security a legal responsibility for anyone handling personal data from people in Europe or the UK. The regulation does not hand you a checklist, but its expectations are clear: collect less, protect what you keep with encryption and access control, keep your software patched, be able to recover from incidents, and know exactly what to do if a breach happens.

The good news is that the measures GDPR asks for are the same ones that keep your site safe from attackers in the first place. Start with data minimisation and patching, sign agreements with your providers, write a simple breach plan, and review everything on a regular schedule. Doing those things consistently puts you in a strong position both with regulators and with the people who trust you with their information.