CRA vs GDPR: what WordPress developers need to know

Two EU regulations, two different problems

Both GDPR and CRA come from the European Union, and both carry serious penalties for non-compliance. But they are solving different problems.

GDPR (General Data Protection Regulation) is about protecting personal data. It governs how organisations collect, store, process, and transfer information that can identify individuals. Its concern is privacy and the rights of data subjects.

CRA (Cyber Resilience Act) is about product cybersecurity. It governs the security properties of products with digital elements, how they are designed, developed, maintained, and supported throughout their lifecycle. Its concern is that products on the EU market meet baseline cybersecurity standards.

The simplest way we think about it: GDPR asks “how do you handle people’s data?” The CRA asks “how secure is the product you are selling?”

Differences at a glance

Do you need to comply with both?

Almost certainly yes. If you sell a WordPress plugin that touches personal data (and nearly all plugins do in some way) and that plugin is commercially available on the EU market, both regulations apply at the same time.

But the obligations target different parts of your operations:

• GDPR compliance is about your data handling practices. What data does your plugin collect, how is it stored, who sees it, and have users consented?
• CRA compliance is about the security of the plugin itself. Is it designed securely? Do you track and patch vulnerabilities? Can you report incidents to authorities?

You could comply perfectly with GDPR (proper consent, encrypted storage, privacy policies) and still violate the CRA if you lack a vulnerability disclosure process or an SBOM. The reverse is true too: excellent product security means nothing under GDPR if you process personal data without a lawful basis.

The two regulations complement each other. Neither substitutes for the other.

Where CRA and GDPR interact

The two regulations are distinct, but there are places where they collide. If you are a WordPress developer, you need to know where.

Data breaches caused by security vulnerabilities

This is the biggest overlap, and frankly the scenario that worries us most. If a vulnerability in your plugin gets exploited and leads to a personal data breach, you face obligations under both regulations:

• Under GDPR, the data controller (typically the site owner running your plugin) must notify their supervisory authority within 72 hours. As the plugin developer, you may be considered a data processor, which carries its own notification obligations.
• Under the CRA, you (as the manufacturer) must report the actively exploited vulnerability to ENISA within 24 hours and follow the 72h/14d reporting timeline.

A single incident can trigger two separate reporting obligations to two different bodies, with different timelines and different information requirements. You do not want to be figuring this out during an active incident. Prepare the playbook now.

Security by design and data protection by design

GDPR Article 25 requires “data protection by design and by default.” The CRA similarly requires security to be baked into the product design and development process. The specifics differ (GDPR cares about data minimisation and purpose limitation, the CRA cares about resilience against attacks), but the underlying idea is the same: you cannot bolt this stuff on afterwards.

For us WordPress developers, that means secure coding practices in your workflow serve both regulations at once. Input validation, proper authentication, secure data storage, dependency management. These are habits that pay off twice.

Documentation requirements

Both regulations want you to keep records. Under GDPR, you need records of processing activities, DPIAs, and privacy policies. Under the CRA, you need technical documentation, SBOMs, vulnerability handling policies, and conformity declarations.

The documents themselves are different, but the discipline is the same. If you have already built a documentation habit for GDPR, extending it to cover CRA requirements is much less painful than starting cold.

Practical steps for WordPress developers

Build a unified compliance workflow

Rather than treating GDPR and CRA as entirely separate projects, find the overlap and build shared processes. Your incident response plan, for example, should account for both GDPR breach notification and CRA vulnerability reporting from the start.

Audit your plugin through both lenses

Review your plugin twice. First, the GDPR lens: what personal data does it touch, and are you handling it lawfully? Second, the CRA lens: is the code secure, are dependencies tracked, and do you have a process for handling vulnerability reports?

Update privacy and security documentation together

When you next revise your privacy policy (a GDPR requirement), also create or update your vulnerability disclosure policy (a CRA requirement). Publish a security.txt file alongside your privacy policy so both are easy to find.

Prepare for dual incident reporting

If an exploited vulnerability leads to a data breach, you will need to report to ENISA (CRA) and help the site owner report to their data protection authority (GDPR). Having templates, timelines, and contact information ready in advance cuts response time dramatically during a real incident.

Communicate clearly with your users

Your customers (WordPress site owners) are the data controllers under GDPR. They need to understand both the data processing aspects of your plugin and its security properties. Clear documentation, transparent security practices, and prompt vulnerability notifications build trust and help your customers meet their own obligations.

CRA Guard covers the CRA side

GDPR compliance tools for WordPress are well-established. Plugins like Complianz and CookieYes have been helping developers and site owners for years. What has been missing is a dedicated tool for the CRA side.

That is why we built CRA Guard. It provides the checklists, document templates, tooling, and workflow support that WordPress developers need to address CRA requirements, sitting alongside the GDPR tools you already use.

Together, a GDPR plugin and CRA Guard give you coverage across both major EU regulatory frameworks: data protection and product cybersecurity.

For the full picture on CRA obligations, read our complete CRA compliance guide. To find out whether the CRA applies to your specific product, check our scope analysis.

Download CRA Guard Free on WordPress.org

Disclaimer: This article provides general information about EU regulations and is not legal advice. For guidance specific to your situation, consult a qualified legal professional.