Når produktet håndterer kortdata: PCI DSS og testkravet

Et softwarehus, hvis produkt selv modtager, gemmer eller videresender kortdata, står et andet sted end et softwarehus, der lader betalingsudbyderen klare det hele. Så kan kunderne forvente, at I selv er omfattet af PCI DSS, og at jeres penetrationstest følger standardens krav 11. Svaret på kundens spørgsmål hviler på to ting: om jeres produkt faktisk hører til det miljø, hvor kortdata behandles, og hvad standarden kræver af test i det miljø. Teksten er ikke juridisk rådgivning og ikke en vurdering af overholdelse.

Er I serviceudbyder i standardens forstand?

PCI Security Standards Council, som ejer PCI DSS, beskriver standarden som et grundniveau af tekniske og driftsmæssige krav til beskyttelse af betalingskortdata. Ifølge rådet gælder den for enheder, der gemmer, behandler eller transmitterer kortholderdata, og nævner udtrykkeligt serviceudbydere ved siden af forretninger, indløsere og udstedere. Den omfatter også enheder, der kan påvirke sikkerheden i det miljø, hvor kortdata findes.

For et SaaS-produkt er spørgsmålet derfor ikke, om kunderne tager imod kortbetaling, men om kortdata passerer gennem jeres systemer, eller om jeres systemer kan påvirke dem. Hvordan betalingen er koblet på produktet, er beskrevet for sig. → Betaling og abonnement i produktet

Hvad krav 11 siger om penetrationstest

Krav 11.4 handler om ekstern og intern penetrationstest. Efter krav 11.4.2 og 11.4.3 skal testen gennemføres efter en fastlagt metode, mindst hver tolvte måned og efter væsentlige opgraderinger eller ændringer af infrastruktur eller applikation. Testeren skal være kvalificeret og organisatorisk uafhængig, men behøver ikke være QSA eller ASV.

Krav 11.4.1 beskriver, hvad metoden skal omfatte. Blandt punkterne er test af hele perimeteren om kortdatamiljøet og kritiske systemer, test både indefra og udefra, test af segmentering, test på applikationslaget og opbevaring af testresultater og rettelser i mindst tolv måneder. Krav 11.4.4 kræver, at udnyttelige sårbarheder rettes efter jeres egen risikovurdering, og at testen gentages for at bekræfte rettelserne. → Ændringer, der kræver en ny test

Hold også testen adskilt fra scanningerne i samme krav. Krav 11.3.2 kræver ekstern sårbarhedsscanning mindst hver tredje måned af en godkendt scanningsleverandør (ASV), og 11.3.1 kræver intern scanning med samme rytme. Scanninger og penetrationstest er to forskellige krav med hver sin rytme og hver sin dokumentation. En kunde, der spørger efter PCI-test, kan mene det ene, det andet eller begge, så spørg, før I sender noget. Svarer I med en scanningsrapport, hvor kunden ventede en pentest, eller omvendt, skal I bagefter forklare, hvorfor dokumentet ikke passer til kravet.

Ekstra krav til serviceudbydere

To krav gælder kun serviceudbydere. Bruger I segmentering til at holde kortdatamiljøet adskilt fra andre net, skal segmenteringen efter krav 11.4.6 testes mindst hver sjette måned og efter ændringer i den, hvor kravet for andre enheder i 11.4.5 er mindst hver tolvte måned. Og efter krav 11.4.7 skal serviceudbydere med flere kunder i samme løsning støtte deres kunder i den eksterne penetrationstest, som kunderne selv skal have gennemført efter krav 11.4.3 og 11.4.4.

Det sidste krav betyder, at en kunde, der selv er omfattet af PCI DSS, kan have brug for jeres medvirken til sin egen test. Et nej uden alternativ kan efterlade kunden uden mulighed for at opfylde sit krav. → Kundens egen test i et delt miljø

Hvor grænsen går

Testkravene i PCI DSS gælder kortdatamiljøet og det, der kan påvirke det. Hvor stor en del af jeres produkt der hører med, afhænger af arkitekturen. Er kortdata isoleret i én tjeneste, og er adskillelsen testet, kan resten af produktet ligge uden for. Er kortdata spredt i databaser, logfiler og integrationer, bliver omfanget større.

Det er derfor en fordel at have en tegning af, hvor kortdata kommer ind, hvor de opbevares, og hvor de forlader produktet, før testen planlægges. Tegningen bliver også grundlaget for omfangsafsnittet i rapporten, så kunderne kan se, hvilke dele testen dækkede. → Omfangsafsnittet i rapporten

Hvad kunderne kan bede om

En kunde, der selv er omfattet, kan bede om dokumentation for, at jeres del af kortdatamiljøet er testet efter krav 11. Det kan være en bekræftelse af, at intern og ekstern test er gennemført inden for tolv måneder, at segmenteringen er testet, og at udnyttelige fund er rettet og efterprøvet. Kunden kan også spørge, hvordan I støtter kundens egen eksterne test.

Pentestrapporten er ét stykke dokumentation. Den er ikke en vurdering af, om I overholder PCI DSS som helhed, og den kan ikke bruges som en sådan. Hvordan overholdelse vurderes og dokumenteres, fastlægges efter PCI SSC’s regler. → Kunden henviser til en standard

Et tænkt eksempel

Et softwarehus driver en abonnementsplatform til fitnesscentre. Platformen modtager kortnumre fra medlemmernes tilmelding og sender dem videre til indløseren. En kæde af centre beder om dokumentation for PCI-test.

Softwarehuset tegner kortdatas vej og konstaterer, at tilmeldingstjenesten og en kø mellem tjenesterne behandler kortdata. Testen planlægges, så den dækker tjenesterne, adskillelsen til resten af platformen og applikationslaget. Kunden får en kundeversion med omfang, dato og status på fund og en beskrivelse af, hvordan softwarehuset støtter kædens egen eksterne test. Tegningen af kortdatas vej gemmes, så den kan genbruges ved næste test og opdateres, når en ny betalingsform kommer til platformen.

Det skal I lade være med

Antage, at I er uden for, fordi kunderne tager imod betalingen · det afgørende er, om kortdata passerer jeres systemer.
Sende rapporten som bevis for overholdelse · den dokumenterer testen, ikke hele standarden.
Glemme det halvårlige krav til segmentering · det gælder serviceudbydere, der bruger segmentering.
Afvise kundens egen eksterne test · krav 11.4.7 forudsætter, at I støtter den.
Smide testresultater ud for tidligt · metoden skal omfatte opbevaring i mindst tolv måneder.

Hvad kan og ikke kan konkluderes

En test efter krav 11 kan vise, at den del af produktet, der behandler kortdata, er afprøvet efter standardens rytme og med den dækning, metoden beskriver. Den kan ikke vise, at hele produktet er sikkert, at I overholder de øvrige krav i PCI DSS, eller at kunden opfylder sine krav. Om jeres produkt er omfattet, og i hvilket omfang, er en vurdering for sig.

Tjekliste, når produktet håndterer kortdata

☐ Ved I, hvor kortdata kommer ind, opbevares og forlader produktet?
☐ Er intern og ekstern test gennemført inden for tolv måneder og efter væsentlige ændringer?
☐ Er segmenteringen testet hver sjette måned, hvis I bruger den?
☐ Er udnyttelige fund rettet og efterprøvet?
☐ Har I en beskrivelse af, hvordan I støtter kundernes egen eksterne test?
☐ Opbevares testresultater og rettelser i mindst tolv måneder?

Kilder

PCI Security Standards Council: PCI DSS: standarden som grundniveau for beskyttelse af betalingskortdata; gælder enheder, der gemmer, behandler eller transmitterer kortholderdata, herunder serviceudbydere.
PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.1 (metode, segmentering, applikationslag, opbevaring i mindst tolv måneder), 11.4.2 og 11.4.3 (mindst hver tolvte måned og efter væsentlige ændringer, uafhængig tester, ikke krav om QSA eller ASV), 11.4.4 (rettelse og gentaget test), 11.4.5 og 11.4.6 (segmentering hver tolvte og for serviceudbydere hver sjette måned) og 11.4.7 (støtte til kundernes eksterne test); krav 11.3.1 og 11.3.2 om intern og ekstern scanning mindst hver tredje måned, den eksterne af en ASV.

Senest gennemgået: oktober 2026.