PCI DSS.
Apibrėžkite mokėjimų duomenis ir priklausomybes, išsiaiškinkite atsakomybę veikloje bei su kompetentinga šalimi suderinkite tinkamą įrodymą.
- PCI DSS v4.0.1 · PCI SSC
- Autorius: Jonathan Bezdek
- Aktualu: 2026-10-22
- Skaitymo trukmė: 7 min.
Trumpas atsakymas.
PCI DSS yra mokėjimo kortelių duomenų apsaugos sektoriaus standartas. Jis taikomas prekybininkams, paslaugų teikėjams ir sistemoms, kurios tvarko tokius duomenis arba veikia jų saugumą. Dabartinė versija – PCI DSS v4.0.1. Mokėjimų aplinka ir vaidmuo lemia aprėptį; įrodymo būdas derinamas su aptarnaujančiu banku arba mokėjimo prekės ženklu, pavyzdžiui, SAQ arba ROC.
PCI DSS 4.0 ir dabartinė versija.
PCI DSS sujungia techninius ir veiklos saugumo reikalavimus mokėjimų duomenims. PCI Security Standards Council, trumpai PCI SSC, kuria standartą ir pagalbines priemones. Tačiau kaip konkrečioje mokėjimų programoje įrodoma atitiktis, nustato kompetentingos priimančios šalys, paprastai aptarnaujantys bankai ir mokėjimo prekės ženklai; PCI SSC DUK 1473 paaiškina šį vaidmenų skirtumą.
PCI DSS v4.0.1 yra oficialioje Document Library nurodyta versija. Pagal PCI SSC publikaciją apie peržiūrą v4.0 panaikinta 2024 m. gruodžio 31 d. Naujiems v4 reikalavimams jau numatyta 2025 m. kovo 31 d. liko nepakeista. Šio puslapio parengimo metu ši data jau praėjusi; tai nėra būsimas įvedimo terminas.
Sėkmingai pateiktas įrodymas nepakeičia nuolatinės apsaugos. Praktiškai organizuojant darbą mokėjimo kelių, taikomųjų programų ir teikėjų pokyčiai turėtų inicijuoti sutartos aprėpties peržiūrą. Nauja atsiskaitymo integracija gali sukurti kitokias priklausomybes nei anksčiau įvertintas sprendimas, nors ta pati įmonė ir toliau priima mokėjimus.
Kam taikomas PCI DSS.
Pagal PCI SSC apžvalgą PCI DSS skirtas ne tik organizacijoms, kurios saugo, tvarko ar perduoda kortelių duomenis. Reikia nagrinėti ir galimą poveikį kortelių turėtojų duomenų aplinkos, angliškai Cardholder Data Environment arba CDE, saugumui. Todėl prekybininkai ir teikėjai pirmiausia turėtų aprašyti savo konkretų vaidmenį ir faktiškai teikiamas paslaugas.
Mokėjimų tvarkymo perdavimas išorei automatiškai neatleidžia nuo pareigų. PCI SSC DUK 1092 atskiria galimai mažesnę tiesioginių reikalavimų aprėptį nuo išliekančios atsakomybės už tinkamus teikėjus, sutartas atsakomybes ir reikalaujamą įrodymą. Net naudojant išorinį atsiskaitymo puslapį su kompetentinga šalimi išsiaiškinkite, kokias sąlygas turi atitikti pasirinkta techninė integracija.
Ribas pagrindžia veiksmingos priemonės, o ne vien pavadinimas architektūros diagramoje. PCI SSC DUK 1115 aiškina, kad reikia tikrinti prijungtas sistemas ir tikrąjį segmentavimo veiksmingumą. Per anksti neįtraukus administravimo prieigų, pagalbinių paslaugų ar sąsajų galima aprašyti neišsamią audito aprėptį.
PCI DSS reikalavimų organizavimas veikloje.
Įgyvendinimas susieja mokėjimų aplinkos apsaugą su atsekamais veiklos procesais. Toliau šešios darbo sritys yra redakcinis planavimo orientyras, o ne dvylikos oficialių reikalavimų ar atskirų patikros punktų atkūrimas; konkretus jų taikymas tikrinamas pagal patvirtintą aprėptį.
Suprantamai aprašykite mokėjimų srautus ir aprėptį.
Praktiškai atsekite, kur atsiranda mokėjimų informacija, kokie komponentai dalyvauja ir kokie žmonės ar teikėjai gali ją paveikti. Patvirtintą ribą užfiksuokite kartu su jos prielaidomis. Suprantamas aprašymas padeda kūrimo, veiklos specialistams ir priimančiai šaliai kalbėti apie tą patį mokėjimo kelią.
Saugiai valdykite sistemas ir pakeitimus.
Dalyvaujančioms taikomosioms programoms ir infrastruktūros komponentams priskirkite aiškius atsakinguosius. Pakeitimus susiekite su klausimu, ar nauji ryšiai, funkcijos ar priklausomybės keičia patvirtintą aprėptį. Kasdienėje veikloje atsekama pakeitimų istorija naudingesnė nei tik audito datai surinkta momentinė nuotrauka.
Ribokite duomenų naudojimą ir perdavimą.
Pradėkite nuo praktinio klausimo, kokių mokėjimų duomenų pasirinktam procesui iš tikrųjų reikia ir kur gali atsirasti kopijos. Atsižvelkite į eksportus, žurnalus ir pagalbinius procesus. Išsamus saugumo planavimas turi atitikti duomenų tipus ir naudojimo tikslą; bendra konfidencialumo žyma šių sprendimų dar nepaaiškina.
Atsekamai organizuokite prieigas.
Susiekite dalykines atsakomybes su faktiškai suteiktomis techninėmis galimybėmis. Be darbuotojų, nagrinėkite paslaugų paskyras, administravimo prieigas ir tiekėjus. Organizuojant darbą rekomenduojama aiškiai atsakyti, kas patvirtina prieigą, kas tvarko pakeitimus ir pagal ką matoma, kad prieiga panaikinta laiku.
Tikrinkite veiklą ir tvarkykite išvadas.
Tinkamus įrašus ir patikras planuokite kartu su mokėjimų aplinkos atsakingaisiais. Vienas skenavimas ar skverbimosi testas aprašo tik savo objektą. Nustačius trūkumus užfiksuokite, koks pakeitimas iš jų kyla ir kaip bus tikrinamas jo poveikis, užuot prilyginę bandymo rezultatą visam PCI DSS įrodymui.
Įtraukite teikėjus ir incidentus.
Nustatykite veiklos kontaktinius asmenis ir veiksmus pastebėjus anomalijas. Perduotose paslaugose savo užduotys turi likti suprantamos šalia teikėjo įsipareigojimų. PCI SSC DUK 1576 paaiškina, kad teikėjo įrodymas turi apimti naudojamas paslaugas; bet koks įmonės dokumentas tam automatiškai netinka.
PCI DSS įgyvendinimas kaip nuolatinė užduotis.
Suderinkite vaidmenį ir įrodymo kelią.
Pradėkite su aptarnaujančiu banku ar mokėjimo prekės ženklu išsiaiškindami savo vaidmenį, laukiamą įrodymą ir atsakingą kontaktinį asmenį prieš rinkdamiesi formą.
Užfiksuokite vieną mokėjimo kelią.
Aprašykite dalyvaujančius duomenis, taikomąsias programas, sistemas ir teikėjus nuo mokėjimo pradžios iki liekančių veiklos įrašų.
Patvirtinkite aprėptį.
Patikrinkite svarbius ryšius ir saugumą veikiančius komponentus bei paveskite specialistams įvertinti ribas, įskaitant galimą segmentavimą.
Įtvirtinkite užduotis veikloje.
Priskirkite apsaugos priemones ir bendras atsakomybes konkretiems asmenims bei susiekite jų įgyvendinimą su tinkamais įrašais.
Nuosekliai parenkite įrodymus.
Patikrinkite, ar reikalaujami dokumentai aprašo tą pačią paslaugą, vaidmenį ir aprėptį bei ar atviri sprendimai sutvarkyti atsekamai.
Stebėkite pokyčius ir tolesnes patikras.
Sutarkite reikiamus įrodymų teikimo intervalus ir po pokyčių patikrinkite, ar aprėptis, teikėjų įrodymai ir veiklos atsakomybės vis dar tinka.
PCI sertifikavimas ir tikroji įrodymo forma.
Pripažįstamam PCI DSS įrodymui naudojami tam skirti oficialūs dokumentai. SAQ dokumentuoja leidžiamą savęs vertinimą, ROC – atitinkamo audito kelio rezultatus, o AOC – susijusį patvirtinimą. Pagal PCI SSC DUK 1220 bet kokie dokumentai, pavadinti atitikties sertifikatais, nepakeičia oficialių šablonų.
Priimanti šalis nustato reikalaujamą kelią; atitinkamame audite gali dalyvauti Qualified Security Assessor, trumpai QSA. Pagal PCI SSC DUK 1473 aprėptis ir taikymas turi būti įvertinti teisingai. Todėl SAQ pavadinimo pasirinkimas dar nepatvirtina, kad tenkinami jo tinkamumo kriterijai ar įgyvendinti visi aktualūs reikalavimai.
Net tinkamą šabloną reikia naudoti dabartinės versijos. PCI SSC pakeitė SAQ A taisykles nuo 2025 m. kovo 31 d. ir aiškiai nurodė, kad pašalinti atskiri klausimyno patikros punktai nepanaikina pagrindinių PCI DSS reikalavimų. Suderinkite įrodymų datas ir tolesnes pareigas konkrečiam atvejui, užuot rėmęsi bendra sertifikato galiojimo trukme.
Ryšys su kitomis sistemomis.
ISO 27001 skirtas informacijos saugumo valdymui apibrėžtoje taikymo srityje; PCI DSS įrodymas yra atskiras sprendimas mokėjimų aplinkai. CIS Controls padeda bendrai nustatyti saugumo darbo prioritetus, tačiau nenustato PCI patvirtinimo kelio. BDAR skirtas asmens duomenų tvarkymui ir turi būti tikrinamas nepriklausomai nuo mokėjimų duomenų įrodymo.
„Secani“ sistemoje.
„Secani“ turi savo redakcinį įmonių katalogą pagal PCI DSS v4.0.1. Profilis, be kita ko, fiksuoja CDE aprėptį, prekybininko ar teikėjo vaidmenį ir sutartą SAQ arba ROC kelią. Šie darbo duomenys padeda struktūruotai dirbti; jie nepakeičia nei oficialių audito dokumentų, nei tinkamumo patvirtinimo, nei kompetentingos šalies sprendimo.
Pradėkite nuo konkretaus mokėjimo kelio.
Pasirinkite iš tikrųjų naudojamą mokėjimo kelią ir įvardykite jo veiklos bei techninę atsakomybę. Užfiksuokite, kokias paslaugas teikiate patys ir kurias perima teikėjas. Tada suderinkite laukiamą įrodymą su kompetentinga šalimi prieš planuodami darbo sąnaudas pagal tariamai tinkamą klausimyną.
Šaltiniai.
- PCI SSC – PCI DSS apžvalga ir tikslinė grupė
- PCI SSC – oficiali Document Library
- PCI SSC – PCI DSS v4.0.1 paskelbimas
- PCI SSC DUK 1473 – kompetentingos šalys ir įrodymo kelias
- PCI SSC DUK 1092 – mokėjimų tvarkymo perdavimas išorei
- PCI SSC DUK 1576 – teikėjų įrodymai
- PCI SSC DUK 1220 – oficialūs dokumentai vietoj atitikties sertifikatų
- PCI SSC DUK 1115 – prijungtos sistemos ir segmentavimas
- PCI SSC – SAQ A pakeitimai nuo 2025 m. kovo 31 d.
- PCI SSC – SAQ biuletenis, 2024 m. spalio 15 d.
Dažniausi klausimai.
Ne, automatiškai neatleidžiama. Perdavimas gali pakeisti tiesioginę aprėptį; atsakomybę už tinkamus teikėjus, aiškias atsakomybes ir reikalaujamą įrodymą reikia vertinti atskirai.
Ne vien pagal pageidaujamas darbo sąnaudas. Turi būti tenkinami tinkamumo kriterijai, o reikalaujamą įrodymo kelią reikia suderinti su priimančia šalimi.
Bet kokie atitikties sertifikatai nėra pripažįstamas oficialių dokumentų pakaitalas. Lemiamą reikšmę turi sutartas audito kelias ir atitinkamos oficialios ataskaitos ar patvirtinimai.
Ne. ISMS sertifikatas taikomas jo nurodytai vadybos sistemos aprėpčiai; mokėjimų aplinkos reikalavimus ir įrodymo kelią reikia išsiaiškinti atskirai.
Apibrėžkite mokėjimo kelią.
Aptarkite, kaip galite tvarkyti aprėptį, užduotis ir įrodymus „Secani“ sistemoje.
Šiame puslapyje PCI DSS aiškinamas savais žodžiais; jis nepakeičia oficialių PCI SSC dokumentų ar profesinio vertinimo. Atitinkamos mokėjimų programos reikalavimus ir kompetentingos šalies sprendimus reikia vykdyti atskirai.