PCI DSS: cała praca, po kolei

• zdecyduj i udokumentujwybory, polityki i zapisy, które podpisuje osoba z uprawnieniami
• zbuduj i skonfigurujsystemy, ustawienia i procedury, które urealniają wybór
• udowodnij i utrzymujsprawdzenia, logi i zapisy, które pokazują, że to działa

Dowiedz się, czego wymaga acquirer, znajdź każde miejsce, do którego trafiają dane kart, i wyprowadź z zakresu to, co się da.

1. 1.1

   zapytaj acquirera, co masz przedstawić

   Zapytaj acquirera lub operatora płatności, jaki formularz masz złożyć, dla których kanałów kartowych, jak często, kto podpisuje i czy potrzebny jest oceniający. Weź odpowiedź na piśmie, bo decydują o tym organizacje płatnicze i acquirer, a nie rada.

   • właściciel zakupy
   • zdecyduj i udokumentuj

   co powstaje

   pisemne stwierdzenie, jaką walidację jesteś winien

   dowód, który zostaje

   odpowiedź acquirera, z datą i nadawcą

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

2. 1.2

   zmapuj, gdzie trafiają dane kart

   Wypisz każde miejsce, w którym dane kart są przechowywane, przetwarzane lub wysyłane, w tym stronę, terminale, nagrania rozmów, papier, logi i dostawców, którzy ich dotykają. Dodaj systemy łączące się z tymi miejscami, bo i one są w zakresie.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   mapa danych kart: kanały, systemy, lokalizacje i dostawcy

   dowód, który zostaje

   mapa, z właścicielem i datą przy każdej pozycji

   zabezpieczenie: asset-inventory

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

3. 1.3

   zdecyduj, co wyprowadzić z zakresu

   Zdecyduj, jakich danych kart możesz przestać przechowywać, czy odesłać klientów na stronę płatności prowadzoną przez dostawcę i które systemy oddzielić od reszty sieci. Każdy usunięty system to zestaw wymagań, których już nie musisz spełniać.

   • właściciel zarząd
   • zdecyduj i udokumentuj

   co powstaje

   decyzja o zakresie, która wymienia, co zostaje, a co wychodzi

   dowód, który zostaje

   decyzja zatwierdzona przez zarząd i poprawiona mapa

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

Ustal, jaki formularz lub raport wypełnisz, i daj aktualny standard osobom, które wykonują pracę.

1. 2.1

   potwierdź formularz z acquirerem

   Sprawdź z acquirerem, który kwestionariusz pasuje do sposobu przyjmowania kart po decyzji o zakresie, albo czy wymagany jest raport oceniającego. Rada radzi pytać acquirera lub organizacje płatnicze, który formularz dotyczy Ciebie.

   • właściciel prawnik lub IOD
   • zdecyduj i udokumentuj

   co powstaje

   nazwany formularz lub rodzaj raportu i osoba, która go wypełnia

   dowód, który zostaje

   potwierdzenie acquirera

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

2. 2.2

   zdobądź aktualne dokumenty

   Pobierz z biblioteki dokumentów rady aktualny standard, formularz i jego instrukcję i sprawdź, czy nie opublikowano nowszej wersji. Ten plan czytał tylko publiczne strony rady, więc każde wymaganie bierz z tych dokumentów.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   aktualny standard i formularz w rękach osób, które wykonują pracę

   dowód, który zostaje

   numery wersji i data pobrania

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

3. 2.3

   zdecyduj, czy pomoże oceniający

   Zdecyduj, czy zaangażować Qualified Security Assessor do testów, doradztwa, czy wcale, o ile acquirer go nie wymaga. Formularze odnotowują, co zrobił oceniający, więc rola musi odpowiadać temu, co faktycznie wykonał.

   • właściciel zarząd
   • zdecyduj i udokumentuj

   co powstaje

   decyzja o roli oceniającego, jeśli jest

   dowód, który zostaje

   decyzja i, gdy jest, warunki zlecenia

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

Zamknij luki w dwunastu wymaganiach dla wszystkiego, co zostało w zakresie.

1. 3.1

   ustaw zabezpieczenia sieci i bezpieczne konfiguracje

   Zdecyduj, co może się z czym łączyć, i egzekwuj to zabezpieczeniami sieci, potem skonfiguruj bezpiecznie każdy system w zakresie i usuń ustawienia domyślne producenta. To dwa pierwsze wymagania.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   reguły sieciowe i utwardzone konfiguracje dla zakresu

   dowód, który zostaje

   zestawy reguł, standardy konfiguracji i zapisy przeglądów

   zabezpieczenie: endpoint-management

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

2. 3.2

   chroń dane kart przechowywane i przesyłane

   Trzymaj jak najmniej danych kart, chroń to, co zostaje, i szyfruj je, gdy przechodzą przez sieci otwarte, kluczami, które mają właścicieli i cykl życia. Dane karty dotyczące osoby są danymi osobowymi, więc obok obowiązuje obowiązek RODO stosowania odpowiednich środków bezpieczeństwa.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   reguła retencji danych i szyfrowanie danych kart przechowywanych i wysyłanych

   dowód, który zostaje

   reguła retencji, ustawienia szyfrowania i lista właścicieli kluczy

   zabezpieczenie: encryption-keys

   podstawa RODO art. 32(1)

3. 3.3

   trzymaj w ryzach złośliwe oprogramowanie i podatności

   Uruchom ochronę przed złośliwym oprogramowaniem na systemach w zakresie i instaluj poprawki w rytmie, który umiesz pokazać. Skanuj regularnie, bo strony rady wymieniają skany podatności zewnętrznych wśród dokumentów, o które może prosić acquirer.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   ochrona przed złośliwym oprogramowaniem, rytm poprawek i raporty ze skanów

   dowód, który zostaje

   raporty ze skanów, zapisy poprawek i lista wyjątków

   strona pracyzabezpieczenie: vulnerability-management

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

4. 3.4

   zabezpiecz oprogramowanie, które tworzysz lub zlecasz

   Jeśli piszesz oprogramowanie, albo ktoś pisze je dla Ciebie, i dotyka ono danych kart, ustal zasady jego tworzenia, przeglądu i zmian. Formularz rady mówi, że wymagania dotyczące bezpiecznego kodowania dotyczą tylko oprogramowania tworzonego na zamówienie lub własnego.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   zasady bezpiecznego wytwarzania oprogramowania w zakresie

   dowód, który zostaje

   zasady, zapisy przeglądów i rejestr zmian

   zabezpieczenie: secure-development

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

5. 3.5

   ogranicz dostęp do tego, czego wymaga praca

   Daj każdej osobie własne konto i tylko ten dostęp do danych kart i systemów w zakresie, którego wymaga praca, z silnym uwierzytelnianiem, i kontroluj fizyczny dostęp do miejsc, gdzie leżą dane kart. To wymagania od 7 do 9.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   dostęp oparty na rolach, indywidualne konta, silne uwierzytelnianie i reguły dostępu fizycznego

   dowód, który zostaje

   listy dostępu, ustawienia uwierzytelniania i zapisy odwiedzin i drzwi

   strona pracyzabezpieczenie: privileged-access

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

6. 3.6

   loguj i testuj

   Loguj dostęp do systemów w zakresie i do danych kart, przeglądaj logi i testuj bezpieczeństwo systemów i sieci według harmonogramu. To wymagania 10 i 11.

   • właściciel szef IT
   • zbuduj i skonfiguruj

   co powstaje

   logowanie obejmujące zakres, rutyna przeglądu i harmonogram testów

   dowód, który zostaje

   próbki logów, zapisy przeglądów i raporty z testów

   zabezpieczenie: logging-monitoring

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

7. 3.7

   napisz politykę, przeszkol ludzi i kontroluj dostawców

   Napisz politykę bezpieczeństwa i wskaż właściciela każdego wymagania, przeszkol osoby w zakresie i zapisz, jak postępujesz przy incydencie. Wypisz każdego dostawcę, który dla Ciebie przechowuje, przetwarza lub przesyła dane kart albo może wpłynąć na Twoje środowisko, i wpisz warunki dla każdego do umowy. Formularz rady mówi, że wymaganie o dostawcach dotyczy wszystkich z tej listy.

   • właściciel zarząd
   • zbuduj i skonfiguruj

   co powstaje

   podpisana polityka, zapis szkolenia, procedura incydentu i lista dostawców z warunkami umownymi

   dowód, który zostaje

   polityka, lista obecności, procedura i podpisane warunki

   strona pracyzabezpieczenie: supplier-management

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

Wypełnij formularz na podstawie dowodów, daj go do podpisu członkowi kierownictwa i wyślij temu, kto prosił.

1. 4.1

   najpierw sprawdź siebie względem formularza

   Przejdź przez formularz z osobami, które prowadzą systemy, zaznacz, co jest wdrożone, a co nie, i usuń luki przed dniem podpisu. Na każdą pozycję odpowiadaj dowodem, który da się otworzyć.

   • właściciel szef IT
   • udowodnij i utrzymuj

   co powstaje

   wstępne sprawdzenie formularza z ustaleniami i właścicielami

   dowód, który zostaje

   wstępne sprawdzenie, z datą i odnośnikiem do dowodu przy każdej odpowiedzi

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

2. 4.2

   wypełnij formularz i opis zakresu

   Wypełnij każdą część, w tym kanały płatności, opis środowiska i dostawców. Zaznacz pozycję jako niedotyczącą dopiero po potwierdzeniu, że nie dotyczy, a jako nietestowaną tylko wtedy, gdy wyłączyłeś ją z oceny.

   • właściciel wszyscy
   • udowodnij i utrzymuj

   co powstaje

   wypełniony formularz z wyjaśnieniem każdej pozycji niedotyczącej i nietestowanej

   dowód, który zostaje

   formularz i wyjaśnienia

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

3. 4.3

   daj formularz do przeczytania i podpisu członkowi kierownictwa

   Osoba, która podpisuje, stwierdza, że formularz rzetelnie przedstawia wyniki i że zabezpieczenia będą utrzymane. Daj jej opis zakresu i otwarte luki, zanim podpisze.

   • właściciel zarząd
   • udowodnij i utrzymuj

   co powstaje

   podpisane oświadczenie

   dowód, który zostaje

   oświadczenie, z podpisującym, stanowiskiem i datą

   strona pracy

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

4. 4.4

   wyślij i zachowaj to, co wysłano

   Wyślij formularz i inne wymagane dokumenty, na przykład raporty ze skanów, temu, kto o nie poprosił, i zapisz, co i kiedy wysłano. Udostępniaj oświadczenie tylko tak, jak pozwalają zasady organizacji płatniczych i acquirer.

   • właściciel prawnik lub IOD
   • udowodnij i utrzymuj

   co powstaje

   zapis zgłoszenia

   dowód, który zostaje

   wysłane dokumenty, adresat i data

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

5. 4.5

   powiedz, co oświadczenie obejmuje

   Napisz krótkie stwierdzenie, co oświadczenie obejmuje: kanały, systemy, datę i czy ocena była pełna czy częściowa. Używaj go, gdy zapyta klient lub partner, i nie przedstawiaj oświadczenia jako zgodności z przepisem.

   • właściciel prawnik lub IOD
   • zdecyduj i udokumentuj

   co powstaje

   krótkie stwierdzenie dla sprzedaży i działu prawnego

   dowód, który zostaje

   stwierdzenie zgodne z oświadczeniem

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

Prowadź zabezpieczenia przez rok i powtarzaj walidację, gdy przypada termin albo zmienia się przepływ płatności.

1. 5.1

   zapytaj, jak często i kiedy

   Zapytaj acquirera, jak często musisz walidować i do kiedy, i wpisz daty do tego samego kalendarza co skany i testy. Ten plan nie czytał zasad organizacji płatniczych o częstotliwości.

   • właściciel zakupy
   • zdecyduj i udokumentuj

   co powstaje

   kalendarz terminów, skanów i testów

   dowód, który zostaje

   odpowiedź acquirera i kalendarz

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

2. 5.2

   potwierdź zakres jeszcze raz

   Potwierdzaj zakres co najmniej raz w roku i za każdym razem, gdy dodajesz kanał płatności, dostawcę lub system dotykający danych kart. Strony rady wymieniają coroczną weryfikację zakresu wśród wymagań, które zaczęły obowiązywać 31 marca 2025.

   • właściciel szef IT
   • udowodnij i utrzymuj

   co powstaje

   datowane potwierdzenie zakresu lub zaktualizowana mapa danych kart

   dowód, który zostaje

   potwierdzenie, mapa i zapis zmiany

   zabezpieczenie: asset-inventory

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

3. 5.3

   przeglądaj, kto ma dostęp do danych kart

   Przeglądaj według harmonogramu, kto może dotrzeć do danych kart i systemów w zakresie, i usuwaj dostęp, którego nikt nie potrzebuje. Zapisz przegląd i to, co się zmieniło.

   • właściciel szef IT
   • udowodnij i utrzymuj

   co powstaje

   cykliczny przegląd dostępu

   dowód, który zostaje

   zapisy przeglądów, z datą i listą usunięć

   zabezpieczenie: access-reviews

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

4. 5.4

   pilnuj nowej wersji

   Przed każdą walidacją sprawdź w bibliotece dokumentów rady, czy jest nowa wersja standardu lub formularza i czy zmieniły się daty. Rada wycofała wersję 4.0 w dniu 31 grudnia 2024, więc wersje się zmieniają.

   • właściciel szef IT
   • zdecyduj i udokumentuj

   co powstaje

   sprawdzenie wersji przed każdą walidacją

   dowód, który zostaje

   sprawdzenie, z datą i zapisaną wersją

   podstawa praktyka robocza. Żaden tekst prawny tego nie ustala.

Te same kroki, pogrupowane według osoby, która musi działać.

Każde zabezpieczenie ma własną stronę: czym jest, na co patrzeć przy wyborze, gdzie się psuje i jaki dowód zostawia.

• Rozporządzenie (UE) 2016/679 (RODO) (EUR-Lex)