D-mærket for webshops: kriterier, pris og sådan kommer I i gang

D-mærket er Danmarks mærkningsordning for it-sikkerhed og ansvarlig dataanvendelse. Det er skabt af Industriens Fond sammen med Dansk Erhverv, Dansk Industri, SMVdanmark og Forbrugerrådet Tænk, og det støttes af Erhvervsstyrelsen. Selve ordningen er en uafhængig privat organisation.

Mærket tildeles på virksomhedsniveau, ikke til et produkt eller en bestemt webshop-platform. Det viser, at virksomheden har dokumenteret, at den lever op til en række krav inden for it-sikkerhed, databeskyttelse og dataetik, og at D-mærkets auditorer har ført tilsyn med dokumentationen. Alle virksomheder med et dansk CVR-nummer kan få det. Udenlandske virksomheder uden dansk CVR-nummer kan ikke.

For en webshop er pointen enkel. Kunder, samarbejdspartnere og større B2B-kunder får et tegn fra en tredjepart på, at I tager deres data alvorligt, og I får selv en struktureret gennemgang af, hvor jeres sikkerhed halter.

Det er vigtigt at vide, hvad mærket ikke er:

• Det er ikke lovpligtigt. GDPR er lovpligtig, D-mærket er et frivilligt tilvalg.
• Det er ikke en garanti mod hackerangreb. D-mærket skriver selv, at mærket ikke beskytter mod hacking og databrud, men at virksomheden står bedre rustet.
• Det er ikke en ISO-certificering. Der står ikke et akkrediteret certificeringsorgan bag. Tilsynet foretages af D-mærkets egne auditorer.
• Det er ikke UL's D Mark. Det mærke bruges på elektrisk udstyr og har intet med it-sikkerhed at gøre.

D-mærket bygger på otte overordnede kriterier. Hvert kriterie har underkriterier og konkrete krav, som varierer fra virksomhed til virksomhed. Underkravene står ikke på hjemmesiden. I ser dem først, når I opretter jer i det gratis selvevalueringsværktøj, hvor hele jeres kriteriesæt også kan downloades som Excel-fil.

For en typisk webshop er kriterie 1-5 kernen. Kriterie 7 bliver relevant, hvis I bruger algoritmer eller AI, fx til produktanbefalinger, en chatbot i kundeservice eller automatisk prissætning. Udvikler I selv software, som andre bruger, kommer kriterie 6 med.

Kriterie 4 er værd at hæfte sig ved. En webshop er sjældent ét system. Der er en platform, en hostingudbyder, en betalingsudbyder, et fragtmodul, et mailsystem, et regnskabsprogram og ofte et bureau eller en freelancer. Kriteriet handler om, at I ved, hvem de er, hvad de har adgang til, og at I stiller krav til, hvordan de passer på jeres data.

Når I starter selvevalueringen, bliver I som et af de første trin placeret i en af fire virksomhedsgrupper. Gruppen afgør, hvor mange kriterier I skal leve op til, og hvad tilsynet koster. Placeringen afhænger af virksomhedens størrelse, forretningsmodel og brug af data- og it-tjenester. På prissiden nævner D-mærket fire faktorer: antal medarbejdere, omsætning, om I er leverandør af it eller software, og om I behandler personfølsomme data.

Antallet af kriterier er det interval, D-mærket selv oplyser for hver gruppe. Til sammenligning har ISO/IEC 27001 93 foranstaltninger.

En mindre webshop med få ansatte og en standardplatform vil ofte høre til i gruppe I eller II. Bemærk dog, at it- og softwareleverandører rykkes op i gruppe III uanset størrelse, fordi D-mærket vurderer, at de har en højere risikoprofil. Sælger I også et modul, en app eller en SaaS-løsning ved siden af shoppen, kan I altså lande højere, end jeres størrelse tilsiger.

Gruppen ligger ikke fast. Vokser I eller ændrer forretningsmodel, skal I selv opdatere indplaceringen under "Organisation" i selvevalueringsværktøjet. Jeres svar bliver gemt, når I skifter gruppe.

Selvevalueringen er gratis. I betaler først, når I anmoder om tilsyn, og prisen afhænger af virksomhedsgruppen. Alle priser er uden moms.

Der er to rabatter. Virksomheder, der rykkes fra gruppe I til gruppe III, fordi de er leverandør af it eller software, får 55 % rabat. Rykkes man fra gruppe II til gruppe III af samme grund, er rabatten 40 %.

Vælger I NIS2-modulet til, bliver I automatisk placeret i gruppe III eller IV, også selvom I ellers hørte til i gruppe I eller II. Det skyldes ifølge D-mærket, at NIS2-kravene kun dækkes af kriterierne i de højere grupper.

Mærket gælder ét år ad gangen, og gentildeling kræver et nyt tilsyn. Prissiden nævner ikke en særskilt pris for gentildeling, så budgettér med, at der kommer en tilsynsudgift hvert år, og få prisen bekræftet af D-mærket.

Den største udgift er sjældent selve tilsynet. Det er tiden til at lukke hullerne og skrive dokumentationen: politikker, leverandøroversigt, beredskabsplan, adgangsgennemgang og bevis for, at backup og opdateringer faktisk virker.

Forløbet består af en gratis selvevaluering, et betalt tilsyn og en årlig gentildeling.

1. Opret jer i selvevalueringen på digital.d-maerket.dk. Et CVR-nummer kan kun oprettes én gang. Har en tidligere medarbejder oprettet jer, skal I bede om en ny adgangskode eller kontakte D-mærket.
2. Besvar spørgsmålene. Svarene holdes op mod kriterierne, og I får jeres gruppe og det kriteriesæt, I skal leve op til. I praksis får I en gap-analyse, der viser, hvor I allerede er, og hvor der mangler noget.
3. Luk hullerne. I kan anmode om tilsyn, når I kan svare ja til alle spørgsmål eller har en kompenserende kontrol, og når I kan dokumentere svarene.
4. Anmod om tilsyn med knappen "Anmod om tilsyn" i værktøjet. I får en tro- og loveerklæring, som en tegningsberettiget skal underskrive, og en faktura.
5. Hold opstartsmøde med auditor. Efter underskrift og betaling holder I et kickoff-møde med D-mærkets auditorer, som forklarer forløbet og lægger en plan med jer.
6. Upload dokumentation. Auditorerne gennemgår den. Tilsynet er primært en dokumentkontrol med stikprøver, suppleret med fremvisning og interviews, hvor det giver bedre kontrol. Det årlige tilsyn dækker udvalgte kontrolmål, og omfanget står i tilsynsrapporten.
7. Få mærket og rapporten. Når dokumentationen er godkendt, bliver I tildelt mærket og får en tilsynsrapport, som kan indeholde en observationsliste over, hvad auditor forventer forbedret til næste gang.
8. Forny hvert år. Tre måneder før udløb får I en påmindelse på mail. Knappen til nyt tilsyn bliver aktiv en måned før udløb.

Mærket gælder et år ud over den løbende måned. Tildeles det fx 5. februar 2026, udløber det 1. marts 2027. Vælger I ikke at forny, skal mærket fjernes fra hjemmesiden og al markedsføring.

I kan undervejs booke et gratis sparringsmøde med en auditor. D-mærket oplyser ikke, hvor lang tid forløbet typisk tager.

Et praktisk råd til trin 6: læg dokumentationen i en mappe pr. kriterie, og navngiv hver fil med dato og kilde, fx 2026-10-21_wp-admin-brugere.csv eller 2026-10-21_tls-test_webshop.dk.txt. Et skærmbillede uden dato og uden synlig URL er svært at bruge som bevis, både for auditor og for jer selv om et år.

D-mærket offentliggør ikke de konkrete tekniske underkrav i kriterie 3, Teknisk it-sikkerhed. Men D-mærkets egen vejledning om it-sikkerhed peger på de steder, hvor angreb typisk kommer ind: manglende to-faktor, svage adgangskoder, manglende opdateringer, gamle adgange og leverandører med lavt sikkerhedsniveau. Oversat til en webshop ser det sådan ud:

Det sidste punkt hænger direkte sammen med GDPR. Får en webshop et databrud, skal det som udgangspunkt anmeldes til Datatilsynet inden for 72 timer, og det er svært at nå, hvis ingen har tænkt det igennem på forhånd. Vi har skrevet en særskilt guide til databrud og 72-timersfristen.

D-mærket nævner selv, at adgange ofte bliver oprettet hurtigt, men sjældent fjernet igen, og anbefaler at gennemgå brugere med særligt fokus på admin-rettigheder, tidligere ansatte, delte konti og leverandøradgange.

Tabellen siger, hvad der skal være på plads. For tilsynet er det næste spørgsmål, hvordan I viser det. Her er vores forslag til en kontrol og et bevis pr. område. Det er ikke D-mærkets officielle krav, men en måde at gøre jeres ja efterprøveligt på:

Mange af punkterne er de samme, som vi går igennem i et sikkerhedstjek af sitet. Vil I starte med det tekniske fundament, er to-faktor og adgangsstyring og backup og gendannelse de to områder, der flytter mest.

Kryptering i transit er det område, hvor det er nemmest at levere et objektivt bevis, fordi alt kan testes udefra. Der er tre ting at se på: hvilke protokolversioner serveren accepterer, om certifikatet er gyldigt og bliver fornyet automatisk, og om browseren bliver tvunget til at bruge HTTPS.

Protokolversioner. TLS 1.0 og 1.1 er formelt udfaset i RFC 8996, der siger, at de ikke må bruges. Serveren bør altså kun acceptere TLS 1.2 og 1.3. Med openssl s_client kan I teste hver version for sig. -servername sender SNI, så I rammer det rigtige certifikat, når flere domæner ligger på samme IP, og -brief giver en kort opsummering i stedet for hele handshaket:

# Skal lykkes
openssl s_client -connect webshop.dk:443 -servername webshop.dk -tls1_2 -brief </dev/null
openssl s_client -connect webshop.dk:443 -servername webshop.dk -tls1_3 -brief </dev/null

# Skal fejle med en handshake-fejl
openssl s_client -connect webshop.dk:443 -servername webshop.dk -tls1_1 -brief </dev/null

Fejler TLS 1.1-testen, er det ikke nødvendigvis serveren, der afviser. Nyere OpenSSL-versioner kan selv have slået gamle protokoller fra på klientsiden. Derfor er en ekstern test som Qualys SSL Labs Server Test et godt supplement. Den tester protokoller, cipher suites og certifikatkæde og giver en karakter efter en offentlig rating-guide, og rapporten kan gemmes som bevis.

Certifikatet. Næste kommando henter certifikatet og viser, hvem det er udstedt til og af, hvornår det udløber, og hvilke domænenavne det dækker. -checkend returnerer en fejlkode, hvis certifikatet udløber inden for det antal sekunder, I angiver, her 14 dage, så den kan bruges i en overvågning:

openssl s_client -connect webshop.dk:443 -servername webshop.dk </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

openssl s_client -connect webshop.dk:443 -servername webshop.dk </dev/null 2>/dev/null \
  | openssl x509 -noout -checkend 1209600 && echo "OK" || echo "Udløber inden 14 dage"

-ext findes ikke i den LibreSSL, macOS leveres med, så kør kommandoen på serveren. Bruger I Let's Encrypt med Certbot, viser certbot certificates alle certifikater med udløbsdato, og certbot renew --dry-run tester fornyelsen mod Let's Encrypts testmiljø uden at gemme noget. Certifikaters levetid bliver gradvist kortere frem mod 47 dage, så automatisk fornyelse er ikke længere valgfri. Læs mere i vores artikel om SSL-certifikater med 47 dages levetid.

Headers. curl -I sender en HEAD-forespørgsel, og nogle applikationer og CDN'er svarer anderledes på HEAD end på GET. Det sikreste er en almindelig GET, hvor headers skrives til skærmen med -D -, og selve siden smides væk:

curl -sS -D - -o /dev/null https://webshop.dk/ \
  | grep -iE '^(strict-transport-security|content-security-policy|x-content-type-options|x-frame-options|referrer-policy|permissions-policy):'

# Bliver http omdirigeret til https?
curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://webshop.dk/

Den sidste skal give en 301 eller 308 til https://webshop.dk/. Kør også kommandoerne mod checkout-siden, fordi den ofte ligger under en anden regel i serverkonfigurationen.

En fuld Content-Security-Policy med script-src er et projekt i sig selv på en webshop med betalingsmoduler, tracking og chat. Start med Content-Security-Policy-Report-Only, som rapporterer overtrædelser uden at blokere noget, og stram til, når I kender jeres kilder.

Konfiguration. I nginx sættes protokoller og headers i server-blokken. Parameteren always sørger for, at headeren også sendes på fejlsider og omdirigeringer, og ikke kun på svar med fx status 200. Vær opmærksom på, at add_header kun arves fra et højere niveau, hvis der ikke står nogen add_header på det aktuelle niveau. Har en location-blok sin egen add_header, forsvinder alle headers fra server-blokken der:

server {
    listen 443 ssl;
    server_name webshop.dk www.webshop.dk;
    ssl_protocols TLSv1.2 TLSv1.3;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "frame-ancestors 'self'" always;
}

Start HSTS med en lav max-age, fx 300 sekunder, og hæv den, når I har tjekket, at alle subdomæner virker på HTTPS. includeSubDomains rammer også fx et gammelt nyhedsbrev.webshop.dk uden certifikat. Direktivet preload er ikke en del af RFC 6797, men et krav for at komme på browsernes preload-liste via hstspreload.org, der kræver mindst et års max-age og includeSubDomains. Det er svært at blive fjernet fra listen igen, så det er et bevidst valg, ikke en standardindstilling.

Et godt bevis er reproducerbart: en kommando eller et udtræk med dato, som en anden kan køre igen. Eksemplerne er til WordPress og WooCommerce med WP-CLI, men principperne gælder for alle platforme.

Adgange. Start med et udtræk af alle brugere med administrative roller. shop_manager er WooCommerces egen rolle med adgang til ordrer og kunder, så den skal med. Gem output med dato i filnavnet:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --format=csv \
  > "$(date +%F)_admin-brugere.csv"
wp user list --role=shop_manager --fields=ID,user_login,user_email,user_registered --format=csv \
  > "$(date +%F)_shop-managers.csv"

# Aktive sessioner for en bruger: login-tid, udløb, IP og browser
wp user session list jens@webshop.dk --format=table

Gå listen igennem med den, der kender organisationen. Ukendte konti, bureau-mails fra tidligere samarbejder og delte konti er de klassiske fund. På PrestaShop ligger back office-brugerne i tabellen ps_employee, hvor last_connection_date viser seneste login. Prefixet ps_ er standard før PrestaShop 9, men tilfældigt genereret fra version 9.

MFA. WordPress har ikke to-faktor i kernen, så det kommer fra et plugin eller fra jeres identitetsudbyder. Test det ved at logge ind fra et privat vindue, og gem en liste over systemer med admin-adgang, hvilken faktor der bruges, og hvornår det sidst er kontrolleret.

Opdateringer. Tre kommandoer giver et dateret billede af versionerne. --update=available er WP-CLI's generelle feltfilter på kolonnen update:

wp core version
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available
php -v

PHP-versionen holdes op mod php.net's liste over understøttede versioner. I skrivende stund får PHP 8.2 sikkerhedsopdateringer til 31. december 2026, og 8.1 og ældre får ingen.

Filintegritet. WP-CLI kan sammenligne WordPress-kernen og plugins med de checksums, WordPress.org har for den installerede version. Betalte plugins og egne temaer findes ikke på WordPress.org og skal tjekkes på anden vis, fx med find. PHP-filer i uploads-mappen er næsten altid et tegn på kompromittering:

wp core verify-checksums
wp plugin verify-checksums --all

# PHP-filer ændret de seneste 7 dage, uden cache-mapper
find /var/www/webshop -type f -name '*.php' -mtime -7 -not -path '*/cache/*'

# PHP-filer i uploads, hvor der kun bør ligge billeder og dokumenter
find /var/www/webshop/wp-content/uploads -type f -name '*.php'

Backup og gendannelse. En backup er først dokumenteret, når den er gendannet. Gendan til en separat testserver, aldrig oven i produktion, og mål to tal: hvor lang tid gendannelsen tog (RTO), og hvor gammel den nyeste ordre i backuppen er i forhold til tidspunktet for backuppen (RPO). Sæt testkopien op, så den ikke sender mails til kunder eller kører planlagte job. DISABLE_WP_CRON slår WordPress' indbyggede cron fra, og WP_ENVIRONMENT_TYPE markerer installationen som staging. Slå også betalingsmoduler over i testtilstand:

# 1. Kontrollér, at backupfilen er hel, og noter hashen i protokollen
sha256sum webshop-2026-10-20.sql.gz

# 2. Importér på testserveren
gunzip -c webshop-2026-10-20.sql.gz | wp db import -

# 3. Skift domæne, først som prøvekørsel
wp search-replace 'https://webshop.dk' 'https://test.webshop.dk' --skip-columns=guid --dry-run
wp search-replace 'https://webshop.dk' 'https://test.webshop.dk' --skip-columns=guid

# 4. Røgtest: svarer forsiden, og hvor ny er seneste ordre?
curl -sS -o /dev/null -w '%{http_code}\n' https://test.webshop.dk/
wp db query "SELECT MAX(date_created_gmt) FROM wp_wc_orders"

Den sidste forespørgsel forudsætter, at shoppen bruger WooCommerces ordretabeller (HPOS). Restore-protokollen skal indeholde backupens dato og hash, start- og sluttidspunkt, resultatet af røgtesten, og hvem der udførte den.

Logning. Hvor længe logs gemmes, står i logrotate-konfigurationen. daily og rotate 14 betyder to ugers logs, hvilket er for lidt til at afgrænse et angreb, der først opdages efter en måned. Logs med IP-adresser er personoplysninger, så perioden skal kunne begrundes. Loginforsøg pr. IP kan tælles direkte i access-loggen, hvor første felt er klientens IP:

cat /etc/logrotate.d/nginx

grep 'POST /wp-login.php' /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head

Mail-domænet. SPF og DMARC er offentlige DNS-poster, så de kan tjekkes med dig +short TXT _dmarc.webshop.dk. En DMARC-politik på quarantine eller reject beskytter mod falske mails i jeres navn, mens none kun overvåger. Læs mere i vores artikel om falske mails i jeres navn.

Gem output fra alle kontrollerne i dokumentationsmappen. Køres de samme kommandoer igen næste år, kan I vise, at kontrollerne er en rutine.

NIS2-loven, Danmarks lov om cybersikkerhed, trådte i kraft 1. juli 2025. Den stiller krav til virksomheder i en række sektorer, og om I selv er omfattet, afhænger af sektor og størrelse. Styrelsen for Samfundssikkerhed har udgivet vejledninger, der hjælper med at afgøre det.

D-mærket har et NIS2-modul, som kan vælges til i den gratis selvevaluering. Ifølge D-mærket tilfører modulet krav til 7 af de 10 minimumskrav i NIS2, blandt andet hændelseshåndtering, kryptografi, netværkssegmentering, fysisk sikkerhed og test af risikoforanstaltninger. D-mærket har også sammenholdt modulet med myndighedernes vejledning og vurderer, at det generelt er i overensstemmelse med de foranstaltninger, der står som "skal".

To ting er vigtige at forstå:

• D-mærket gør jer ikke NIS2-compliant. D-mærket skriver selv, at det ikke kan give en garanti, og at det alene er myndighederne, der kan vurdere, om en virksomhed lever op til loven.
• Ikke alle D-mærkede virksomheder opfylder NIS2's minimumskrav. Er I omfattet af NIS2, skal I vælge NIS2-modulet til, og så rykker I samtidig op i gruppe III eller IV.

For en webshop, der ikke selv er omfattet, kan NIS2 alligevel blive relevant. NIS2 handler også om sikkerhed i forsyningskæden, så omfattede virksomheder kan stille krav til deres leverandører. Sælger I B2B til fx forsyning, transport eller produktion, kan I blive bedt om at dokumentere jeres sikkerhed, og her er en tilsynsrapport fra D-mærket et konkret svar. De tekniske beviser fra afsnittene ovenfor, TLS-test, adgangsudtræk og restore-protokol, kan som regel genbruges direkte i et leverandørspørgeskema. Læs mere om, hvad NIS2 betyder for jer.

De samme fejl går igen, når virksomheder går i gang med D-mærket eller med sikkerhed generelt:

• At se D-mærket som et it-projekt. Kriterie 1 handler om ledelsens ansvar, og en tegningsberettiget skal underskrive en tro- og loveerklæring. Ledelsen skal være med fra start.
• At svare ja for hurtigt. Et ja i selvevalueringen skal kunne dokumenteres. "Vi tager backup" holder ikke, hvis ingen har prøvet at gendanne fra den.
• At glemme leverandørerne. Platform, hosting og bureau har ofte bredere adgang til shoppen end jeres egne ansatte. De skal med i oversigten og have databehandleraftaler.
• At lade gamle admin-logins ligge. Tidligere bureauer, freelancere og praktikanter med administratoradgang er en klassisk vej ind, og D-mærket nævner selv, at adgange sjældent bliver fjernet igen.
• At vælge forkert gruppe. Sælger I software eller it-ydelser ved siden af shoppen, skal det med i besvarelsen. Ellers passer kriteriesættet ikke, og det opdages ved tilsynet.
• At lade mærket udløbe og glemme logoet. Udløber mærket, skal det fjernes fra footer, checkout, nyhedsbreve og andet markedsføringsmateriale.
• At teste HTTPS på forsiden og glemme resten. Checkout, admin, API-endpoints og gamle subdomæner har ofte deres egen konfiguration. En header i én server-blok gælder ikke automatisk de andre.

Brug listen her, før I trykker på "Anmod om tilsyn". Kan I ikke krydse et punkt af, så luk det først, eller find en kompenserende kontrol, I kan dokumentere.

• Selvevalueringen er udfyldt, og den rigtige virksomhedsgruppe er valgt under "Organisation"
• Kriteriesættet er downloadet, og hvert krav har en ansvarlig person
• Ledelsen har godkendt en kort sikkerhedspolitik og ved, hvad tro- og loveerklæringen forpligter til
• Der er en liste over alle systemer: shopplatform, hosting, domæne, mail, betaling, fragt, regnskab, marketing
• Der er en liste over leverandører med databehandleraftaler, hvor de behandler persondata
• To-faktor er slået til på shop-admin, hosting, domæne, mail og betalingsudbyder, og det er testet fra et privat browservindue
• Brugere er gennemgået, og tidligere ansatte, delte konti og gamle leverandøradgange er fjernet. Udtrækket er gemt med dato
• Platform, moduler og PHP er på understøttede versioner, og der er en fast rutine for opdateringer
• Checksums for kerne og plugins er verificeret, og der ligger ingen PHP-filer i uploads
• Serveren accepterer kun TLS 1.2 og 1.3, certifikatet fornyes automatisk, og http omdirigeres til https
• HSTS og de grundlæggende sikkerhedsheaders er sat og testet på både forside og checkout
• Backup er adskilt fra den kørende shop, og en gendannelse er testet og dokumenteret med dato, hash og varighed
• Det er beskrevet, hvor logs ligger, og hvor længe de gemmes
• SPF og DMARC er sat op for mail-domænet
• Medarbejderne har fået en introduktion til phishing og sikker adfærd
• Der er en beredskabsplan, som beskriver, hvem der gør hvad ved et hackerangreb eller databrud
• Privatlivspolitik og cookiehåndtering på shoppen passer til, hvad I faktisk gør med data
• Hvis I bruger AI eller algoritmer, er det beskrevet hvor og til hvad

Hvad er D-mærket, kort fortalt? En frivillig dansk mærkningsordning for it-sikkerhed og ansvarlig dataanvendelse. Virksomheden dokumenterer, at den lever op til et sæt kriterier, og D-mærkets auditorer fører tilsyn. Mærket gælder et år ad gangen.

Hvad koster D-mærket for en lille webshop? Selvevalueringen er gratis. Tilsynet koster 5.000 kr. uden moms i gruppe I (0-9 medarbejdere) og 15.000 kr. i gruppe II (10-49 medarbejdere). Dertil kommer jeres egen tid og eventuel hjælp udefra.

Er D-mærket et krav? Nej. GDPR er lovpligtig, og NIS2 er det for omfattede virksomheder. D-mærket er frivilligt, men kan bruges som dokumentation over for kunder og samarbejdspartnere.

Kan vi bruge det, vi har lavet til ISO 27001 eller GDPR? Ofte ja. D-mærket har mappet sine kriterier til blandt andet GDPR, ISO/IEC 27001 og NIS2, og dokumentation kan i nogle tilfælde genbruges helt eller delvist.

Gør D-mærket os klar til NIS2? Ikke i sig selv. Er I omfattet af NIS2, skal I vælge NIS2-modulet til, og selv da er det kun myndighederne, der kan vurdere, om I lever op til loven.

Hvem kontrollerer, at vi lever op til kravene? D-mærkets egne auditorer. Tilsynet er primært en gennemgang af dokumentation med stikprøver, og I får en rapport bagefter.

For de fleste webshops er D-mærket ikke et spørgsmål om at få et logo i footeren. Det er en anledning til at få styr på de ting, der alligevel skal være i orden: hvem har adgang, er der to-faktor, bliver shoppen opdateret, virker backuppen, og hvad gør I, hvis det går galt.

Start med den gratis selvevaluering. Den koster kun tid og giver en konkret liste over, hvad der mangler. Ofte er det tekniske hurtigere at lukke end det skriftlige, fordi det handler om få, men vigtige indstillinger i shop, hosting og mail. Gør kontrollerne til kommandoer, I kan køre igen, så næste års tilsyn bliver en opdatering og ikke et nyt projekt.

Vi kan hjælpe med den tekniske del: et sikkerhedstjek af sitet, to-faktor og oprydning i adgange, TLS- og header-konfiguration, backup med testet gendannelse og faste opdateringer af platform, moduler og PHP. Vi kan også hjælpe med at samle dokumentationen fra hosting og platform, så den er klar til tilsynet. Er I i tvivl om NIS2, så læs vores side om NIS2, eller skriv til os.

Kilder

• D-mærket
• Kriterier
• Priser
• Virksomhedsgrupper
• Proces
• NIS 2
• FAQ
• It-sikkerhed
• Om D-mærket
• Lovguiden om NIS2-lovens ikrafttræden
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• RFC 6797: HTTP Strict Transport Security
• hstspreload.org
• OpenSSL: s_client
• OpenSSL: x509
• Qualys SSL Labs: SSL Server Rating Guide
• Certbot: brugervejledning
• nginx: ngx_http_headers_module
• nginx: ngx_http_ssl_module
• MDN: frame-ancestors
• MDN: Content-Security-Policy-Report-Only
• MDN: X-Content-Type-Options
• MDN: Referrer-Policy
• MDN: Permissions-Policy
• WP-CLI: wp user list
• WP-CLI: wp user session
• WP-CLI: wp plugin list
• WP-CLI: wp core verify-checksums
• WP-CLI: wp plugin verify-checksums
• WP-CLI: wp db import
• WP-CLI: wp search-replace
• WordPress: wp-config.php
• PHP: Supported Versions
• PrestaShop: database
• logrotate(8)
• RFC 7489: DMARC