Guide til regeletterlevelse for WordPress-byråer i Spania: GDPR, AEPD, LSSI og NIS2

#Guide til regeletterlevelse for WordPress-byråer i Spania: GDPR, AEPD, LSSI og NIS2

De juridiske rammene for bedriftsnettsteder og nettbutikker i Spania er ikke lenger en samling teoretiske retningslinjer. De har blitt et strengt regelverk for daglig drift. I 2026 krever det å bygge et nettsted i Spania med WordPress god kjennskap ikke bare til teknologien, men også til de nasjonale og europeiske lovene som regulerer personvern, netthandel, fakturering og cybersikkerhet.

Bedrifter som ser bort fra disse reglene, risikerer sanksjoner fra det spanske datatilsynet (Agencia Española de Protección de Datos, AEPD), fra statssekretariatet for digitalisering og kunstig intelligens (Secretaría de Estado de Digitalización e Inteligencia Artificial) og fra skattemyndigheten (Agencia Tributaria). Denne artikkelen går gjennom de tekniske kravene en WordPress-installasjon må oppfylle for å følge dagens regelverk i Spania, med henvisninger til de konsoliderte lovtekstene i BOE (Spanias lovtidend) og til AEPDs veiledninger.

#Slik oppfyller du GDPR i WordPress etter AEPDs krav

GDPR (forordning (EU) 2016/679) er grunnmuren for behandling av personopplysninger i EU. I Spania følges etterlevelsen svært aktivt opp av AEPD gjennom Ley Orgánica 3/2018 om vern av personopplysninger og sikring av digitale rettigheter (LOPDGDD).

#Slik hoster du Google Fonts lokalt i WordPress

En av de vanligste feilene på WordPress-nettsteder er å hente eksterne ressurser direkte ved hver sidevisning. Når et nettsted sender en forespørsel til en ekstern server (for eksempel Googles servere for å laste ned skrifter), overføres brukerens IP-adresse (en personopplysning etter GDPR) til denne tredjepartsleverandøren, og ofte ut av EU.

Den overføringen trenger et rettslig grunnlag og, hvis serveren står utenfor EØS, garantier for den internasjonale overføringen. Hoster du skriftene på egen server, forsvinner den eksterne forespørselen, og med den begge problemene. Den tekniske løsningen i WordPress er enkel: alle skrifter lastes ned og leveres lokalt fra serveren eller bygges inn i det statiske bygget (for headless-nettsteder basert på Astro).

Slik hoster du skrifter lokalt i en klassisk WordPress-løsning:

1. Last ned skriftfilene (.woff2) fra Google Webfonts Helper eller en lignende kilde.
2. Last opp skriftene til mappen for temaet eller undertemaet (/assets/fonts/).
3. Definer @font-face-reglene i CSS-stilarket.
4. Slå av eksterne forespørsler med filtre i functions.php eller med optimaliseringsverktøy.

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

#GDPR-vennlig hosting i EU

GDPR krever at den behandlingsansvarlige sørger for at brukerdata lagres og behandles på infrastruktur som oppfyller europeisk regelverk. Overføring av data til land uten en beslutning om tilstrekkelig beskyttelsesnivå fra EU-kommisjonen krever ekstra garantier (for eksempel signering av standard personvernbestemmelser, SCC).

I 2026 har datasuverenitet fått byråer til å foretrekke hosting som fysisk befinner seg i EU. Plattformer som sender trafikken gjennom proxyer utenfor Europa uten en signert databehandleravtale (DPA, Data Processing Agreement), er en betydelig etterlevelsesrisiko. CDN- og hostingleverandører som lagrer data utelukkende i europeiske datasentre, er standardvalget for produksjonsløsninger.

#Hva LSSI krever av et WordPress-nettsted

LSSI (Ley 34/2002) gjennomfører e-handelsdirektivet i spansk rett. Loven regulerer tjenester som tilbys over internett når de utgjør en økonomisk aktivitet for tjenesteyteren.

#Hva Aviso Legal-siden må inneholde

Alle nettsteder som utgjør en økonomisk aktivitet for eieren (direkte salg, annonser, affiliate eller innhenting av leads), må gi varig, enkel, direkte og gratis tilgang til opplysningene som er listet opp i artikkel 10.1 i LSSI. De samles vanligvis på siden Aviso Legal (den juridiske merknaden):

• Navn eller firmanavn, bosted eller adresse (eller et fast driftssted i Spania), e-postadresse og andre opplysninger som gjør direkte og effektiv kommunikasjon mulig.
• Opplysninger om registrering i handelsregisteret (Registro Mercantil) eller i det offentlige registeret eieren er registrert i.
• Hvis virksomheten krever forhåndstillatelse fra myndighetene: opplysninger om tillatelsen og om organet som fører tilsyn.
• Hvis eieren utøver et regulert yrke: yrkesorganisasjonen og medlemsnummeret, tittelen, staten som utstedte den, og de yrkesreglene som gjelder.
• Skatteidentifikasjonsnummer.
• Hvis nettstedet viser priser: klar og nøyaktig informasjon om hvorvidt de inkluderer skatter og eventuelt fraktkostnader.
• Bransjenormene (códigos de conducta) eieren har sluttet seg til.

Loven krever ikke telefonnummer: e-post pluss en annen kanal for direkte kontakt er nok. Artikkel 38 graderer bruddene. Et vesentlig brudd på bokstav a (identifikasjon og kontakt) og f (priser) i artikkel 10.1 er en alvorlig overtredelse (artikkel 38.3 b), mens det å ikke informere om de øvrige opplysningene er en mindre alvorlig overtredelse (artikkel 38.4 b). Etter artikkel 39 straffes alvorlige overtredelser med bot på 30.001 til 150.000 euro og mindre alvorlige med bot på opptil 30.000 euro. I WordPress er det naturlige stedet for disse opplysningene en side som lenkes fra bunnteksten i alle maler, også i kassen i WooCommerce.

#Cookiehåndtering og samtykkebanneret

Artikkel 22.2 i LSSI tillater bruk av enheter for lagring og henting av data på brukerens utstyr bare hvis brukeren har gitt samtykke etter å ha fått klar og fullstendig informasjon om bruken og formålet. AEPDs veiledning om bruk av cookies, oppdatert i mai 2024, presiserer hvordan banneret (CMP, Consent Management Platform) skal fungere:

• Likeverdige knapper: valget om å avvise må tilbys samtidig, på samme nivå og like synlig som valget om å godta, uten at brukeren sendes videre til et annet lag for å avvise. Det er ikke tillatt å fremheve godta-knappen med iøynefallende farger og gjemme avvisningen bak en lite lesbar tekstlenke.
• Kategorier: brukeren må kunne godta eller avvise cookies per formål (analyse, annonser, preferanser). Tekniske cookies som trengs for å levere tjenesten brukeren har bedt om (for eksempel for å holde varer i handlekurven eller huske språket), er unntatt fra samtykke.
• Aktivt samtykke: veiledningen gjengir Det europeiske personvernrådets syn om at det å fortsette å surfe ikke er en gyldig måte å gi samtykke på, og legger til at ren inaktivitet fra brukeren heller ikke er det. Sporingsskript må være helt inaktive til brukeren klikker “Godta”.

#Hvilken nettstedsanalyse som kan kjøre uten samtykke etter AEPD

AEPDs generelle veiledning minner om at analysecookies ikke er unntatt fra samtykkekravet. Unntaket står i en annen veiledning, Uso de cookies para herramientas de medición de audiencia (bruk av cookies i verktøy for publikumsmåling, januar 2024), som godtar det bare når alle disse vilkårene er oppfylt:

• Formålet er begrenset til å måle publikummet på eget nettsted, utelukkende på vegne av utgiveren, og resultatet er anonyme statistiske data.
• Dataene krysses ikke med annen behandling og overføres ikke til tredjeparter, og de gjør det ikke mulig å følge personen på tvers av nettsteder eller apper.
• Levetiden til cookiene er begrenset til en periode som gjør det mulig å sammenligne publikum (veiledningen bruker tretten måneder som eksempel), uten at den forlenges ved hvert besøk, og dataene oppbevares i høyst tjuefem måneder.
• Brukeren får informasjon, for eksempel i personvernerklæringen.
• Hvis målingen leveres av en ekstern leverandør, finnes det en avtale etter artikkel 28 i GDPR som forbyr leverandøren å bruke dataene på nytt.

Veiledningen lister også opp målingene den regner som strengt nødvendige: publikum per side, henvisende sider, enhetstype og nettleser, lastetider, tid på siden, brukerhandlinger og geografisk område, alltid i aggregert form. Et oppsett som deler data med annonseplattformer, faller utenfor unntaket. Et selvhostet verktøy som er satt opp slik at det ikke krysser eller deler data, kan falle innenfor.

#Hvilken bot AEPD gir for cookies uten samtykke

Å bruke cookies som ikke er unntatt, uten å informere eller uten å innhente samtykke slik artikkel 22.2 krever, er en mindre alvorlig overtredelse etter artikkel 38.4 g i LSSI, med bot på opptil 30.000 euro (artikkel 39.1 c). Ved gjentakelse som er fastslått i et rettskraftig vedtak fra de tre foregående årene, blir overtredelsen alvorlig (artikkel 38.3 i), med bot på 30.001 til 150.000 euro. De fleste overtredelser av LSSI sanksjoneres av Secretaría de Estado de Digitalización e Inteligencia Artificial, men artikkel 43.1 legger til AEPD overtredelsene som gjelder cookies, kommersiell kommunikasjon på e-post og tilbaketrekking av samtykke.

Når boten fastsettes, tar artikkel 40 blant annet hensyn til forsett, hvor lenge overtredelsen pågikk, fortjenesten som ble oppnådd, omsetningen som ble berørt, og om det er satt inn tiltak for å begrense eller rette opp skaden. Å rette banneret så snart feilen oppdages og dokumentere rettelsen, er altså noe loven selv tar hensyn til.

#Slik lager du GDPR-vennlige skjemaer i WordPress

Innhenting av leads gjennom kontaktskjemaer, nyhetsbrevpåmeldinger eller tilbudsforespørsler er et punkt AEPD følger nøye. Siden WordPress i stor grad bygger på skjemautvidelser (som Contact Form 7, Gravity Forms eller Formidable Forms), trengs det grundig oppsett for å unngå juridiske hull:

#Samtykkeboks i kontaktskjemaet

Alle kontaktskjemaer som samler inn personopplysninger (som navn, e-post eller telefon), må ha en avkrysningsboks (checkbox) som ikke er krysset av på forhånd, der brukeren uttrykkelig godtar nettstedets personvernerklæring.

• Forhåndsavkryssede bokser er ikke tillatt.
• Skjemaet må være sperret for innsending til brukeren aktivt har krysset av.
• Teksten ved boksen må lenke tydelig og tilgjengelig til siden med personvernerklæringen.

#Hva det første laget med personverninformasjon må inneholde

AEPD krever at et forenklet “første lag” med informasjon om behandlingen vises rett under skjemaets send-knapp. Det må tydelig og direkte oppgi:

• Behandlingsansvarlig: navnet på eieren av nettstedet eller bedriften.
• Formål: hva opplysningene samles inn for (for eksempel å svare på henvendelser eller sende kommersielle tilbud).
• Rettslig grunnlag: grunnlaget for behandlingen (vanligvis samtykke fra den registrerte).
• Mottakere: om opplysningene deles med tredjeparter (for eksempel e-postmarkedsføringsverktøy som Brevo eller Mailchimp).
• Rettigheter: hvordan brukeren kan utøve retten til innsyn, retting, sletting og protest (for eksempel ved å sende e-post til en egen innboks).

#Slik logger du samtykker fra skjemaer i WordPress

For å oppfylle GDPRs ansvarsprinsipp (accountability) må bedriften kunne dokumentere at en bestemt bruker godtok personvernerklæringen på en bestemt dato og et bestemt klokkeslett. I WordPress gjøres dette ved å sette opp skjemautvidelsen slik at den for hver innsending lagrer IP-adressen (helst delvis anonymisert), tidsstempelet (timestamp) og status for samtykkeboksen i databasen.

#Obligatorisk universell utforming i WordPress med EAA

Direktiv (EU) 2019/882, kjent som European Accessibility Act (EAA), ble gjennomført i Spania gjennom avdeling I i Ley 11/2023 av 8. mai. Den krever at visse produkter og tjenester, blant dem netthandelstjenester (også de som er bygget med WooCommerce) og bank-, transport- og elektroniske kommunikasjonstjenester, er tilgjengelige for personer med funksjonsnedsettelser.

#Fra når universell utforming av en nettbutikk er obligatorisk i Spania

Etter attende sluttbestemmelse (disposición final decimoctava) i Ley 11/2023 trådte avdeling I i kraft 28. juni 2025. Fra den datoen må tjenestene som omfattes, oppfylle kravene til tilgjengelighet. Artikkel 3.3 unntar mikroforetak som leverer tjenester, og loven definerer et mikroforetak som et foretak med færre enn 10 ansatte og en årlig omsetning eller en samlet årlig balanse på høyst 2 millioner euro. Et byrå som jobber for flere butikker, må sjekke unntaket kunde for kunde, fordi det er størrelsen på butikkens eier som teller, ikke byråets.

#WCAG 2.2-kriterier på nivå AA for WordPress

Den praktiske målestokken når du reviderer et nettsted, er nivå AA i retningslinjene for tilgjengelig webinnhold (WCAG). W3C forklarer i spesifikasjonen for WCAG 2.2 at denne versjonen utvider WCAG 2.1 med flere kriterier, slik at et nettsted som oppfyller 2.2, også oppfyller 2.1, og anbefaler å sikte mot 2.2 selv om de formelle pliktene nevner eldre versjoner. Byråer må derfor revidere og forbedre WordPress-maler og -blokker etter strenge kriterier:

• Tastaturnavigasjon: hele nettstedet, inkludert nedtrekksmenyer og kassen i WooCommerce, må kunne brukes med tastaturet alene (Tab-tasten). Fokustilstander (focus states) må være godt synlige.
• Skjermlesere: bilder må ha beskrivende alt-attributter, og interaktive elementer (knapper, lenker) må ha beskrivende aria-label-attributter når tekstinnholdet ikke er tydelig.
• Fargekontrast: teksten må ha et kontrastforhold på minst 4.5:1 mot bakgrunnen (og 3:1 for stor tekst).

#Hvorfor overlay-utvidelser for tilgjengelighet ikke løser EAA

Mange byråer prøver å løse tilgjengelighet ved å installere overleggsutvidelser (overlays) som lover å gjøre nettstedet tilgjengelig automatisk via en flytende knapp. Et overlay endrer siden i nettleseren etter at den er lastet, men det endrer ikke malene, blokkene eller HTML-en som WordPress lager, og det er der WCAG-kriteriene sjekkes. Tilgjengelighet må løses i selve koden med semantisk HTML, ikke med JavaScript-lapper.

#Hvordan NIS2 påvirker et WordPress-byrå i Spania

EUs NIS2-direktiv, direktiv (EU) 2022/2555, skal heve det felles nivået for cybersikkerhet i hele EU. Det utvider antallet regulerte sektorer betydelig og deler de berørte virksomhetene inn i vesentlige og viktige enheter. Artikkel 41 satte 17. oktober 2024 som frist for at medlemsstatene skulle vedta og kunngjøre reglene som gjennomfører direktivet.

#Status for gjennomføringen av NIS2 i Spania

Per 14. oktober 2026 finnes det ingen spansk regel i BOEs database over konsolidert lovgivning som gjennomfører NIS2. Gjeldende rammeverk er fortsatt Real Decreto-ley 12/2018 om sikkerhet i nettverk og informasjonssystemer, som gjennomførte det første NIS-direktivet og er utfylt av Real Decreto 43/2021. Artikkel 19 pålegger operatører av samfunnsviktige tjenester og leverandører av digitale tjenester å melde fra om hendelser, og de gjør det via sitt CSIRT. Artikkel 11 legger virksomheter som ikke hører til offentlig sektor slik den er definert i Ley 40/2015, til INCIBE-CERT. Med mindre byrået selv er operatør av samfunnsviktige tjenester eller leverandør av digitale tjenester i lovens forstand, er det ikke byrået som har meldeplikten. Det byrået derimot får, er kontraktskravene fra regulerte kunder.

#NIS2-krav til WordPress-byråer i leverandørkjeden

En av de viktigste nyhetene i NIS2 er vekten på cybersikkerhet i leverandørkjeden. Artikkel 21.2 regner sikkerhet i leverandørkjeden blant minimumstiltakene for risikostyring, med sikkerhetssidene ved forholdet mellom hver virksomhet og dens direkte leverandører (bokstav d), og bruk av flerfaktorautentisering der det er relevant (bokstav j). Artikkel 21.3 ber i tillegg virksomhetene vurdere sårbarhetene hos hver leverandør og kvaliteten på leverandørens praksis for cybersikkerhet, inkludert rutinene for sikker utvikling.

Hvis byrået ditt utvikler, hoster eller vedlikeholder et WordPress-nettsted for en regulert virksomhet, er det rimelig å regne med at kunden tar disse tiltakene inn i kontrakten:

• Tilgangskontroll og MFA: tofaktorautentisering for alle administratorkontoer i CMS-et og i serverens kontrollpaneler.
• Hendelsesrunbook: en dokumentert prosedyre for å varsle kunden uten opphold, slik at kunden kan overholde sine egne frister. Artikkel 23.4 i NIS2 krever at den regulerte virksomheten sender et tidlig varsel innen 24 timer etter at den ble kjent med en betydelig hendelse, en melding innen 72 timer og en sluttrapport senest en måned etter meldingen.
• Revisjon av avhengigheter: jevnlig gjennomgang av WordPress-utvidelsene som brukes i produksjon, for å hindre angrep på leverandørkjeden (for eksempel bakdører smuglet inn i oppdateringer av populære utvidelser).

#Slik tilpasser du WooCommerce til VeriFactu

Real Decreto 1007/2023 vedtar forskriften som fastsetter kravene til datasystemer for fakturering, kjent som VeriFactu-forskriften. Artikkel 8 krever at disse systemene sikrer integritet, oppbevaring, tilgjengelighet, lesbarhet, sporbarhet og uforanderlighet for fakturaregistreringene.

#Tekniske krav til WooCommerce

For WooCommerce-butikker som selger i det spanske markedet, må faktureringen følge forskriften:

• QR-kode: fakturaen har en QR-kode med data som mottakeren frivillig kan sende til skattemyndigheten (artikkel 17).
• Integritet i registreringene: registreringene kan ikke endres uten at systemet oppdager det og varsler. Enhver korrigering eller annullering gjøres med minst én ny, senere fakturaregistrering, slik at de opprinnelige dataene bevares (artikkel 8.2 a). Registreringene er lenket sammen, slik at rekkefølgen kan følges fra den første til den siste (artikkel 8.2 b).
• To moduser: systemet kan sende alle registreringene til AEAT automatisk og umiddelbart, og regnes da som et “Sistema VERI*FACTU” som antas å oppfylle kravene gjennom utformingen (artikkel 16). Sender det dem ikke, må det signere registreringene elektronisk (artikkel 16.3 unntar bare VERI*FACTU-systemer fra signaturen).
• Egenerklæring: programvareprodusenten bekrefter at systemet oppfyller forskriften med en egenerklæring (declaración responsable) som er synlig i hver versjon (artikkel 13). Forskriften legger ikke opp til noen godkjenning av programvaren fra skattemyndighetene.

WordPress-byråer bør unngå generiske utvidelser som lagrer redigerbare registreringer, og heller integrere WooCommerce via API-er med ERP-systemer eller faktureringsprogramvare der produsenten leverer en slik egenerklæring.

#Frister for VeriFactu i WooCommerce-butikker

Fjerde sluttbestemmelse (disposición final cuarta) i Real Decreto 1007/2023, i den formen den fikk gjennom Real Decreto-ley 15/2025 av 2. desember, setter disse fristene:

• Skattytere som betaler selskapsskatt (Impuesto sobre Sociedades): systemene må være tilpasset før 1. januar 2027.
• Øvrige pliktige etter artikkel 3.1 (skattytere som betaler inntektsskatt, IRPF, og driver økonomisk virksomhet, ikke-bosatte med fast driftssted og enheter i ordningen for tilordning av inntekt): systemene må være i drift før 1. juli 2027.
• Produsenter og forhandlere av programvare: produktene må være tilpasset innen ni måneder etter at den utfyllende ministerforskriften trer i kraft.

Artikkel 3.3 holder utenfor skattytere som fører registrene etter artikkel 62.6 i merverdiavgiftsforskriften (Reglamento del IVA), altså via Suministro Inmediato de Información (SII). For alle andre må faktureringssystemet være tilpasset innen disse datoene, og i mange små butikker er det nettopp WooCommerce som lager fakturaen.

#Sjekkliste for regeletterlevelse med WordPress i Spania

Her er en teknisk sjekkliste over de viktigste elementene som må settes opp i enhver WordPress-installasjon for det spanske markedet for å oppfylle regelverket fullt ut i 2026:

graph TD
    A[Regeletterlevelse i Spania] --> B[Personvern & GDPR]
    A --> C[Formelle plikter & LSSI]
    A --> D[Sikkerhet & NIS2]
    A --> E[Fakturering & VeriFactu]

    B --> B1["Google Fonts hostet lokalt"]
    B --> B2["Servere med DPA innenfor EU"]
    B --> B3["Sporingsskript blokkert på forhånd"]

    C --> C1["Synlig Aviso Legal, personvern- og cookiesider"]
    C --> C2["Cookiebanner med likeverdige knapper"]
    C --> C3["Uttrykkelig og informert samtykke"]

    D --> D1["Tofaktorautentisering (MFA) for administratorer"]
    D --> D2["Hendelseslogg og systemlogger"]
    D --> D3["Automatisk revisjon av installerte utvidelser"]

    E --> E1["Fakturaer som ikke kan endres"]
    E --> E2["Programvare med VeriFactu-egenerklæring"]
    E --> E3["IGIC på Kanariøyene og IPSI i Ceuta og Melilla"]

#Sjekkliste for oppsett av WordPress og WooCommerce

• Lokale skrifter: fjern alle kall til fonts.googleapis.com eller fonts.gstatic.com.
• Ingen ekstern CDN: sørg for at bilder og statiske ressurser leveres fra domener under EU-kontroll.
• Oppdaterte retningslinjer: tilgjengelige lenker i bunnteksten til personvernerklæring, Aviso Legal og cookieerklæring.
• Cookiebanner som følger reglene: sett opp verktøyet du har valgt (som Cookiebot, Complianz eller en lett egenutviklet løsning på Cloudflare Workers) etter AEPDs cookieveiledning, med avvis-knappen i det første laget.
• Sikkerhet i WordPress:
  • Begrens antall mislykkede innloggingsforsøk (med sikkerhetsutvidelser eller på proxynivå i Cloudflare).
  • Endre standardprefikset for WordPress-databasen (wp_) under installasjonen.
  • Installer en utvidelse for aktivitetslogg som registrerer kritiske handlinger fra administratorer.
• WooCommerce:
  • Sett opp fraktsoner og avgiftsberegning for Kanariøyene (IGIC), Ceuta og Melilla (IPSI).
  • Legg til egne felt for NIF/CIF i faktureringsskjemaet i kassen.
  • Koble kassen til betalingsløsninger som bruker den sterke kundeautentiseringen PSD2 krever (3D Secure 2 ved kortbetaling).

#Konklusjon

Regeletterlevelse for et bedriftsnettsted eller en nettbutikk i Spania er ikke lenger en enkel gjennomgang av juridiske tekster som kan løses med ferdige maler. I 2026 henger lovligheten tett sammen med plattformens design og tekniske arkitektur.

Byråer som tar en proaktiv tilnærming med innebygd sikkerhet og personvern som standard, reduserer ikke bare betydelige juridiske risikoer for kundene sine. De får også et klart konkurransefortrinn når de skal vinne de største og mest verdifulle prosjektene på det iberiske markedet.

#Slik unngår du sanksjoner fra AEPD i WordPress

Regeletterlevelse i det spanske digitale økosystemet krever proaktiv teknisk oppfølging:

• Håndtering av internasjonale dataoverføringer: etter flere europeiske rettsavgjørelser om transatlantiske dataflyter må administratorer sørge for at leverandører av hosting, analyse og automatisering ikke overfører data til jurisdiksjoner uten tilstrekkelige garantier uten brukerens uttrykkelige samtykke.
• Protokoll over behandlingsaktiviteter (RAT) i WordPress: alle virksomheter må dokumentere kontaktskjemaer, kundedatabaser i WooCommerce og tilgangslogger for registrerte brukere grundig. Når disse rutinene bygges direkte inn i prosjektets tekniske dokumentasjon, står virksomheten godt rustet ved et eventuelt tilsyn fra det spanske datatilsynet. Juridisk grundighet beskytter verdien av virksomheten.

#Sikkerhetskopier og GDPR-opplæring for WordPress-team

God praksis for cybersikkerhet reduserer juridisk og operasjonell risiko på nett:

• Kontrollerte oppdateringer og uforanderlige sikkerhetskopier: automatiserte sikkerhetskopier i datasentre i Europa gir rask gjenoppretting etter løsepengevirusangrep eller maskinvarefeil.
• Opplæring av redaksjonen: når skribentene lærer å håndtere bilder, forfatterrettigheter og personopplysninger på en ansvarlig måte, bygger virksomheten en varig kultur for regeletterlevelse.