In this guide (6)
Your website collects names, emails, IP addresses, contact requests. Perhaps even health or tax data. In all these cases, the GDPR applies — and having a cookie banner is not enough to be compliant.
"GDPR-compliant CMS" is one of those expressions often used inappropriately. Some use it to say the CMS has a cookie plugin. Others to say there's a privacy policy. Neither of these is sufficient.
This article explains what GDPR compliance really means at a technical level, what your CMS needs to do to satisfy it, and why the plugin route on WordPress is structurally risky.
Want to know if your site is compliant?
We'll analyze your site's technical structure for free and tell you what's missing to be GDPR compliant.
What "GDPR compliant CMS" really means
The GDPR — General Data Protection Regulation, in force since 25 May 2018 — does not certify CMSs. There is no official stamp that says "this software is compliant". Compliance depends on how the system collects, processes, stores and protects personal data in your specific configuration.
A CMS can facilitate compliance or make it structurally difficult. The difference lies in the architecture, not in the vendor's claims.
The data controller — that is, you, as the company or professional managing the site — is responsible for compliance. Not your hosting provider, not the developer who installed the CMS, not the plugin that manages cookies. You.
This means that choosing a technically adequate CMS is not a matter of aesthetics or preference: it is an operational requirement with direct legal implications.
If you haven't chosen a platform yet, the guide on how to choose a business CMS in 2026 will help you evaluate options based on security, costs and compliance.
The 6 technical requirements your CMS must meet
1. Documented and revocable consent management
The GDPR requires that consent to data processing be freely given, specific, informed and unambiguous. And revocable at any time, as easily as it was given.
At a technical level, this means the CMS must record when and how the user gave consent — with a timestamp, the version of the accepted notice and the channel — and must allow the user to revoke it without having to contact an email address or fill out a paper form.
A cookie banner that sets an accepted=true cookie without recording anything is not sufficient. A system that does not allow granular revocation by purpose is not sufficient.
2. Data access logs
Who accessed users' personal data, when, and from which device? The GDPR requires adequate security measures, and access traceability is an integral part of these measures — especially for sites that process special categories of data such as health data, judicial data or financial information.
The CMS must make it possible to know who viewed or modified a record containing personal data, with logs kept for an adequate period.
3. Encryption of data in transit and at rest
HTTPS is the minimum — and by now it's mandatory. But encryption of data at rest, i.e. data stored in the database, is a requirement that many sites ignore.
If the database is compromised and user data is stored in plain text, the impact on the notification to the Data Protection Authority and on the sanctions is significantly different compared to data encrypted with robust algorithms. Encryption at rest reduces the severity of the breach and therefore the scope of the corrective measures required.
4. Documented data breach procedure
The GDPR requires notification to the Data Protection Authority within 72 hours of discovering a breach that poses risks to the rights of the data subjects. Not from the breach — from its discovery.
The CMS must support this procedure with tools that allow you to quickly reconstruct what happened, which data was involved, how many people were affected. Without structured logs and audit tools, reconstructing the incident within 72 hours is operationally impossible.
5. Data portability and deletion on request
Users have the right to receive their own data in a machine-readable format (right to portability) and to request its deletion (right to be forgotten). The CMS must technically support these operations.
In practice: the system must allow you to export all data referring to a specific individual and to delete it permanently — not just de-index it or hide it in the panel, but remove it from the database and from backups.
6. Minimisation of data collected
The GDPR introduces the principle of minimisation: collecting only the data strictly necessary for the stated purpose. A contact form that collects date of birth, landline number and profession when only a name and email are needed violates this principle.
The CMS must allow forms to be configured so that only the necessary fields are collected, without forcing the collection of additional data for technical or system reasons.
Why WordPress with plugins is not a reliable solution
WordPress is built on a plugin-based architecture. Security, privacy, consent management, access logs — everything is added through third-party extensions with independent update cycles.
The problem is not that plugins are inherently dangerous. The problem is structural: each plugin is a separate subprocessor, with its own privacy policy, its own cookies, its own endpoints, its own update cycle. Every plugin that collects or processes personal data requires a separate Data Processing Agreement (DPA) and must be declared in the list of subprocessors.
An average WordPress site with 15-25 active plugins potentially has 15-25 subprocessors to manage contractually, monitor and update. In practice, nobody does.
When a plugin is abandoned by its developer, it stops receiving security updates but remains installed and active — continuing to collect data, continuing to be an attack surface, continuing to transfer data to servers over which you no longer have any control.
Calculate your CMS's financial exposure in 10 secondsHow much would a data breach cost you?
The problem with third-party plugins and subprocessors
GDPR requires that every party processing personal data on behalf of the data controller be a data processor bound by contract. If you're completely new to this topic, you can always ask us for a consultation. In a plugin-based ecosystem, this means that every plugin sending data to external servers — analytics, forms, chat, newsletters, maps, fonts — must be covered by a signed DPA.
Google Fonts loads fonts from Google's servers and transfers the user's IP address to the USA. A contact form using Mailchimp transfers data to Mailchimp. A live chat plugin sends messages to third-party servers. Each of these is a data transfer that requires a legal basis and a contract.
In a CMS with a proprietary architecture and no external dependencies for core functions, the list of subprocessors is controllable and limited. In a plugin-based ecosystem, it grows uncontrollably with every new installation.
What the site owner must do in case of a data breach
When the site is compromised and personal data has been or may have been exfiltrated, here's the sequence:
First — immediately assess whether the breach poses risks to the rights of the data subjects. If so, the notification obligation kicks in.
Second — notify the Data Protection Authority within 72 hours of discovery, even if you don't yet have all the details. A preliminary notification is accepted and can be updated later.
Third — if the breach poses high risks to the data subjects, inform the people involved directly without undue delay.
Fourth — document everything: what happened, when it was discovered, what data was involved, how many people, what measures were taken.
The CMS you use determines your ability to meet these deadlines. Without structured logs, without audit tools, without a documented technical procedure, meeting the 72-hour deadline is practically impossible.
How to check if your site is truly compliant
These are the minimum checks to carry out:
Does the site use HTTPS on all pages, including the admin ones?
Is the data in the database encrypted or stored in plain text?
Is there a consent log with a timestamp for each user?
Is it possible to export all data for a single user in a structured format?
Is it possible to permanently delete all data for a single user, including backups?
Is there an access log for the admin panel?
Is every plugin that processes personal data covered by a signed DPA?
Is the list of subprocessors up to date and available?
Is there a documented procedure for handling a data breach?
If the answer to more than two of these questions is "I don't know" or "probably not," the site is not compliant — regardless of what the privacy policy says.
If you're considering rebuilding your company website, keep in mind that migration is also the right time to align your architecture with GDPR requirements.
KeideaCMS
KeideaCMS natively integrates consent management, access logs, AES-256 encryption and 2FA — with no third-party plugins to manage.
KeideaCMS
KeideaCMS natively integrates consent management, access logs, AES-256 encryption and 2FA — with no third-party plugins to manage.
