Databrud på webshoppen: anmeld til Datatilsynet inden 72 timer

Et databrud, eller brud på persondatasikkerheden, er ifølge GDPR et brud på sikkerheden, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger.

Datatilsynet deler det op i tre typer:

To ting er vigtige. For det første skal der være personoplysninger involveret. Mislykkede loginforsøg er en sikkerhedshændelse, men ikke et databrud, så længe ingen kom ind. For det andet er det nok, at uvedkommende har haft mulighed for at se oplysningerne. Har en mappe med kundedata ligget åbent på nettet, er det et brud, også selvom I ikke ved, om nogen har kigget.

Som webshop er I dataansvarlige for jeres kunders oplysninger. Det er derfor jer, der skal vurdere, anmelde og underrette, også når bruddet sker hos hostingudbyderen, platformen eller bureauet.

Bruddet skal anmeldes uden unødig forsinkelse og om muligt senest 72 timer efter, at I er blevet bekendt med det. Uret starter altså ikke, når bruddet skete, men når I ved, at det er sket.

Datatilsynets vejledning præciserer det sådan:

• I er som udgangspunkt bekendt med bruddet, når en medarbejder bliver det. Det er ikke nok, at ejeren eller ledelsen ikke har hørt om det endnu.
• En formodning er ikke nok til at starte uret, men den forpligter jer til at undersøge sagen hurtigst muligt, også sammen med leverandører og databehandlere.
• Når I efter en hurtig undersøgelse har rimelig vished, skal I anmelde hurtigst muligt og senest inden 72 timer.
• Er I stadig i tvivl, men kan ikke afvise, at det er et brud, bør I anmelde. Viser det sig senere ikke at være et brud, kan I meddele Datatilsynet det.
• Fristen gælder også i weekender og på helligdage. Ferie eller sygdom hos den, der plejer at anmelde, er ifølge Datatilsynet generelt ikke en gyldig grund til at komme for sent.
• Kan I ikke nå at få det fulde billede, skal I anmelde så fyldestgørende som muligt inden for fristen og sende resten trinvist bagefter.
• Anmelder I efter 72 timer, skal I give en begrundelse for forsinkelsen.

Bruger I en hostingudbyder, en platform eller et bureau, der behandler kundedata for jer, skal de underrette jer uden unødig forsinkelse, når de opdager et brud. De må ikke selv vurdere, at det er for lille til at nævne. Det bør stå i databehandleraftalen, hvordan og hvor hurtigt det sker.

Skriv tidspunktet ned, så snart nogen opdager noget, med dato, klokkeslæt og tidszone. Det er det tidspunkt, fristen regnes fra, og det er det første punkt i tidslinjen, som vi viser længere nede.

Udgangspunktet er, at et databrud skal anmeldes. Det eneste, der fritager jer, er hvis det er usandsynligt, at bruddet indebærer en risiko for de berørte personers rettigheder.

Datatilsynet beskriver risiko som sandsynligheden for et negativt udfald gange alvoren af det. Typiske konsekvenser er identitetstyveri, svindel, økonomisk tab, skade på omdømme og diskrimination. Vurderingen ser blandt andet på:

• hvilken type brud det er
• hvilke og hvor mange oplysninger der er berørt
• hvor let det er at identificere personerne
• hvem der har fået adgang, fx en kollega eller en kriminel
• hvor længe bruddet har stået på
• om der er særligt sårbare personer, fx børn
• hvor mange personer der er berørt

Bevisbyrden ligger hos jer. Vil I undlade at anmelde, skal I kunne vise, at bruddet ikke kan få konsekvenser. Ved uautoriseret adgang til et system betyder det i praksis troværdige logs, der dækker hele perioden, som ikke er manipuleret, og som viser, at ingen uvedkommende har tilgået data. Kan I ikke undersøge det inden for 72 timer, skal I som udgangspunkt anmelde.

For en webshop, hvor en hacker har været inde i admin eller på serveren, vil det sjældent være muligt at bevise, at ingen kundedata er set. Har angriberen haft root eller adgang til hostingpanelet, kan logfilerne på serveren være ændret, og så er de ikke troværdige alene. Det taler for at anmelde. De næste to afsnit handler om, hvordan I sikrer de spor, der findes, og bruger dem til at afgrænse bruddet.

Det første tekniske skridt er at stoppe bruddet uden at ødelægge sporene. Gendanner I serveren fra backup, eller sletter I den ukendte admin-bruger, før noget er kopieret, forsvinder netop det, der skal bruges til at vurdere bruddet. Rækkefølgen er: kopiér, beregn hash, flyt kopien væk fra serveren, og ryd derefter op.

Logs fra hosting, CDN og betalingsudbyder ligger hos leverandøren og kan have kort levetid. Bed om udtræk med det samme.

Her er et minimalt sæt kommandoer til at sikre spor på en Linux-server med WordPress. Kør dem som en bruger med læseadgang til logs, og gem alt i en mappe pr. sag:

SAG=databrud-2026-10-21
mkdir -p ~/$SAG && cd ~/$SAG

# Logs inkl. roterede filer, med bevarede tidsstempler
cp -a /var/log/nginx ./nginx-logs

# Filer med ændringstid (mtime) og statusændring (ctime) i UTC
TZ=UTC find /var/www/webshop -type f -printf '%T+ %C+ %s %p\n' | sort > filer-tider-utc.txt

# Admin-brugere og databasen, som de så ud ved opdagelsen
wp --path=/var/www/webshop user list --role=administrator --format=csv > admins.csv
wp --path=/var/www/webshop db export db-ved-opdagelse.sql --single-transaction

# Hash af alt, så I senere kan vise, at kopierne ikke er ændret
find . -type f ! -name SHA256SUMS -exec sha256sum {} + > SHA256SUMS

Kopiér derefter mappen til et sted uden for serveren, fx med rsync -a eller scp, og kør sha256sum -c SHA256SUMS på kopien. Passer alle linjer, er kopien identisk med originalen.

To detaljer er vigtige. Mtime kan sættes til hvad som helst med touch, så en angriber kan få en ændret fil til at se gammel ud. Ctime opdateres af systemet, når filens metadata ændres, og kan ikke sættes med touch. En fil, hvor ctime er meget nyere end mtime, er værd at se nærmere på. Og databasedumpet indeholder kundedata, så det skal behandles lige så fortroligt som produktionsdatabasen.

Tidszoner. Kilderne bruger ikke samme ur, og en fejl på en time eller to kan flytte ordrer ind og ud af det berørte vindue:

Skriv tidslinjen i UTC og dansk tid i parentes. Husk sommertiden: natten til 25. oktober 2026 går Danmark fra UTC+2 til UTC+1. Med GNU date kan et tidsstempel med offset omregnes: date -u -d '2026-10-21 09:40:12 +0200' '+%F %T'.

Log-retention. Spor kan kun sikres, hvis de findes. Skimmere og bagdøre sidder ofte i uger, før nogen opdager dem, og hvis access-loggen kun gemmes i 14 dage, kan I ikke afgrænse bruddet bagud og må regne med den værst tænkelige periode. Retention står i logrotate, hvor rotate er antallet af roterede filer, der gemmes. Logs indeholder IP-adresser og er derfor personoplysninger, så perioden skal kunne begrundes. Der er ingen fast dansk regel for, hvor længe; vælg en periode, der dækker den tid, det realistisk tager at opdage et brud, og skriv begrundelsen ned:

/var/log/nginx/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    dateext
}

Send også logs løbende til et sted uden for webserveren. En angriber med root kan slette lokale logs, men ikke dem, der allerede er sendt væk. Tjek desuden databasens binære log med SHOW VARIABLES LIKE 'log_bin';. I MySQL 8.4 er den slået til som standard med 30 dages udløb, men på mange hostingopsætninger er den slået fra.

Anmeldelsen skal angive kategorier af personer og oplysninger og omtrent hvor mange. Det tal kommer fra to kilder: logs, der viser hvornår og hvordan angriberen var inde, og databasen, der viser hvilke kunder og ordrer der lå i det vindue. Kør forespørgslerne mod en kopi, fx en gendannet backup eller dumpet fra før, ikke mod den ramte server.

Find vinduet i loggen. Start med en kendt indikator, typisk en mistænkelig IP eller en ukendt fil, og find første og sidste forespørgsel. I nginx' og Apaches standardformat er felt 1 IP, felt 4 tidspunkt, felt 7 URL, felt 9 statuskode og felt 10 antal bytes i svaret:

# Alt fra en IP i alle logs, også komprimerede
zcat -f /var/log/nginx/access.log* | grep '^203\.0\.113\.45 ' | awk '{print $4, $7, $9, $10}'

# Store svar, som kan være et dataudtræk
zcat -f /var/log/nginx/access.log* | awk '$9 == 200 && $10 > 5000000 {print $1, $4, $7, $10}'

# Kald til WooCommerces REST-API for kunder og ordrer
zcat -f /var/log/nginx/access.log* | grep -E '/wp-json/wc/v[0-9]+/(customers|orders)'

# PHP-filer kaldt fra uploads er et tydeligt tegn på en bagdør
zcat -f /var/log/nginx/access.log* | grep -E '/wp-content/uploads/.*\.php'

Find platform og tabeller. I WordPress kan tabelprefixet være andet end wp_, og WooCommerce kan gemme ordrer i to forskellige strukturer. Tjek begge dele, før I skriver SQL:

wp config get table_prefix
# yes = ordrer ligger i wp_wc_orders (HPOS), ellers i wp_posts og wp_postmeta
wp option get woocommerce_custom_orders_table_enabled

WooCommerce med HPOS. Ordrer ligger i wp_wc_orders, og navne, adresser og telefonnumre i wp_wc_order_addresses. date_created_gmt er i UTC, så vinduet skal angives i UTC:

SELECT o.id, o.date_created_gmt, o.billing_email, o.payment_method,
       a.first_name, a.last_name, a.phone, a.postcode
FROM wp_wc_orders o
JOIN wp_wc_order_addresses a ON a.order_id = o.id AND a.address_type = 'billing'
WHERE o.type = 'shop_order'
  AND o.date_created_gmt BETWEEN '2026-10-14 08:12:00' AND '2026-10-21 07:40:00'
ORDER BY o.date_created_gmt;

SELECT COUNT(*) AS ordrer, COUNT(DISTINCT o.billing_email) AS personer
FROM wp_wc_orders o
WHERE o.type = 'shop_order'
  AND o.date_created_gmt BETWEEN '2026-10-14 08:12:00' AND '2026-10-21 07:40:00';

Bruger shoppen den ældre struktur, ligger ordren i wp_posts med post_type = 'shop_order', og kundens mail i wp_postmeta under nøglen _billing_email:

SELECT p.ID, p.post_date_gmt, pm.meta_value AS billing_email
FROM wp_posts p
JOIN wp_postmeta pm ON pm.post_id = p.ID AND pm.meta_key = '_billing_email'
WHERE p.post_type = 'shop_order'
  AND p.post_date_gmt BETWEEN '2026-10-14 08:12:00' AND '2026-10-21 07:40:00';

Er hele databasen hentet, er vinduet ligegyldigt, og så er spørgsmålet, hvor mange personer der overhovedet findes. wp_wc_customer_lookup samler kunder til WooCommerces statistik og indeholder også gæstekunder. Adgangskoder er relevante for vurderingen: WordPress gemmer kun hashes, og fra version 6.8 bruges bcrypt med prefixet $wp$2y$, mens ældre hashes med $P$ (phpass) først opgraderes, når brugeren logger ind igen. Fordelingen fortæller, hvor svære hashene er at knække. Tjek også API-nøgler, fordi en lækket nøgle giver adgang til kunder og ordrer uden login:

SELECT COUNT(*) FROM wp_users;
SELECT COUNT(*) FROM wp_wc_customer_lookup;

SELECT LEFT(user_pass, 4) AS hashtype, COUNT(*) FROM wp_users GROUP BY hashtype;

SELECT key_id, user_id, description, permissions, truncated_key, last_access
FROM wp_woocommerce_api_keys
ORDER BY last_access DESC;

PrestaShop. Ordrer ligger i ps_orders, kunder i ps_customer og adresser i ps_address. Prefixet ps_ er standard før version 9, men fra PrestaShop 9 er det tilfældigt genereret, så tjek database_prefix i shoppens konfiguration. date_add er gemt uden tidszone, typisk i shoppens lokaltid:

SELECT o.id_order, o.reference, o.date_add, c.email, c.firstname, c.lastname,
       a.address1, a.postcode, a.city, a.phone
FROM ps_orders o
JOIN ps_customer c ON c.id_customer = o.id_customer
JOIN ps_address a ON a.id_address = o.id_address_invoice
WHERE o.date_add BETWEEN '2026-10-14 10:12:00' AND '2026-10-21 09:40:00';

SELECT id_employee, email, id_profile, active, last_connection_date FROM ps_employee;
SELECT date_add, id_employee, severity, message FROM ps_log
WHERE date_add >= '2026-10-14' ORDER BY date_add;

Gem hver forespørgsel som en fil sammen med resultatet. Så kan tallet i anmeldelsen spores tilbage til præcis den forespørgsel, der gav det, og den kan køres igen, hvis vinduet ændrer sig.

Anmeldelsen sker via virk.dk i løsningen "Indberetning af brud på sikkerhed". Det er en fælles blanket, hvor I kan indberette til flere myndigheder på én gang, men de fleste skal kun indberette til Datatilsynet. Datatilsynet har altid et opdateret link på sin side "Anmeld sikkerhedsbrud".

1. Find frem til blanketten via datatilsynet.dk eller direkte på virk.dk.
2. Log ind med MitID. Sørg for, at den person, der skal anmelde, har adgang, før det brænder. Det kan også være en rådgiver eller databehandler med fuldmagt, men ansvaret bliver hos jer.
3. Besvar de indledende spørgsmål om, hvorvidt hændelsen vedrører persondata og eventuelt kritisk infrastruktur. Blanketten er dynamisk, så de næste spørgsmål afhænger af jeres svar.
4. Beskriv bruddet. Hvad skete der, hvilke kategorier af personer og oplysninger er berørt, og omtrent hvor mange.
5. Angiv en kontaktperson, der kan give flere oplysninger.
6. Beskriv de sandsynlige konsekvenser for kunderne.
7. Beskriv, hvad I har gjort og vil gøre, for at standse bruddet og begrænse skaden.
8. Download en kopi, før I lukker. Blanketten går til Erhvervsstyrelsen, som sender den videre. Erhvervsstyrelsen sletter anmeldelser efter 30 dage, så kopien er jeres bevis.

Skriv ikke personoplysninger om de berørte kunder i blanketten ud over det, der spørges om.

Til trin 4 kan I bruge resultatet af afgrænsningen direkte: kategorier af personer (kunder med konto, gæstekunder, medarbejdere), kategorier af oplysninger (navn, adresse, mail, telefon, ordrehistorik, adgangskode-hashes) og antal, gerne som et interval, hvis vinduet ikke er helt fastlagt. Er tallet usikkert, så skriv det og opdater det i en supplerende anmeldelse.

Er I i tvivl om, hvordan et brud skal håndteres, opfordrer Datatilsynet selv til at ringe og få råd på 33 19 32 00. Er I omfattet af NIS2, kan der gælde en kortere frist for væsentlige hændelser, i nogle tilfælde 24 timer, og her kan det være praktisk at anmelde begge dele i samme blanket.

Anmeldelse til Datatilsynet og underretning af kunderne er to forskellige pligter. Kunderne skal kun underrettes, hvis bruddet sandsynligvis indebærer en høj risiko for dem.

Der er ingen fast frist for underretning, men Datatilsynet skriver, at når hackere har fået fat i oplysninger, skal underretning som klart udgangspunkt ske tilnærmelsesvis straks. Formodningen er, at de vil misbruge dem. Høj risiko kan også opstå, selvom sandsynligheden er lav, hvis konsekvensen er alvorlig.

Husk de afledte konsekvenser. Er brugernavne og adgangskoder lækket, kan kunderne have genbrugt dem andre steder. Det er et argument for at underrette, også selvom adgangskoderne kun giver adgang til en kundekonto i shoppen.

Underretningen skal i et klart og forståeligt sprog beskrive:

• hvad der er sket, og hvordan oplysningerne er kommet ud
• hvilke oplysninger der er berørt
• de sandsynlige konsekvenser
• hvad I har gjort og vil gøre
• hvad kunden selv kan gøre, fx skifte adgangskode eller holde øje med sin konto
• hvem kunden kan kontakte

Underretningen må ikke gemmes i et nyhedsbrev eller en generel opdatering, og et opslag på bloggen er typisk ikke nok. Kan I ikke kontakte kunderne direkte, fordi I ikke ved, hvem der er ramt, kan en offentlig meddelelse bruges i stedet. I skal heller ikke underrette, hvis oplysningerne var krypteret, så de er uforståelige for andre, eller hvis I efter bruddet har fjernet den høje risiko. Begge dele skal I kunne begrunde.

Modtagerlisten kommer fra samme forespørgsel som tallet i anmeldelsen, så den er konsistent. Send underretningen fra jeres normale, autentificerede maildomæne og uden links til login. En mail om et databrud er en oplagt skabelon for svindlere, og kunderne skal kunne kende forskel.

Her er tre situationer, vi ser i webshops, og hvordan Datatilsynets vejledning kan bruges på dem. Vurderingen er altid konkret.

1. Lækket kundedata. En angriber kommer ind via et sårbart modul eller et gammelt admin-login og får adgang til kundedatabasen med navne, adresser, mail, telefonnumre og ordrehistorik. Det er et brud på fortroligheden. Kan I ikke med logs bevise, at intet blev hentet, skal det anmeldes. Hvis der også er adgangskoder i databasen, eller hvis data bliver brugt til målrettet phishing, taler meget for at underrette kunderne. Luk hullet, skift alle adgange, og gem logfilerne, før noget slettes. Tilbagekald også API-nøgler og log alle brugere ud, fordi en stjålet session virker, selvom adgangskoden er skiftet.

2. Skimmer i checkout. Der er lagt et script ind i checkout, som sender kortoplysninger og kundedata videre til en fremmed server. Det er et brud på fortroligheden, oplysningerne er havnet hos kriminelle, og risikoen for økonomisk tab er åbenlys. Det skal anmeldes, og kunderne skal som udgangspunkt underrettes hurtigt, så de kan spærre kort og holde øje med deres konto. Kontakt også jeres betalingsudbyder med det samme. Find ud af, hvornår scriptet kom ind, for det afgør, hvilke ordrer der er ramt. Skimmere ligger ofte i databasen frem for i filerne, fx i en indstilling eller en widget, så søg begge steder. wp db search søger på tværs af tabellerne, og --one_line giver tabel, kolonne og række på én linje:

wp db search '<script' wp_options wp_posts --one_line
grep -rlE 'atob\(|eval\(' /var/www/webshop/wp-content/themes /var/www/webshop/wp-content/plugins

Begge giver falske positiver, fordi legitime plugins også bruger scripts og eval. Fundene skal gennemgås manuelt, og ændringstid og ctime fra fillisten fortæller, hvornår en fil blev ændret.

3. Forkert sendt mail. En ordrebekræftelse eller faktura sendes til den forkerte kunde, eller et nyhedsbrev sendes med alle modtagere synlige i CC. Datatilsynet nævner fejlsendte breve og mails direkte som eksempler på brud på fortroligheden. Om det skal anmeldes, afhænger af, hvilke oplysninger der stod, hvor mange der fik dem, og om I kan få modtageren til at bekræfte sletning. Det skal dokumenteres uanset.

Alle databrud skal dokumenteres internt, også dem, I vurderer ikke skal anmeldes.

Datatilsynet har et dokumentationsregister, man kan tage udgangspunkt i:

1. Dato og tidspunkt for bruddet
2. Hvad er der sket
3. Årsagen til bruddet
4. Hvilke typer personoplysninger er berørt
5. Hvilke konsekvenser har bruddet for de berørte personer
6. Hvilke afhjælpende foranstaltninger er truffet
7. Er bruddet anmeldt til Datatilsynet, og hvornår. Hvis nej, hvorfor ikke
8. Er de berørte personer underrettet, og hvornår. Hvis nej, hvorfor ikke

Dokumentér også begrundelsen for de vigtige beslutninger, især hvis I beslutter ikke at anmelde eller ikke at underrette. Kopien af anmeldelsen og af underretningen kan indgå i dokumentationen.

Datatilsynet anbefaler at gemme dokumentationen i fem år efter bruddet, fordi forældelsesfristen for overtrædelser af reglerne er fem år.

Teknisk dokumentation er lige så vigtig: logfiler fra server og shop, en liste over admin-brugere før og efter, kopier af ændrede filer, SHA256SUMS-filen, de SQL-forespørgsler, der gav antallet af berørte, og tidspunkter for, hvornår I opdagede og lukkede hullet. Slet ikke noget, før det er gemt et sted uden for den ramte server.

En tidslinje binder det sammen. Hver linje har et tidspunkt i UTC, en hændelse og en kilde, så en anden kan efterprøve den. Her er en skabelon med et opdigtet forløb:

Sag: databrud-2026-10-21, webshop.dk
Alle tider i UTC, dansk tid (UTC+2) i parentes

TIDSPUNKT                 HÆNDELSE                                          KILDE
2026-10-14 08:12 (10:12)  Første kald fra 203.0.113.45 til sårbart modul    access.log.7.gz
2026-10-14 08:15 (10:15)  Admin-bruger "support2" oprettet                  wp_users.user_registered
2026-10-19 22:03 (00:03)  41 MB svar på eksport-URL til 203.0.113.45        access.log.2.gz
2026-10-21 07:40 (09:40)  Medarbejder ser ukendt admin-bruger               Mail til drift
                          = bekendt med bruddet, frist 2026-10-24 07:40 UTC
2026-10-21 08:05 (10:05)  Spor kopieret og hashet                           SHA256SUMS
2026-10-21 09:30 (11:30)  Modul opdateret, admin slettet, nøgler roteret    Ændringslog
2026-10-21 13:00 (15:00)  Afgrænsning: 1.284 ordrer, 1.102 personer         q-hpos-vindue.sql
2026-10-22 10:00 (12:00)  Anmeldt via virk.dk, kopi gemt                    anmeldelse.pdf
2026-10-22 14:00 (16:00)  Kunder underrettet pr. mail                       underretning.eml

Linjen med "bekendt med bruddet" er den vigtigste. Den fastlægger fristen, og hvis anmeldelsen kommer efter den, skal begrundelsen for forsinkelsen kunne læses ud af tidslinjen.

I Danmark kan Datatilsynet ikke selv udstede bøder. Datatilsynet kan udtale kritik og give påbud, fx om at anmelde eller underrette. Er en bøde passende, politianmelder Datatilsynet sagen og indstiller et beløb, og så er det politi, anklagemyndighed og domstole, der tager den videre.

Manglende anmeldelse og manglende underretning hører under GDPR artikel 83, stk. 4. Her er bødeloftet 10 mio. euro, ca. 75 mio. kr., eller 2 % af den samlede globale årsomsætning, hvis det er højere. Fejl i selve sikkerheden, artikel 32, hører under samme kategori. Andre overtrædelser kan koste op til 20 mio. euro eller 4 %.

Datatilsynet skriver i sin bødevejledning, at manglende anmeldelse af et sikkerhedsbrud i sig selv er en overtrædelse, der kan give bøde. Det er altså ikke kun bruddet, der kan koste, men også at holde det skjult. Grundbeløbene i bødevejledningen er nedsat for mikro-, små og mellemstore virksomheder.

Erstatning er en anden sag. Efter GDPR artikel 82 kan en person, der har lidt materiel eller immateriel skade, kræve erstatning af den dataansvarlige. EU-Domstolen har fastslået, at der ikke er en bagatelgrænse for immateriel skade, men at personen stadig skal påvise en reel skade. En velbegrundet frygt for, at oplysningerne bliver misbrugt, kan efter EU-Domstolens praksis tælle med. En overtrædelse i sig selv er ikke nok.

De fejl, der oftest gør et databrud værre:

• At vente på det fulde overblik. Anmeld det, I ved, inden for 72 timer, og suppler bagefter.
• At tro, det er hostingens problem. Er bruddet sket hos en leverandør, er det stadig jer, der er dataansvarlige og skal anmelde.
• At rydde op, før der er sikret spor. Når serveren gendannes, forsvinder logfilerne, og så kan I ikke bevise, hvad der er sket.
• At blande tidszoner. Et vindue i dansk tid mod en kolonne i UTC rammer forkerte ordrer.
• At skrive en vag underretning. "Vi har haft en sikkerhedshændelse" er ikke nok. Kunden skal kunne forstå, hvad der skete med netop deres oplysninger.
• At ingen kan logge ind på virk.dk. Find ud af det nu, ikke en lørdag aften.

Tjekliste til jeres beredskab:

• Der er udpeget en ansvarlig for databrud og en stedfortræder
• Den ansvarlige kan logge ind og anmelde på virk.dk med MitID
• Databehandleraftaler med hosting, platform og bureau beskriver, hvordan de underretter jer
• Der er en skabelon til intern dokumentation, en tidslinje og en skabelon til underretning af kunder
• I ved, hvor logfilerne fra shop og server ligger, og hvor længe de gemmes, og perioden er længere end to uger
• Logs sendes løbende til et sted uden for webserveren
• Serverens ur er synkroniseret, og I kender tidszonen i hver logkilde
• Der er en læseadgang til databasen eller en testserver, hvor en backup kan gendannes til analyse
• Backup ligger adskilt fra shoppen og kan gendannes
• Kontaktoplysninger til betalingsudbyder, hosting og it-hjælp ligger et sted, alle kan finde
• Medarbejderne ved, at de skal sige til med det samme, hvis de ser noget mistænkeligt

Hvornår starter de 72 timer? Når I er blevet bekendt med bruddet, som udgangspunkt når en medarbejder ved det. Ikke når bruddet skete.

Hvad hvis vi ikke når at anmelde inden 72 timer? Anmeld alligevel, så hurtigt som muligt, og skriv en begrundelse for forsinkelsen. Datatilsynet vurderer, om begrundelsen holder.

Skal en forkert sendt mail anmeldes? Det er et databrud. Om det skal anmeldes, afhænger af risikoen for kunden. Indholdet, antallet af modtagere og om I kan få oplysningerne slettet er afgørende. Dokumentér det uanset.

Kan hostingudbyderen eller bureauet anmelde for os? Ja, hvis de har fuldmagt. Men ansvaret for, at det sker korrekt og til tiden, bliver hos jer.

Hvor længe skal vi gemme logs? Der er ingen fast dansk frist. Logs med IP-adresser er personoplysninger, så perioden skal kunne begrundes, men den skal også være lang nok til, at I kan afgrænse et brud, der først opdages efter flere uger.

Hvad koster det at anmelde for sent? Datatilsynet kan give kritik og påbud eller politianmelde med indstilling om bøde. Loftet for manglende anmeldelse er 10 mio. euro eller 2 % af den globale omsætning, men bøder fastsættes af domstolene ud fra sagen og virksomhedens størrelse.

Kan kunderne kræve erstatning? Ja, efter GDPR artikel 82, hvis de kan påvise en reel skade. Der er ingen bagatelgrænse for immateriel skade.

Et databrud kan ramme alle webshops, og det er sjældent selve bruddet, der bliver det dyreste. Det er de første timer, hvor man ikke ved, hvem der gør hvad, hvor logfilerne er, og hvordan man logger ind på virk.dk. 72 timer er ikke lang tid, når det er weekend, og shoppen samtidig skal køre.

Har I et databrud nu, så gør tre ting i den rækkefølge: stop bruddet uden at slette spor, start dokumentationen, og vurdér, om der skal anmeldes. Kan I ikke vurdere det selv, så anmeld hellere end at lade fristen løbe ud.

Vi hjælper webshops med den tekniske del af et databrud: finde hullet, lukke det, sikre logfiler og få shoppen sikkert op igen. Læs om vores hjælp efter hackerangreb, hvor målet er, at det kører igen inden for 24 timer, og om hvordan vi hjælper med databrud og GDPR, fra vurdering og dokumentation til grundlaget for anmeldelsen. Vil I være klar, før det sker, så kig på en kriseplan for cyberangreb, og læs vores guide til de første timer efter et hack.

Kilder

• Datatilsynet: Anmeld sikkerhedsbrud
• Datatilsynet: Håndtering af brud på persondatasikkerheden
• Datatilsynets vejledning, maj 2025 (PDF)
• virk.dk: Indberetning af brud på sikkerhed
• Datatilsynets bødevejledning (PDF)
• Datatilsynet: Databehandler indstillet til bøde
• Lovguiden om EU-Domstolens dom om immateriel skade
• nginx: log_format
• Apache: log files
• logrotate(8)
• find(1)
• date(1)
• MySQL: tidszoner
• MySQL: binær log
• MySQL: mysqlbinlog
• WooCommerce: High-Performance Order Storage
• WooCommerce: ordretabellernes skema
• WooCommerce: installationsskema
• WordPress 6.8 bruger bcrypt
• WP-CLI: wp db search
• WP-CLI: wp db export
• WP-CLI: wp config get
• WP-CLI: wp user list
• PrestaShop: databasestruktur
• PrestaShop: tabelprefix