Zgodność z prawem dla agencji WordPress w Hiszpanii: RODO, AEPD, LSSI i NIS2

#Zgodność z prawem dla agencji WordPress w Hiszpanii: RODO, AEPD, LSSI i NIS2

Otoczenie prawne firmowych stron i sklepów internetowych w Hiszpanii przestało być zbiorem teoretycznych wytycznych. Dziś to ścisłe ramy, w których trzeba działać na co dzień. W 2026 roku budowa strony na WordPressie w Hiszpanii wymaga dobrej znajomości nie tylko technologii, ale też przepisów krajowych i unijnych dotyczących prywatności, handlu elektronicznego, fakturowania i cyberbezpieczeństwa.

Ignorowanie tych przepisów naraża firmy na kary ze strony hiszpańskiego organu ochrony danych (Agencia Española de Protección de Datos, AEPD), Sekretariatu Stanu ds. Cyfryzacji i Sztucznej Inteligencji (Secretaría de Estado de Digitalización e Inteligencia Artificial) oraz hiszpańskiej administracji skarbowej (Agencia Tributaria). W tym artykule omawiamy wymagania techniczne, które instalacja WordPress musi spełnić, by była zgodna z obecnymi przepisami w Hiszpanii, z odwołaniami do tekstów jednolitych w BOE (hiszpański dziennik urzędowy) i do wytycznych AEPD.

#Jak spełnić RODO na WordPressie według wytycznych AEPD

RODO (rozporządzenie UE 2016/679) to podstawa przetwarzania danych osobowych w Unii Europejskiej. W Hiszpanii jego stosowanie bardzo aktywnie nadzoruje AEPD na podstawie ustawy organicznej 3/2018 o ochronie danych osobowych i gwarancji praw cyfrowych (LOPDGDD).

#Jak hostować Google Fonts lokalnie w WordPressie

Jeden z najczęstszych błędów na stronach WordPress to ładowanie zasobów z zewnętrznych serwerów w locie. Gdy strona wysyła zapytanie do obcego serwera (na przykład do serwerów Google po fonty), adres IP użytkownika (dana osobowa w rozumieniu RODO) trafia do tego zewnętrznego dostawcy, często poza Unię Europejską.

Takie przekazanie wymaga podstawy prawnej, a jeśli serwer stoi poza Europejskim Obszarem Gospodarczym, także zabezpieczeń dla transferu międzynarodowego. Hostowanie fontów na własnym serwerze usuwa zewnętrzne zapytanie, a razem z nim oba problemy. Rozwiązanie techniczne w WordPressie jest proste: wszystkie fonty pobiera się i serwuje lokalnie z serwera albo wbudowuje w statyczny build (w przypadku stron headless opartych na Astro).

Aby hostować fonty lokalnie w klasycznym WordPressie:

1. Pobierz pliki fontów (.woff2) z Google Webfonts Helper lub podobnego źródła.
2. Wgraj fonty do folderu motywu lub motywu potomnego (/assets/fonts/).
3. Zdefiniuj reguły @font-face w arkuszu stylów CSS.
4. Wyłącz zewnętrzne zapytania filtrami w functions.php albo narzędziem do optymalizacji.

@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');
}

#Hosting w UE zgodny z RODO

RODO wymaga, by administrator danych zapewnił ich przechowywanie i przetwarzanie na infrastrukturze zgodnej z przepisami europejskimi. Przekazywanie danych do państw, wobec których Komisja Europejska nie wydała decyzji stwierdzającej odpowiedni stopień ochrony, wymaga dodatkowych zabezpieczeń (na przykład podpisania standardowych klauzul umownych, SCC).

W 2026 roku suwerenność danych skłoniła agencje do wyboru hostingu fizycznie zlokalizowanego w Unii Europejskiej. Platformy, które przepuszczają ruch przez proxy poza Europą bez podpisanej umowy powierzenia przetwarzania (DPA, Data Processing Agreement), to poważne ryzyko dla zgodności. Standardem przy wdrożeniach produkcyjnych są dostawcy CDN i hostingu przechowujący dane wyłącznie w europejskich centrach danych.

#Czego LSSI wymaga od strony na WordPressie

LSSI (ustawa 34/2002) przenosi do prawa hiszpańskiego dyrektywę o handlu elektronicznym. Reguluje usługi świadczone przez internet, jeśli stanowią działalność gospodarczą usługodawcy.

#Co musi zawierać strona Aviso Legal

Każda strona, która stanowi działalność gospodarczą właściciela (sprzedaż bezpośrednia, reklama, afiliacja albo pozyskiwanie leadów), musi zapewniać stały, łatwy, bezpośredni i bezpłatny dostęp do informacji wymienionych w art. 10.1 LSSI. Zwykle zbiera się je na stronie Aviso Legal, czyli w nocie prawnej:

• Imię i nazwisko lub nazwa firmy, miejsce zamieszkania lub siedziba (albo stały zakład w Hiszpanii), adres e-mail i wszelkie inne dane, które pozwalają na bezpośredni i skuteczny kontakt.
• Dane wpisu do rejestru handlowego (Registro Mercantil) albo do innego rejestru publicznego, w którym figuruje właściciel.
• Jeśli działalność wymaga uprzedniego zezwolenia administracyjnego, dane tego zezwolenia i organu, który ją nadzoruje.
• Jeśli właściciel wykonuje zawód regulowany, samorząd zawodowy i numer wpisu, tytuł zawodowy, państwo, w którym go wydano, oraz obowiązujące zasady wykonywania zawodu.
• Numer identyfikacji podatkowej.
• Jeśli strona pokazuje ceny, jasną i dokładną informację, czy obejmują podatki, a w odpowiednich przypadkach koszty wysyłki.
• Kodeksy postępowania, do których właściciel przystąpił.

Ustawa nie wymaga numeru telefonu: wystarczy e-mail plus dowolny inny kanał bezpośredniego kontaktu. Art. 38 stopniuje naruszenia. Istotne niedopełnienie obowiązków z lit. a) (identyfikacja i kontakt) i f) (ceny) art. 10.1 to naruszenie poważne (art. 38.3 b), a brak pozostałych informacji to naruszenie lekkie (art. 38.4 b). Według art. 39 naruszenia poważne karze się grzywną od 30.001 do 150.000 euro, a lekkie grzywną do 30.000 euro. W WordPressie naturalne miejsce na te dane to strona podlinkowana w stopce wszystkich szablonów, łącznie z checkoutem WooCommerce.

#Zarządzanie cookies i baner zgody

Art. 22.2 LSSI pozwala używać urządzeń do przechowywania i odczytu danych na urządzeniu użytkownika tylko wtedy, gdy wyraził on zgodę po otrzymaniu jasnej i pełnej informacji o ich użyciu i celu. Wytyczne AEPD w sprawie cookies (Guía sobre el uso de las cookies), zaktualizowane w maju 2024 roku, precyzują, jak ma działać baner (CMP, Consent Management Platform):

• Równorzędne przyciski: opcja odrzucenia musi być dostępna w tym samym momencie, na tym samym poziomie i z tą samą widocznością co opcja akceptacji, bez odsyłania użytkownika do kolejnej warstwy, żeby mógł odmówić. Nie wolno wyróżniać akceptacji krzykliwym kolorem i chować odrzucenia za mało czytelnym linkiem tekstowym.
• Kategorie: użytkownik musi móc zaakceptować lub odrzucić cookies według celów (analityczne, reklamowe, preferencji). Cookies techniczne, niezbędne do świadczenia usługi, o którą prosi użytkownik (na przykład przechowujące produkty w koszyku czy zapamiętujące język), są zwolnione z obowiązku zgody.
• Aktywna zgoda: wytyczne przejmują stanowisko Europejskiej Rady Ochrony Danych, według którego dalsze przeglądanie strony nie jest ważnym sposobem wyrażenia zgody, i dodają, że sama bezczynność użytkownika również nim nie jest. Skrypty śledzące muszą być całkowicie nieaktywne, dopóki użytkownik nie kliknie “Akceptuj”.

#Która analityka może działać bez zgody według AEPD

Ogólne wytyczne AEPD przypominają, że cookies analityczne nie są zwolnione z obowiązku zgody. Wyjątek opisuje osobny dokument, wytyczne dotyczące cookies w narzędziach do pomiaru oglądalności (Uso de cookies para herramientas de medición de audiencia, styczeń 2024), który dopuszcza go tylko wtedy, gdy spełnione są wszystkie poniższe warunki:

• Celem jest wyłącznie pomiar ruchu na własnej stronie, wyłącznie w imieniu wydawcy, a wynikiem są anonimowe dane statystyczne.
• Danych nie łączy się z innymi operacjami przetwarzania ani nie przekazuje podmiotom trzecim, a nie pozwalają one śledzić osoby między różnymi stronami czy aplikacjami.
• Czas działania cookies jest ograniczony do okresu, który pozwala porównywać oglądalność (wytyczne podają przykładowo trzynaście miesięcy), nie przedłuża się przy każdej wizycie, a dane przechowuje się najwyżej dwadzieścia pięć miesięcy.
• Użytkownik zostaje o tym poinformowany, na przykład w polityce prywatności.
• Jeśli pomiar prowadzi zewnętrzny dostawca, obowiązuje umowa zgodna z art. 28 RODO, która zabrania mu ponownego wykorzystania danych.

Wytyczne wymieniają też pomiary, które uznają za ściśle niezbędne: ruch na poszczególnych podstronach, strony odsyłające, typ urządzenia i przeglądarki, czasy ładowania, czas spędzony na stronie, działania użytkownika i region geograficzny, zawsze w formie zagregowanej. Konfiguracja, która udostępnia dane platformom reklamowym, wypada poza zwolnienie. Narzędzie hostowane samodzielnie, skonfigurowane tak, by nie łączyło ani nie przekazywało danych, może się w nim zmieścić.

#Jaka kara AEPD grozi za cookies bez zgody

Używanie cookies niezwolnionych z obowiązku zgody bez poinformowania użytkownika albo bez uzyskania zgody na warunkach art. 22.2 to według art. 38.4 g) LSSI naruszenie lekkie, zagrożone grzywną do 30.000 euro (art. 39.1 c). Jeśli dojdzie do ponownego naruszenia, stwierdzonego prawomocną decyzją wydaną w ciągu poprzednich trzech lat, naruszenie staje się poważne (art. 38.3 i), z grzywną od 30.001 do 150.000 euro. Większość naruszeń LSSI karze Sekretariat Stanu ds. Cyfryzacji i Sztucznej Inteligencji, ale art. 43.1 powierza AEPD naruszenia dotyczące cookies, komunikacji handlowej przez e-mail i cofnięcia zgody.

Przy ustalaniu wysokości kary art. 40 bierze pod uwagę między innymi umyślność, czas trwania naruszenia, uzyskane korzyści, objęty nim obrót oraz podjęcie działań, które ograniczają lub naprawiają szkodę. Poprawienie banera od razu po wykryciu błędu i udokumentowanie tej poprawki to więc czynnik, który sama ustawa uwzględnia.

#Jak zbudować formularze zgodne z RODO w WordPressie

Zbieranie leadów przez formularze kontaktowe, zapisy do newslettera czy zapytania ofertowe to punkt, któremu AEPD przygląda się szczególnie uważnie. WordPress w dużej mierze opiera się na wtyczkach formularzy (takich jak Contact Form 7, Gravity Forms czy Formidable Forms), więc wymaga starannej konfiguracji, by nie zostawić luk prawnych:

#Checkbox zgody w formularzu kontaktowym

Każdy formularz kontaktowy zbierający dane osobowe (imię, e-mail, telefon) musi mieć domyślnie niezaznaczone pole wyboru (checkbox), którym użytkownik wprost akceptuje politykę prywatności strony.

• Pola zaznaczone z góry są niedozwolone.
• Wysłanie formularza musi być zablokowane, dopóki użytkownik sam nie zaznaczy pola.
• Tekst przy polu musi zawierać czytelny i dostępny link do strony Polityki prywatności.

#Co musi zawierać pierwsza warstwa informacji o prywatności

AEPD wymaga, by bezpośrednio pod przyciskiem wysyłki formularza wyświetlała się uproszczona “pierwsza warstwa” informacji o przetwarzaniu danych. Musi jasno i wprost podawać:

• Administrator: nazwę właściciela strony lub firmy.
• Cel: po co zbierane są dane (na przykład odpowiedź na zapytanie, wysyłka ofert handlowych).
• Podstawa prawna: podstawę przetwarzania (zwykle zgoda osoby, której dane dotyczą).
• Odbiorcy: czy dane trafią do podmiotów trzecich (na przykład do narzędzi e-mail marketingu, takich jak Brevo czy Mailchimp).
• Prawa: jak użytkownik może skorzystać z prawa dostępu, sprostowania, usunięcia i sprzeciwu (na przykład pisząc na dedykowaną skrzynkę e-mail).

#Jak rejestrować zgody z formularzy w WordPressie

Zasada rozliczalności (accountability) z RODO wymaga, by firma potrafiła wykazać, że konkretny użytkownik zaakceptował politykę prywatności określonego dnia o określonej godzinie. W WordPressie osiąga się to, konfigurując wtyczkę formularzy tak, by przy każdym zgłoszeniu zapisywała w bazie adres IP (w miarę możliwości częściowo zanonimizowany), znacznik czasu (timestamp) i stan zaznaczonego pola zgody.

#Obowiązkowa dostępność strony WordPress według EAA

Dyrektywę (UE) 2019/882, znaną jako Europejski akt w sprawie dostępności (European Accessibility Act, EAA), Hiszpania wdrożyła tytułem I ustawy 11/2023 z 8 maja (Ley 11/2023). Wymaga ona, by określone produkty i usługi, w tym usługi handlu elektronicznego (także te zbudowane na WooCommerce) oraz usługi bankowe, transportowe i łączności elektronicznej, były dostępne dla osób z niepełnosprawnościami.

#Od kiedy dostępność sklepu internetowego w Hiszpanii jest obowiązkowa

Zgodnie z osiemnastym przepisem końcowym (disposición final decimoctava) Ley 11/2023 tytuł I wszedł w życie 28 czerwca 2025 roku. Od tego dnia usługi objęte jego zakresem muszą spełniać wymagania dostępności. Art. 3.3 zwalnia mikroprzedsiębiorstwa świadczące usługi, a sama ustawa definiuje mikroprzedsiębiorstwo jako firmę, która zatrudnia mniej niż 10 osób i której roczny obrót albo suma bilansowa nie przekracza 2 milionów euro. Agencja pracująca dla kilku sklepów musi sprawdzać zwolnienie osobno dla każdego klienta, bo liczy się wielkość właściciela sklepu, a nie agencji.

#Kryteria WCAG 2.2 na poziomie AA dla WordPressa

Praktycznym punktem odniesienia przy audycie strony jest poziom AA wytycznych dotyczących dostępności treści internetowych (WCAG). W3C wyjaśnia w specyfikacji WCAG 2.2, że ta wersja rozszerza WCAG 2.1 o nowe kryteria, więc strona zgodna z 2.2 jest też zgodna z 2.1, i zaleca przyjęcie 2.2 jako celu, nawet jeśli formalne obowiązki wymieniają starsze wersje. Agencje muszą więc audytować i poprawiać szablony oraz bloki WordPressa według ścisłych kryteriów:

• Nawigacja klawiaturą: cała strona, łącznie z rozwijanymi menu i checkoutem WooCommerce, musi dać się obsłużyć wyłącznie klawiaturą (klawisz Tab). Stany fokusu (focus states) muszą być wyraźnie widoczne.
• Czytniki ekranu: obrazy muszą mieć opisowe atrybuty alt, a elementy interaktywne (przyciski, linki) opisowe etykiety aria-label, jeśli ich treść tekstowa nie jest jednoznaczna.
• Kontrast kolorów: tekst musi zachować minimalny współczynnik kontrastu 4.5:1 względem tła (i 3:1 dla dużego tekstu).

#Dlaczego wtyczki dostępności typu overlay nie spełniają EAA

Wiele agencji próbuje rozwiązać problem dostępności, instalując wtyczki nakładkowe (overlays), które obiecują automatyczną dostępność dzięki pływającemu przyciskowi. Overlay zmienia stronę w przeglądarce już po jej załadowaniu, ale nie zmienia szablonów, bloków ani HTML-a generowanego przez WordPressa, a to właśnie tam sprawdza się kryteria WCAG. Dostępność trzeba rozwiązać natywnie, w semantycznym HTML, a nie łatkami w JavaScripcie.

#Jak NIS2 wpływa na agencję WordPress w Hiszpanii

Dyrektywa NIS2, czyli dyrektywa (UE) 2022/2555, ma podnieść wspólny poziom cyberbezpieczeństwa w całej Unii Europejskiej. Znacznie poszerza krąg sektorów objętych regulacją i dzieli firmy, których dotyczy, na podmioty kluczowe i ważne. Jej art. 41 wyznaczył 17 października 2024 roku jako termin, do którego państwa członkowskie miały przyjąć i opublikować przepisy wdrażające.

#Na jakim etapie jest wdrożenie NIS2 w Hiszpanii

Na dzień 14 października 2026 roku baza tekstów jednolitych BOE nie zawiera żadnego hiszpańskiego aktu wdrażającego NIS2. Obowiązującą podstawą pozostaje Real Decreto-ley 12/2018 o bezpieczeństwie sieci i systemów informatycznych, który wdrożył pierwszą dyrektywę NIS, a szczegóły reguluje Real Decreto 43/2021. Jego art. 19 nakłada obowiązek zgłaszania incydentów na operatorów usług kluczowych i dostawców usług cyfrowych, którzy robią to przez właściwy dla siebie CSIRT. Art. 11 przypisuje do INCIBE-CERT podmioty spoza sektora publicznego w rozumieniu ustawy 40/2015 (Ley 40/2015). Jeśli sama agencja nie jest operatorem usług kluczowych ani dostawcą usług cyfrowych w rozumieniu tego aktu, obowiązek zgłaszania jej nie dotyczy. Trafiają do niej natomiast wymagania umowne od regulowanych klientów.

#Wymagania NIS2 wobec agencji WordPress w łańcuchu dostaw

Jedną z najważniejszych zmian w NIS2 jest nacisk na cyberbezpieczeństwo łańcucha dostaw. Art. 21 ust. 2 wymienia wśród minimalnych środków zarządzania ryzykiem bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa relacji między każdym podmiotem a jego bezpośrednimi dostawcami (lit. d), oraz stosowanie uwierzytelniania wieloskładnikowego tam, gdzie to właściwe (lit. j). Art. 21 ust. 3 wymaga ponadto, by podmioty oceniały podatności każdego dostawcy i jakość jego praktyk w zakresie cyberbezpieczeństwa, łącznie z procedurami bezpiecznego tworzenia oprogramowania.

Jeśli twoja agencja tworzy, hostuje lub utrzymuje stronę WordPress dla podmiotu regulowanego, możesz rozsądnie zakładać, że klient przeniesie te środki do umowy:

• Kontrola dostępu i MFA: uwierzytelnianie dwuskładnikowe na wszystkich kontach administratorów CMS i paneli zarządzania serwerem.
• Runbook incydentów: spisana procedura niezwłocznego powiadamiania klienta, tak by mógł dotrzymać własnych terminów. Art. 23 ust. 4 NIS2 wymaga od podmiotu regulowanego wczesnego ostrzeżenia w ciągu 24 godzin od powzięcia wiadomości o poważnym incydencie, zgłoszenia w ciągu 72 godzin i raportu końcowego najpóźniej miesiąc po zgłoszeniu.
• Audyt zależności: regularny przegląd wtyczek WordPress używanych na produkcji, by zapobiec atakom na łańcuch dostaw (na przykład wprowadzeniu backdoorów w aktualizacjach popularnych wtyczek).

#Jak dostosować WooCommerce do VeriFactu

Real Decreto 1007/2023 zatwierdza rozporządzenie określające wymagania dla systemów informatycznych do fakturowania, znane jako rozporządzenie VeriFactu. Jego art. 8 wymaga, by te systemy zapewniały integralność, przechowywanie, dostępność, czytelność, identyfikowalność i niezmienialność rejestrów faktur.

#Wymagania techniczne dla WooCommerce

W sklepach na WooCommerce sprzedających na rynku hiszpańskim wystawianie faktur musi być zgodne z rozporządzeniem:

• Kod QR: faktura zawiera kod QR, którego dane odbiorca może dobrowolnie przekazać hiszpańskiej administracji skarbowej (art. 17).
• Integralność rejestru: rejestrów nie można zmienić tak, by system tego nie wykrył i nie ostrzegł. Każda korekta lub anulowanie odbywa się przez co najmniej jeden dodatkowy, późniejszy rejestr faktury, więc pierwotne dane zostają zachowane (art. 8.2 a). Rejestry są powiązane w łańcuch, tak by dało się prześledzić ich kolejność od pierwszego do ostatniego (art. 8.2 b).
• Dwa tryby: system może automatycznie i natychmiast przesyłać wszystkie rejestry do AEAT, a wtedy uznaje się go za “Sistema VERI*FACTU” i domniemywa, że z założenia spełnia wymagania (art. 16). Jeśli ich nie przesyła, musi podpisywać rejestry elektronicznie (art. 16.3 zwalnia z tego podpisu wyłącznie systemy VERI*FACTU).
• Declaración responsable: producent oprogramowania potwierdza zgodność swojego systemu z rozporządzeniem w oświadczeniu (declaración responsable), widocznym w każdej wersji (art. 13). Rozporządzenie nie przewiduje homologacji oprogramowania przez urząd skarbowy.

Agencje WordPress powinny unikać uniwersalnych wtyczek, które zapisują edytowalne rekordy, i integrować WooCommerce przez API z systemami ERP albo oprogramowaniem do fakturowania, którego producent złożył taką declaración responsable.

#Terminy VeriFactu dla sklepów WooCommerce

Czwarty przepis końcowy (disposición final cuarta) Real Decreto 1007/2023 w brzmieniu nadanym przez Real Decreto-ley 15/2025 z 2 grudnia wyznacza następujące terminy:

• Podatnicy Impuesto sobre Sociedades (hiszpański podatek dochodowy od osób prawnych): systemy dostosowane przed 1 stycznia 2027 roku.
• Pozostali zobowiązani z art. 3.1 (podatnicy IRPF prowadzący działalność gospodarczą, nierezydenci posiadający stały zakład i podmioty w systemie przypisania dochodów): systemy działające przed 1 lipca 2027 roku.
• Producenci i sprzedawcy oprogramowania: produkty dostosowane najpóźniej w ciągu dziewięciu miesięcy od wejścia w życie rozporządzenia ministerialnego wykonawczego.

Art. 3.3 wyłącza podatników, którzy prowadzą księgi rejestrowe na zasadach art. 62.6 rozporządzenia o VAT, czyli przez Suministro Inmediato de Información (SII). Pozostali muszą mieć system fakturowania dostosowany w tych terminach, a w wielu małych sklepach to właśnie WooCommerce jest miejscem, w którym powstaje faktura.

#Lista kontrolna zgodności prawnej WordPressa w Hiszpanii

Poniżej techniczna lista kontrolna kluczowych elementów, które trzeba skonfigurować w każdej instalacji WordPress na rynek hiszpański, by w 2026 roku spełnić wszystkie wymogi:

graph TD
    A[Zgodność z przepisami w Hiszpanii] --> B[Prywatność & RODO]
    A --> C[Obowiązki formalne & LSSI]
    A --> D[Bezpieczeństwo & NIS2]
    A --> E[Fakturowanie & VeriFactu]

    B --> B1["Lokalny hosting Google Fonts"]
    B --> B2["Serwery z umową DPA na terenie UE"]
    B --> B3["Blokada skryptów śledzących przed zgodą"]

    C --> C1["Widoczne Aviso Legal, polityka prywatności i cookies"]
    C --> C2["Baner cookies z równorzędnymi przyciskami"]
    C --> C3["Wyraźna i świadoma zgoda"]

    D --> D1["Uwierzytelnianie dwuskładnikowe (MFA) dla administratorów"]
    D --> D2["Rejestr zdarzeń i logi systemowe"]
    D --> D3["Automatyczny audyt zainstalowanych wtyczek"]

    E --> E1["Faktury bez możliwości edycji"]
    E --> E2["Oprogramowanie z declaración responsable VeriFactu"]
    E --> E3["IGIC na Wyspach Kanaryjskich i IPSI w Ceucie i Melilli"]

#Lista kontrolna konfiguracji WordPressa i WooCommerce

• Lokalne fonty: usuń wszystkie odwołania do fonts.googleapis.com i fonts.gstatic.com.
• Bez zewnętrznego CDN: upewnij się, że obrazy i zasoby statyczne są serwowane z domen pod kontrolą UE.
• Aktualne dokumenty: dostępne ze stopki linki do polityki prywatności, Aviso Legal i polityki cookies.
• Zgodny baner cookies: skonfiguruj wybrane narzędzie (na przykład Cookiebot, Complianz albo lekkie rozwiązanie własne na Cloudflare Workers) według wytycznych AEPD w sprawie cookies, z przyciskiem odrzucenia w pierwszej warstwie.
• Bezpieczeństwo WordPressa:
  • Ogranicz liczbę nieudanych prób logowania (wtyczką bezpieczeństwa albo na poziomie proxy Cloudflare).
  • Zmień domyślny prefiks bazy danych WordPressa (wp_) podczas instalacji.
  • Zainstaluj wtyczkę do audytu aktywności, która rejestruje krytyczne działania administratorów.
• WooCommerce:
  • Skonfiguruj strefy wysyłki i naliczanie podatków dla Wysp Kanaryjskich (IGIC), Ceuty i Melilli (IPSI).
  • Dodaj w formularzu danych do faktury w checkoucie osobne pola na NIF/CIF.
  • Połącz checkout z bramkami płatności, które stosują silne uwierzytelnianie klienta wymagane przez PSD2 (3D Secure 2 przy płatnościach kartą).

#Podsumowanie

Zgodność z prawem firmowej strony lub sklepu internetowego w Hiszpanii to już nie przegląd tekstów prawnych, który da się załatwić gotowym szablonem. W 2026 roku legalność jest nierozerwalnie związana z projektem i architekturą techniczną platformy.

Agencje, które stawiają na bezpieczeństwo w fazie projektowania i domyślną ochronę prywatności, nie tylko ograniczają poważne ryzyko prawne swoich klientów. Zyskują też wyraźną przewagę w walce o największe i najcenniejsze projekty na rynku iberyjskim.

#Jak uniknąć kar AEPD na WordPressie

Zgodność z prawem w hiszpańskim środowisku cyfrowym wymaga stałego, aktywnego nadzoru technicznego:

• Międzynarodowe przekazywanie danych: po kolejnych wyrokach europejskich sądów dotyczących transatlantyckiego przepływu danych administratorzy muszą pilnować, by dostawcy hostingu, analityki i automatyzacji nie przekazywali danych do jurysdykcji bez odpowiednich zabezpieczeń, chyba że użytkownik wyraźnie się na to zgodził.
• Rejestr czynności przetwarzania (RAT) w WordPressie: każda firma musi dokładnie udokumentować formularze kontaktowe, bazy klientów WooCommerce i logi dostępu zarejestrowanych użytkowników. Wpisanie tych zasad bezpośrednio do dokumentacji technicznej projektu daje spokój na wypadek kontroli hiszpańskiego organu ochrony danych. Rzetelność prawna chroni wartość firmy.

#Kopie zapasowe i szkolenia z RODO dla zespołu WordPress

Dobre praktyki cyberbezpieczeństwa zmniejszają ryzyko prawne i operacyjne:

• Kontrolowane aktualizacje i niezmienialne kopie zapasowe: automatyczne backupy w centrach danych zlokalizowanych w Europie pozwalają natychmiast odtworzyć stronę po ataku ransomware albo awarii sprzętu.
• Szkolenie zespołu redakcyjnego: nauczenie autorów właściwego obchodzenia się z obrazami, uprawnieniami autorskimi i danymi osobowymi buduje w firmie trwałą kulturę zgodności z przepisami.