Legal compliance guide for WordPress agencies in Spain: GDPR, AEPD, LSSI and NIS2

#Legal compliance guide for WordPress agencies in Spain: GDPR, AEPD, LSSI and NIS2

Legal requirements for corporate and ecommerce websites in Spain are no longer a set of theoretical guidelines. They have become a strict operating framework. In 2026, building a website in Spain with WordPress takes detailed knowledge not only of the technology but also of the national and European laws that govern privacy, ecommerce, invoicing and cybersecurity.

Ignoring these rules exposes companies to sanctions from the Spanish Data Protection Agency (AEPD), from the Secretaría de Estado de Digitalización e Inteligencia Artificial (the Secretary of State for Digitalisation and Artificial Intelligence) and from the Spanish Tax Agency. This article walks through the technical requirements a WordPress installation has to meet to comply with the current regulatory framework in Spain, with references to the consolidated texts in the BOE (the Spanish official gazette) and to the AEPD guides.

#How to comply with the GDPR on WordPress under AEPD rules

The GDPR (Regulation (EU) 2016/679) is the foundation of personal data processing in the European Union. In Spain it is enforced very actively by the AEPD through Organic Law 3/2018 on the Protection of Personal Data and Guarantee of Digital Rights (LOPDGDD).

#How to host Google Fonts locally in WordPress

One of the most common mistakes on WordPress sites is hotloading external resources. When a website makes a request to an external server (such as Google’s servers to download fonts), the visitor’s IP address (personal data under the GDPR) is passed to that third-party provider and, often, outside the European Union.

That transfer needs a legal basis and, if the server sits outside the European Economic Area, safeguards for the international transfer. Hosting the fonts on your own server removes the external request and, with it, both problems. The technical fix in WordPress is simple: every font is downloaded and served locally from the server or bundled into the static build (for headless sites built with Astro).

To host fonts locally on a classic WordPress build:

1. Download the font files (.woff2) from Google Webfonts Helper or a similar source.
2. Upload the fonts to the theme or child theme folder (/assets/fonts/).
3. Define the @font-face rules in the CSS stylesheet.
4. Disable external requests with filters in functions.php or with optimisation tools.

@font-face {
  font-family: 'Outfit';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/assets/fonts/outfit-v11-latin-regular.woff2') format('woff2');
}

#Choosing GDPR-compliant hosting in the EU

The GDPR requires the controller to ensure that user data is stored and processed on infrastructure that meets European rules. International data transfers to countries without an adequacy decision from the European Commission need additional safeguards (such as signing Standard Contractual Clauses, SCC).

In 2026, data sovereignty has pushed agencies towards hosting physically located in the European Union. Platforms that route traffic through proxies outside Europe without a signed DPA (Data Processing Agreement) are a significant compliance risk. CDN and hosting providers that offer storage exclusively in European data centres are the standard choice for production builds.

#What the LSSI requires from a WordPress site

The LSSI (Law 34/2002) transposes the Electronic Commerce Directive into Spanish law. It governs services offered online when they form an economic activity for the provider.

#What the Aviso Legal page must include

Any website that forms an economic activity for its owner (direct sales, advertising, affiliate links or lead generation) must give permanent, easy, direct and free access to the information listed in Article 10.1 of the LSSI, usually gathered on the Aviso Legal (legal notice) page:

• Name or registered company name, residence or address (or a permanent establishment in Spain), email address and any other detail that allows direct and effective communication.
• Registration details in the Commercial Registry (Registro Mercantil) or in the public register where the owner is registered.
• If the activity requires prior administrative authorisation, the details of that authorisation and of the body that supervises it.
• If a regulated profession is practised, the professional association and membership number, the qualification, the State that issued it and the applicable professional rules.
• Tax identification number.
• If the site shows prices, clear and accurate information on whether they include taxes and, where relevant, shipping costs.
• The codes of conduct the owner has signed up to.

The law does not require a phone number: an email address plus any other direct contact channel is enough. Article 38 grades the breaches. A significant failure to comply with paragraphs a) (identification and contact) and f) (prices) of Article 10.1 is a serious infringement (Article 38.3 b), and failing to provide the other details is a minor infringement (Article 38.4 b). Under Article 39, serious infringements carry fines of 30,001 to 150,000 euros and minor ones fines of up to 30,000 euros. In WordPress, the natural place for this information is a page linked from the footer of every template, including the WooCommerce checkout.

#Cookie management and the consent banner

Article 22.2 of the LSSI allows data storage and retrieval devices to be used on the user’s equipment only if the user has given consent after receiving clear and complete information about their use and purpose. The AEPD Guía sobre el uso de las cookies (guide on the use of cookies), updated in May 2024, sets out how the banner (CMP, Consent Management Platform) has to work:

• Equal buttons: the option to reject must be offered at the same time, at the same level and with the same visibility as the option to accept, without sending the user to another layer to reject. Highlighting the accept button with loud colours while hiding the reject option behind a hard-to-read text link is not allowed.
• Categories: users must be able to accept or reject cookies by purpose (analytics, advertising, preferences). Technical cookies needed to provide the service requested (such as keeping items in the cart or remembering the language) are exempt from consent.
• Active consent: the guide adopts the European Data Protection Board’s position that continuing to browse is not a valid way of giving consent, and adds that mere inactivity by the user is not valid either. Tracking scripts must stay fully inactive until the user clicks “Accept”.

#Which web analytics can run without consent under AEPD rules

The general AEPD guide points out that analytics cookies are not exempt from the consent requirement. The exception sits in a separate guide, Uso de cookies para herramientas de medición de audiencia (use of cookies for audience measurement tools, January 2024), which allows it only if all of these conditions are met:

• The purpose is limited to measuring the audience of the site itself, solely on behalf of the publisher, and the result is anonymous statistical data.
• The data is not combined with other processing or passed to third parties, and it does not allow the person to be tracked across different sites or apps.
• The cookie lifetime is limited to a period that allows audiences to be compared (the guide gives thirteen months as an example), without being extended on each visit, and the data is kept for no more than twenty-five months.
• The user is informed, for example in the privacy policy.
• If the measurement is provided by an external vendor, there is a contract under Article 28 of the GDPR that forbids the vendor from reusing the data.

The guide also lists the measurements it considers strictly necessary: audience per page, referring pages, device and browser type, load times, time on page, user actions and geographic area, always in aggregate form. A setup that shares data with advertising platforms falls outside the exemption. A self-hosted tool, configured not to combine or pass on data, can fit within it.

#What fine the AEPD imposes for cookies without consent

Using non-exempt cookies without informing users or without obtaining consent on the terms of Article 22.2 is a minor infringement under Article 38.4 g) of the LSSI, punishable by a fine of up to 30,000 euros (Article 39.1 c). If the breach is repeated and a final decision issued in the previous three years has declared it, the infringement becomes serious (Article 38.3 i), with a fine of 30,001 to 150,000 euros. Most LSSI infringements are sanctioned by the Secretaría de Estado de Digitalización e Inteligencia Artificial, but Article 43.1 gives the AEPD those concerning cookies, commercial communications by email and the withdrawal of consent.

To set the amount, Article 40 takes into account, among other criteria, intent, how long the infringement lasted, the profits obtained, the turnover affected and the steps taken to mitigate or repair the damage. Fixing the banner as soon as the fault is found and documenting the fix is therefore a factor the law itself weighs.

#How to build GDPR-compliant forms in WordPress

Lead capture through contact forms, newsletter sign-ups or quote requests is a critical point under AEPD scrutiny. Because WordPress relies heavily on form plugins (such as Contact Form 7, Gravity Forms or Formidable Forms), it needs careful configuration to avoid legal gaps:

#Consent checkbox on the contact form

Every contact form that collects personal data (such as name, email or phone number) must include a checkbox that is unticked by default, through which the user explicitly accepts the site’s privacy policy.

• Pre-ticked boxes are not allowed.
• Form submission must stay blocked until the user actively ticks the box.
• The text next to the box must link clearly and accessibly to the Privacy Policy page.

#What the first layer of privacy information must include

The AEPD requires a simplified “first layer” of information about data processing to appear directly below the form’s submit button. It must state clearly and directly:

• Controller: name of the site owner or company.
• Purpose: why the data is collected (for example, answering enquiries or sending commercial offers).
• Legal basis: the lawful basis for processing (usually the data subject’s consent).
• Recipients: whether data will be shared with third parties (for example, email marketing tools such as Brevo or Mailchimp).
• Rights: how users can exercise their rights of access, rectification, erasure and objection (for example, by emailing a dedicated mailbox).

#How to log form consent in WordPress

To meet the GDPR accountability principle, the company must be able to prove that a specific user accepted the privacy policy on a specific date and time. In WordPress, this means configuring the form plugin to store in the database the IP address (partly anonymised where possible), the timestamp and the consent state of the ticked box for every form submission.

#Mandatory web accessibility in WordPress under the EAA

Directive (EU) 2019/882, known as the European Accessibility Act (EAA), was transposed in Spain through Title I of Ley 11/2023, de 8 de mayo (Law 11/2023 of 8 May). It requires certain products and services to be accessible to people with disabilities, among them ecommerce services (including those built with WooCommerce) and banking, transport and electronic communications services.

#Since when online shop accessibility has been mandatory in Spain

Under the eighteenth final provision of Ley 11/2023, Title I came into force on 28 June 2025. Since that date, the services within its scope must meet the accessibility requirements. Article 3.3 exempts microenterprises that provide services, and the law itself defines a microenterprise as one that employs fewer than 10 people and whose annual turnover or annual balance sheet total does not exceed 2 million euros. An agency working for several shops has to check the exemption client by client, because what counts is the size of the shop owner, not the size of the agency.

#WCAG 2.2 level AA criteria for WordPress

The practical benchmark for auditing a website is level AA of the Web Content Accessibility Guidelines (WCAG). The W3C explains in the WCAG 2.2 specification that this version extends WCAG 2.1 by adding criteria, so a site that conforms to 2.2 also conforms to 2.1, and it recommends adopting 2.2 as the target even where formal obligations mention earlier versions. Agencies therefore have to audit and optimise WordPress templates and blocks against strict criteria:

• Keyboard navigation: the whole site, including dropdown menus and the WooCommerce checkout, must be usable with the keyboard alone (Tab key). Focus states must be clearly visible.
• Screen readers: images need descriptive alt attributes, and interactive elements (buttons, links) need descriptive aria-label attributes when their text content is not explicit.
• Colour contrast: site text must keep a minimum contrast ratio of 4.5:1 against the background (and 3:1 for large text).

#Why accessibility overlay plugins do not solve the EAA

Many agencies try to solve accessibility by installing overlay plugins that promise to make a site accessible automatically through a floating button. An overlay changes the page in the browser after it loads, but it does not change the templates, the blocks or the HTML that WordPress generates, which is where the WCAG criteria are tested. Accessibility has to be solved natively in semantic HTML, not with JavaScript patches.

#How NIS2 affects a WordPress agency in Spain

The European NIS2 directive, Directive (EU) 2022/2555, aims to raise the common level of cybersecurity across the European Union. It considerably widens the number of regulated sectors and splits the companies it covers into essential and important entities. Its Article 41 set 17 October 2024 as the deadline for Member States to adopt and publish their transposition rules.

#Status of NIS2 transposition in Spain

As of 14 October 2026, the BOE consolidated legislation database lists no Spanish law that transposes NIS2. The framework in force is still Real Decreto-ley 12/2018 on the security of network and information systems, which transposed the first NIS directive and is implemented by Real Decreto 43/2021. Its Article 19 places the duty to notify incidents on operators of essential services and digital service providers, which report through their reference CSIRT. Article 11 assigns to INCIBE-CERT the entities that do not belong to the public sector as defined in Law 40/2015. Unless the agency itself is an operator of essential services or a digital service provider within the meaning of that law, the duty to notify does not fall on it. What does reach it are the contractual requirements of its regulated clients.

#NIS2 requirements for WordPress agencies in the supply chain

One of the most significant changes in NIS2 is its focus on supply chain cybersecurity. Article 21.2 includes among the minimum risk management measures supply chain security, covering the security aspects of the relationship between each entity and its direct suppliers (point d), and the use of multi-factor authentication where appropriate (point j). Article 21.3 also asks entities to assess the vulnerabilities of each supplier and the quality of its cybersecurity practices, including its secure development procedures.

If your agency builds, hosts or maintains a WordPress site for a regulated entity, you can reasonably expect the client to write these measures into the contract:

• Access control and MFA: two-factor authentication on every CMS administrator account and every server control panel.
• Incident runbook: a documented procedure for alerting the client without delay, so that the client can meet its own deadlines. Article 23.4 of NIS2 requires the regulated entity to send an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report no later than one month after the notification.
• Dependency audits: regular review of the WordPress plugins used in production to prevent supply chain attacks (such as backdoors slipped into updates of popular plugins).

#How to adapt WooCommerce to VeriFactu

Real Decreto 1007/2023 approves the regulation that sets the requirements for computerised invoicing systems, known as the VeriFactu regulation. Its Article 8 requires these systems to guarantee the integrity, retention, accessibility, legibility, traceability and immutability of invoicing records.

#VeriFactu technical requirements for WooCommerce

For WooCommerce stores selling on the Spanish market, invoicing has to follow the regulation:

• QR code: the invoice carries a QR code whose data the recipient can voluntarily send to the Spanish Tax Agency (Article 17).
• Record integrity: records cannot be altered without the system detecting it and raising a warning. Any correction or cancellation is made through at least one additional, later invoicing record, so the original data is kept (Article 8.2 a). Records are chained so that their sequence can be followed from the first to the last (Article 8.2 b).
• Two modes: the system can send every record to the AEAT automatically and instantly, in which case it counts as a “Sistema VERI*FACTU” and is presumed compliant by design (Article 16). If it does not send them, it must sign the records electronically (Article 16.3 exempts only VERI*FACTU systems from that signature).
• Declaración responsable: the software producer certifies that its system complies with the regulation through a declaración responsable (statement of compliance) visible in each version (Article 13). The regulation does not provide for any approval of the software by the Tax Agency.

WordPress development agencies should avoid generic plugins that store editable records and instead integrate WooCommerce through APIs with ERPs or invoicing software whose producer provides that statement of compliance.

#VeriFactu deadlines for WooCommerce stores

The fourth final provision of Real Decreto 1007/2023, as worded by Real Decreto-ley 15/2025 of 2 December, sets these deadlines:

• Corporate income tax (Impuesto sobre Sociedades) taxpayers: systems adapted before 1 January 2027.
• Other parties bound under Article 3.1 (personal income tax (IRPF) taxpayers with economic activities, non-residents with a permanent establishment and entities taxed under the income attribution regime): systems operational before 1 July 2027.
• Software producers and sellers: products adapted within no more than nine months of the implementing ministerial order coming into force.

Article 3.3 excludes taxpayers who keep their record books on the terms of Article 62.6 of the VAT Regulation, that is, through the Suministro Inmediato de Información (SII, immediate supply of information). For everyone else, the invoicing system has to be adapted by those dates, and in many small shops WooCommerce is exactly where the invoice is generated.

#Legal compliance checklist for WordPress in Spain

Below is a technical checklist of the key elements to configure on any WordPress installation for the Spanish market to achieve full regulatory compliance in 2026:

graph TD
    A[Regulatory compliance in Spain] --> B[Privacy & GDPR]
    A --> C[Formal obligations & LSSI]
    A --> D[Security & NIS2]
    A --> E[Invoicing & VeriFactu]

    B --> B1["Google Fonts hosted locally"]
    B --> B2["Servers with a DPA inside the EU"]
    B --> B3["Tracking scripts blocked by default"]

    C --> C1["Visible Aviso Legal, privacy and cookie pages"]
    C --> C2["Cookie banner with equal buttons"]
    C --> C3["Explicit and informed consent"]

    D --> D1["Two-factor authentication (MFA) for admins"]
    D --> D2["System event logging"]
    D --> D3["Automatic audit of installed plugins"]

    E --> E1["Non-editable invoices"]
    E --> E2["Software with a VeriFactu statement of compliance"]
    E --> E3["IGIC in the Canary Islands, IPSI in Ceuta and Melilla"]

#WordPress and WooCommerce configuration checklist

• Local fonts: remove every call to fonts.googleapis.com or fonts.gstatic.com.
• No external CDN: make sure images and static assets are served from domains under EU control.
• Up-to-date policies: accessible footer links to the Privacy Policy, Legal Notice and Cookie Policy.
• Compliant cookie banner: configure the tool you choose (such as Cookiebot, Complianz or a lightweight custom build on Cloudflare Workers) according to the AEPD cookie guide, with the reject button on the first layer.
• WordPress security:
  • Limit failed login attempts (with security plugins or at the Cloudflare proxy level).
  • Change the default WordPress database prefix (wp_) during installation.
  • Install an activity audit plugin to log critical administrator actions.
• WooCommerce:
  • Configure shipping zones and tax calculation for the Canary Islands (IGIC), Ceuta and Melilla (IPSI).
  • Add dedicated NIF/CIF fields to the checkout billing form.
  • Connect the checkout to payment gateways that apply the strong customer authentication required by PSD2 (3D Secure 2 for card payments).

#Conclusion

Regulatory compliance for a corporate website or online store in Spain is no longer a simple review of legal texts that can be solved with ready-made templates. In 2026, legality is tied directly to the design and technical architecture of the platform.

Web development agencies that take a proactive security by design and privacy by default approach do more than reduce significant legal risk for their clients. They gain a decisive competitive edge in winning the largest and most valuable projects on the Iberian market.

#How to avoid AEPD sanctions on WordPress

Legal compliance in the Spanish digital ecosystem calls for proactive technical oversight:

• Managing international data transfers: after successive European court rulings on transatlantic data flows, administrators must make sure that hosting, analytics and automation providers do not transfer data to jurisdictions without adequate safeguards unless the user has expressly consented.
• Record of processing activities (RAT) in WordPress: every company must thoroughly document its contact forms, WooCommerce customer databases and login records of registered users. Building these policies directly into the project’s technical documentation gives legal peace of mind in the event of an inspection by the Spanish Data Protection Agency. Legal rigour protects the asset value of the business.

#Backups and GDPR training for WordPress teams

Good cybersecurity practice reduces legal and operational risk on the web:

• Controlled updates and immutable backups: automated backup systems in data centres located in Europe make immediate recovery possible after ransomware incidents or hardware failures.
• Training the editorial team: teaching writers to handle images, author permissions and personal data responsibly builds a lasting culture of regulatory compliance across the company.