Kortdata är ett känt ansvar för företag. Den globala genomsnittliga kostnaden för ett dataintrång var 4,44 miljoner USD år 2025. Varje server, loggfil och säkerhetskopia som lagrar ett primärt kontonummer (PAN) blir en del av vad Payment Card Industry Data Security Standard (PCI DSS) kallar kortinnehavarens datamiljö (CDE), och varje aspekt av den miljön är föremål för efterlevnadskrav.
Tokenisering ändrar vad som faktiskt finns i den miljön genom att ersätta PAN:et med ett ersättningsvärde som inte har något eget värde som kan utnyttjas. Om du implementerar tokenisering på rätt sätt kan du minska dina efterlevnadsskyldigheter till en bråkdel av vad de annars skulle vara. Nedan går vi igenom hur tokenisering för PCI-efterlevnad fungerar, gränserna för dess skydd, var andra säkerhetskontroller behöver implementeras och vad PCI Security Standards Council kräver från ett kompatibelt tokensystem.
Viktiga slutsatser
Tokenisering kan ta bort hela system från efterlevnadsomfattningen för Payment Card Industry Data Security Standard (PCI DSS), men endast när genereringen av tokens, valvets säkerhet och detokeniseringskontrollerna uppfyller specifika tekniska standarder.
Kryptering och tokenisering skyddar kortdata på olika sätt enligt PCI DSS, och många kompatibla arkitekturer förlitar sig på båda snarare än att välja den ena framför den andra.
Att kvalificera sig för det enklaste frågeformuläret för självutvärdering av PCI-efterlevnad beror på hur kortdata flödar genom en integration snarare än bara om tokenisering finns någonstans i systemet.
Vad är PCI DSS-efterlevnad?
PCI DSS-efterlevnad innebär att man uppfyller säkerhetskraven som ställts upp av PCI Security Standards Council för alla företag som lagrar, behandlar eller överför kortinnehavardata. Standarden omfattar 12 grundläggande krav som sträcker sig över nätverkssäkerhet, åtkomstkontroll, kryptering och övervakning. Den gäller oavsett om du kör en enda betalningsterminal eller behandlar miljontals transaktioner per år.
Vad PCI DSS säger om tokenisering
PCI DSS-riktlinjer för tokenisering anger att om en token inte har något värde utanför det system som skapade den, och om det systemet är ordentligt isolerat och säkrat, behöver de miljöer där tokenen finns inte utvärderas som om de innehåller riktig kortdata. Varje PAN finns fortfarande någonstans, oftast i ett krypterat valv, men tokenisering innebär att det endast finns på den enda platsen, inte utspritt över olika system.
Så minskar tokenisering omfattningen av PCI-efterlevnad
Tokenisering minskar omfattningen av PCI-efterlevnad genom att begränsa antalet platser där läsbar kortdata lagras eller överförs. Detta gäller så länge tokens inte kan återställas till det ursprungliga PAN:et av någon utanför tokeniseringssystemet. Om någon kan beräkna PAN:et från tokenen med känd logik minskar inte tokenen omfattningen.
PCI DSS-riktlinjer och krav för tokenisering för minskad omfattning
PCI Security Standards Councils riktlinjer inkluderar specifika tekniska förväntningar för alla system som hävdar att de minskar omfattningen. Dessa delas in i två huvudkategorier: generering av tokens och tokenvalv.
Tokengenerering
Generering av tokens måste motstå baklängeskonstruktion. Formatbevarande tokens som härmar längden och strukturen på ett visst kortnummer är säkra så länge själva bytet är oförutsägbart snarare än härlett genom en reversibel formel.
Tokens som skapas genom en envägsprocess, så att det inte finns någon omvänd matematisk funktion, kvalificerar mer tillförlitligt för en minskad omfattning än tokens som genereras genom kryptering med en återställningsbar nyckel. Krypterade värden betraktas fortfarande som kortinnehavardata enligt definitionerna i PCI DSS, även när de är formaterade för att se ut som tokens. Hur tokens genereras avgör hur en granskare klassificerar ditt system. PCI DSS-riktlinjerna tar också upp motståndskraft mot brute-force-attacker. Om tokeniseringsalgoritmen kan gissas eller reverseras genom upprepade försök kvalificerar tokenen inte för en minskad omfattning, oavsett hur den genererades.
Tokenvalv
Systemet för att lagra tokens kallas för ett valv. Tokenvalvet måste ligga i en segmenterad nätverkszon, tillämpa strikt rollbaserad åtkomstkontroll på data som mappar tokens tillbaka till det ursprungliga PAN:et och logga varje detokeniseringshändelse i tillräcklig detalj för att stödja en rättsteknisk granskning. PCI DSS-granskare håller sig generellt till standarden att detokenisering ska vara sällsynt, avsiktlig och reviderbar. Riktlinjerna kräver också att tokeniseringsleverantören, oavsett om det är ett internt team eller en tredje part, genomgår sin egen PCI DSS-utvärdering. Ett komprometterat valv motverkar syftet med tokenisering.
Dokumentation måste bevisa påståendet om minskad omfattning för granskarna och bör inkludera ett dataflödesdiagram som exakt visar var PAN finns i klartext (d.v.s. läsbar data som inte är krypterad), var tokenisering sker och var tokens tar över i dina system. Diagrammet måste uppdateras varje gång ett nytt system går in i betalningssökvägen. Om inte, slutar påståendet om minskad omfattning att stämma överens med verkligheten även om inget annat har ändrats.
Hur tokenisering jämförs med kryptering enligt PCI DSS
Både tokenisering och kryptering skyddar samma underliggande data, men PCI DSS behandlar dem väldigt annorlunda när det gäller omfattning. Ett krypterat PAN stannar generellt inom omfattningen om inte det lagrande systemet saknar tillgång till de dekrypteringsnycklar som behövs för att läsa chiffertexten (det krypterade formatet). Det system som innehåller chiffertexten måste uppfylla samma krav på åtkomstkontroll, aktivitetsloggning och sårbarhetshantering som ett system som lagrar PAN:et i klartext, även om den praktiska risken är lägre.
Med tokenisering finns det ingen nyckel att skydda. När en token genereras genom en korrekt implementerad envägsprocess kan den inte reverseras matematiskt, vilket innebär att systemen som innehåller den existerar utanför CDE.
I praktiken använder många PCI-kompatibla arkitekturer både kryptering och tokenisering, eftersom de båda tillför olika skyddsåtgärder. Kryptering skyddar PAN:et inuti valvet för auktorisering och avräkning, medan tokenisering skyddar PAN:et överallt annars, till exempel i de system som behöver referera till en transaktion, utföra en återbetalning eller visa en kund de sista fyra siffrorna, utan att någonsin behöva det faktiska numret. I slutändan skyddar kryptering användbar data, och tokenisering tar bort den från ett system helt och hållet.
Vem ansvarar för att upprätthålla tokeniseringsefterlevnad efter implementering?
PCI DSS-efterlevnad kräver löpande validering och tokenisering lägger till sitt eget underhåll ovanpå standardens vanliga korrigeringar (d.v.s. att tillämpa säkerhetsuppdateringar) och övervakningscykel. Om du använder en tredjepartsleverantör av tokenisering är du fortfarande ansvarig för att bekräfta att leverantören upprätthåller sin egen PCI DSS-validering och för att granska deras Intyg om efterlevnad varje år. En utgången certifiering på leverantörens sida äventyrar ditt eget påstående om minskad omfattning, även om inget ändrats på din sida.
Internt måste någon ansvara för dataflödesdiagrammet och uppdatera det varje gång ett nytt system läggs till i betalningssökvägen. En minskad omfattning kan tyst urholkas när exempelvis ett nytt analysverktyg ansluts, eller ett supportteam exporterar transaktionsdata till ett kalkylblad för felsökning och hittar ett PAN i klartext som ingen redovisade vid den senaste utvärderingen. Även valvets åtkomstloggar måste granskas regelbundet för att fånga detokeniseringsbegäranden som inte matchar förväntade affärsprocesser.
På många medelstora företag är detta ansvaret för den som hanterar företagets betalinfrastruktur (ofta någon inom ekonomi eller teknik), som arbetar med en kvalificerad säkerhetsgranskare (QSA) under den årliga utvärderingscykeln. Mindre företag som använder en betalningsleverantör som hanterar tokenisering från början till slut har det lättare, men de måste fortfarande bekräfta att de inte har återinfört PAN i sina egna system genom exporter, skärmdumpar eller kundtjänstarbetsflöden som föll utanför den ursprungliga minskade omfattningen.
Räcker tokenisering för att garantera PCI DSS-efterlevnad på egen hand?
Tokenisering minskar omfattningen, men det eliminerar inte efterlevnadsskyldigheter för de system som förblir inom omfattningen. Valvet behöver fortfarande fullständig efterlevnad: genereringslogiken, data för token-till-PAN-mappning och detokeniseringskontroller måste alla uppfylla kompletta PCI DSS-standarder.
Företagets beröringspunkter innan tokenisering måste också förbli inom omfattningen. Varje system som hanterar ett PAN innan det blir tokeniserat, till exempel en kassasida eller ett POS-system, behöver kryptering under överföring, nätverkssegmentering och sårbarhetsgenomsökning.
Kvalificeringsklyftan för frågeformulär för självutvärdering (SAQ)
Många företag antar att en tokeniseringslösning kvalificerar dem att använda frågeformulär för självutvärdering A (SAQ A), det enklaste frågeformuläret för självutvärdering. Men det gäller endast om tokeniseringssystemet hindrar företaget från att någonsin hantera, överföra eller lagra PAN, vanligtvis via en betalningssida som de är värd för eller en inbäddad komponent där kortdata går direkt från kundens webbläsare till betalningsleverantören. Ett tokeniseringskoncept där rå kortdata fortfarande passerar genom företagets egen server, även kortvarigt, innan den tokeniseras, håller den servern inom en bredare omfattning, oavsett hur stark tokeniseringen är från och med den punkten framåt.
Så kan Stripe Payments hjälpa till
Stripe Payments erbjuder en enhetlig, global betalningslösning som hjälper alla företag – från växande startupföretag till globala företag – att ta emot betalningar online, fysiskt och runt om i världen.
Det här kan Stripe Payments hjälpa till med:
Optimera din kassaupplevelse: Skapa en smidig kundupplevelse och spara teknikertid med förbyggda betalningsgränssnitt, tillgång till fler än 125 betalningsmetoder och Link, en plånbok byggd av Stripe.
Expandera till nya marknader snabbare: Nå kunder över hela världen och minska komplexiteten och kostnaderna för hantering av flera valutor med gränsöverskridande betalningsalternativ, tillgängliga i 195 länder och för över 135 valutor.
Göra betalningar både fysiskt och online till en enhetlig upplevelse: Bygg en enhetlig köpupplevelse i digitala och fysiska kanaler för att personanpassa interaktioner, belöna lojalitet och öka intäkterna.
Förbättrad betalningsprestanda: Öka intäkterna med en rad anpassningsbara, lättkonfigurerade betalningsverktyg, inklusive kodfritt skydd mot bedrägeri och avancerade funktioner som förbättrar auktoriseringstiderna.
Snabbare utveckling med en flexibel och pålitlig plattform för tillväxt: Bygg vidare på en plattform som är utformad för att skala upp med dig, med historisk upptid på 99,999 % och branschledande tillförlitlighet.
Läs mer om hur Stripe Payments kan driva dina online- och fysiska betalningar, eller börja i dag.
Innehållet i den här artikeln är endast avsett för allmän information och utbildningsändamål och ska inte tolkas som juridisk eller skatterelaterad rådgivning. Stripe garanterar inte att informationen i artikeln är korrekt, fullständig, adekvat eller aktuell. Du bör söka råd från en kompetent advokat eller revisor som är licensierad att praktisera i din jurisdiktion för råd om din specifika situation.