PCI DSS: кой трябва да го спазва и кой SAQ се прилага

Въпросът кой трябва да спазва PCI DSS има измамно прост отговор: всеки, който съхранява, обработва или предава данни на картодържатели, плюс доставчиците на услуги, които могат да повлияят на сигурността на тези данни. На практика обхватът е мястото, където повечето екипи засядат, защото една хоствана страница за плащане може да ви вкара в различен път на валидация от този на пълна вътрешна платежна система. Това ръководство е написано за мениджъри по съответствието, CISO и основатели, които трябва да знаят дали PCI DSS се прилага към тях, какво всъщност изисква стандартът и кой Self-Assessment Questionnaire (SAQ) пасва на тяхната настройка. То отразява PCI DSS v4.0.1, версията, която е в сила в момента.

Какво представлява PCI DSS

Payment Card Industry Data Security Standard (PCI DSS) е стандарт за сигурност за организациите, които работят с маркови платежни карти. Той се поддържа от PCI Security Standards Council (PCI SSC), орган, основан от големите картови схеми. Текущото издание е PCI DSS v4.0.1. Ключово е, че PCI DSS е договорно задължение: картовите схеми и вашата банка придобивател го изискват и то стига до вас през търговското ви споразумение или през договорите ви като доставчик на услуги. Прилагането, глобите и сроковете за валидация идват от банките придобиватели и от картовите схеми. Струва си да се задържите върху това, защото сменя човека, с когото спорите. Няма надзорен орган, към който да обжалвате, и няма принцип на пропорционалност, на който да се опрете; отсрещната страна е банка, която може да вдигне таксите ви или да спре да приема вашите транзакции. На практика това прави PCI DSS по-малко договорим от повечето законови режими, въпреки че става дума само за договор. Стандартът е организиран в 12 основни изисквания, групирани в 6 цели, които покриват всичко от мрежова сигурност и криптиране до контрол на достъпа, наблюдение и писмена политика за информационна сигурност.

Кой трябва да го спазва и кой попада в обхвата

Ако организацията ви докосва данни на картодържатели в която и да е точка, вие сте в обхвата. Това включва търговците, които приемат карти за стоки или услуги, и доставчиците на услуги, чиито системи могат да повлияят на сигурността на тези данни. Размерът на задължението ви и начинът, по който го доказвате, зависят от ролята ви и от годишния ви обем картови транзакции.

Търговците и четирите нива

Търговците се разпределят в четири нива според годишния обем транзакции, а нивото определя как се валидира съответствието:

• Ниво 1 е нивото с най-голям обем и по правило изисква годишна оценка на място, която произвежда Report on Compliance (ROC), подписан от Qualified Security Assessor (QSA), плюс тримесечни сканирания на мрежата.
• Нива 2, 3 и 4 покриват постепенно по-малки обеми и често могат да валидират чрез годишен Self-Assessment Questionnaire и Attestation of Compliance, отново със сканиране там, където картови данни преминават през интернет.

Точните прагове по обем и третирането на всяко ниво се определят от отделните картови схеми, затова потвърдете нивото си при своя придобивател, вместо да го приемате наум. Това е един имейл и повечето екипи никога не го изпращат. Ако отгатнете нивото си от статия в блог, се озовавате с подготвен грешен пакет за валидация седмици преди срок, който също сте отгатнали.

Доставчици на услуги

Всеки бизнес, който съхранява, обработва или предава данни на картодържатели от името на други, или който може да повлияе на сигурността на картовите данни на свой клиент, е доставчик на услуги по PCI DSS. Хостинг доставчиците, платежните шлюзове, фирмите за управлявана сигурност и подобните бизнеси обикновено валидират спрямо най-пълния набор изисквания, а по-големите доставчици на услуги най-често преминават оценка на място независимо от нивото по търговската скала.

Какво изисква PCI DSS

Същината на стандарта живее в неговите 12 изисквания, групирани в 6 цели. Накратко, PCI DSS иска от вас да изградите и поддържате сигурна мрежа (да инсталирате и управлявате защитни стени и мрежови контроли и да премахнете фабричните пароли на доставчиците), да защитите съхраняваните данни на картодържатели (чрез криптиране и силна криптография при пренос) и да поддържате програма за управление на уязвимостите (контроли срещу зловреден софтуер и сигурна разработка на софтуер). След това иска да въведете строг контрол на достъпа (да ограничите достъпа на принципа на нужда от знание, да използвате уникални идентификатори и да обезопасите физическия достъп), редовно да наблюдавате и тествате мрежите (да журналирате и проследявате достъпа и да правите сканирания за уязвимости и тестове за проникване) и да поддържате политика за информационна сигурност, която урежда как служителите работят с картови данни.

Версия 4.0.1 запазва тази структура, но поставя повече тежест върху непрекъсната сигурност, основана на риска, вместо върху еднократна годишна снимка. Няколко по-нови очаквания, като по-строгите контроли върху скриптовете на платежните страници, са релевантни за онлайн търговците и определят кой SAQ важи за тях. Тези контроли върху скриптовете са наистина трудната част в текущата версия. Инвентаризирането и оторизирането на всеки скрипт, който се изпълнява на страница за плащане, звучи тривиално, докато не срещнете маркетинг екип с tag manager и навик да добавя пиксели в петък. Голяма част от останалото в стандарта е хигиена на сигурността, която вече би трябвало да имате. Това изискване налага разговор за управлението на въпроса кой има право да слага код на платежната ви страница, а този разговор рядко е удобен.

Въпросниците за самооценка и кой от тях се прилага

Търговците, които отговарят на условията, валидират, като попълват SAQ, съответстващ на начина, по който приемат и обработват картови данни. Изборът на грешен въпросник е честа и скъпа грешка, защото всеки SAQ носи различно подмножество от 12-те изисквания. Основните видове са:

• SAQ A - за търговци, чиито картови функции са изцяло изнесени към валидирани трети страни, например онлайн магазини, които пренасочват клиента изцяло към хоствана платежна страница или използват напълно изнесен iframe. Вие никога не докосвате и не съхранявате картови данни в собствените си системи. Това е най-краткият SAQ.
• SAQ A-EP - за онлайн търговци, които изнасят част от процеса. Класическият случай е платежна страница, която вашият сайт помага да бъде доставена, например когато вашият уеб сървър отдава скриптове заедно с платежна форма на трета страна. Тук значение имат контролите върху скриптовете на платежната страница и откриването на промени (изисквания 6.4.3 и 11.6.1), а въпросникът е значително по-дълъг от SAQ A.
• SAQ B - за търговци, които използват импринтери или самостоятелни терминали с изходящо набиране, без електронно съхранение на данни на картодържатели.
• SAQ C - за търговци с платежно приложение, свързано с интернет, при което картовите данни остават без електронно съхранение.
• SAQ D - най-пълният въпросник, за всички останали търговци, които попадат извън по-тесните SAQ, и за доставчиците на услуги, които имат право на самооценка. Той покрива най-широкия набор изисквания.

Посоката е ясна: колкото повече собствените ви системи докосват картови данни, толкова по-дълъг и по-взискателен става вашият SAQ. Свиването на обхвата, например чрез преминаване от самостоятелно хоствана форма към изцяло пренасочено плащане, може да ви премести от SAQ A-EP към SAQ A и да намали задълженията ви съществено. Ако вземете едно решение от това ръководство, вземете точно това. Един спринт инженерна работа, който изнася въвеждането на картата извън собствените ви страници, спестява повече усилия по съответствието от каквато и да е документация на контроли и продължава да ги спестява всяка година. Проведете този разговор с инженерния екип, преди да отворите въпросник, защото след това само документирате избор, който вече сте направили.

Как всъщност да постигнете съответствие

1. Потвърдете ролята и нивото си при вашата банка придобивател. Попитайте дали ви третират като търговец или като доставчик на услуги и кое ниво на валидация важи за вашия обем.
2. Картографирайте данните на картодържателите. Документирайте всяко място, където картови данни се събират, предават, обработват или съхраняват, включително платежни страници на трети страни и всички скриптове, които сайтът ви отдава. Това определя обхвата ви.
3. Сведете обхвата до минимум. Изнесете каквото можете към валидирани доставчици, токенизирайте картовите данни или се откажете от съхранението им и сегментирайте системите, които остават в обхвата. По-малък обхват означава по-кратък SAQ и по-нисък риск.
4. Определете правилния SAQ (или потвърдете, че ви трябва Report on Compliance, воден от QSA) въз основа на това как реално приемате плащания.
5. Затворете пропуските в контролите. Преминете през приложимите изисквания: защитни стени и мрежови контроли, криптиране, контрол на достъпа, журналиране, управление на уязвимостите и писмената ви политика за сигурност.
6. Уредете външните части. Наемете Approved Scanning Vendor (ASV) за тримесечните външни сканирания, когато се изискват, и QSA, ако нивото ви налага оценка на място. Това са отделни ангажименти, независими от какъвто и да е софтуер за управление. Запишете ги по-рано, отколкото ви се струва необходимо. Прозорците за сканиране и календарите на оценителите са двете неща в този процес, които не можете да свиете, а неуспешно сканиране, което изисква отстраняване и повторно сканиране, само по себе си може да глътне цял месец.
7. Попълнете SAQ и Attestation of Compliance, съберете доказателствата зад всеки отговор и подайте на своя придобивател.
8. Поддържайте го през цялата година. Сканирайте отново, тествайте отново, преглеждайте логовете и валидирайте отново всяка година. PCI DSS v4.0.1 очаква непрекъсната хигиена на сигурността във всеки един момент.

За изглед на стандарта контрол по контрол и как той се съотнася с доказателствата, които вече събирате, вижте как Venvera работи с PCI DSS. Ако не сте сигурни къде се намирате, безплатната проверка на съответствието ще ви даде бърза представа за вероятния ви обхват и пропуски.

Често задавани въпроси

Законово изискване ли е PCI DSS?

Не. PCI DSS е договорен стандарт, който се налага от картовите схеми и от вашата банка придобивател. При това пренебрегването му може да наруши търговското ви споразумение и да ви изложи на глоби, по-високи такси или загуба на възможността да приемате карти, така че на практика той работи като твърдо изискване за всеки, който приема картови плащания.

Прилага ли се PCI DSS към малките бизнеси?

Да. Няма изключение по минимален размер. Бизнес, който обработва шепа транзакции годишно, пак е в обхвата, ако докосва данни на картодържатели. По-малките търговци обикновено попадат в по-ниските нива на валидация и могат да се самооценят чрез SAQ вместо да преминават оценка на място, но от тях все така се очаква да покриват приложимите изисквания.

Как да разбера кой SAQ да използвам?

Започнете от това как картовите данни стигат до вас. Изцяло изнесената електронна търговия сочи към SAQ A; онлайн страница, която частично хоствате или за която отдавате скриптове, сочи към SAQ A-EP; самостоятелните терминали сочат към SAQ B; платежно приложение, свързано с интернет и без съхранени данни, сочи към SAQ C; а всичко останало, включително повечето доставчици на услуги, сочи към SAQ D. Когато два варианта изглеждат правдоподобни, потвърдете при своя придобивател, тъй като изборът на прекалено лек SAQ оставя изисквания непокрити.

Нужен ли ми е PCI DSS, ако използвам Stripe или друг платежен процесор?

Обикновено да, но задълженията ви са по-леки. Използването на валидиран процесор и на хоствано или пренасочено плащане може да ви премести към SAQ A, най-краткия въпросник, защото избягвате прякото боравене с картови данни. Вие пак отговаряте за попълването на SAQ, за защитата на целостта на уебсайта си и за потвърждаването, че вашите доставчици съответстват на PCI DSS.

Може ли GRC платформа сама да ме направи съответстващ на PCI DSS?

Не. Никоя платформа за управление не може сама да валидира съответствието ви и никоя GRC платформа не е Approved Scanning Vendor. Сканирането от ASV и оценката от QSA са отделни договори, които уреждате самостоятелно. Venvera ви помага да организирате, проследявате и доказвате контролите си по PCI DSS; тя не е ASV или QSA и не замества нито едното, нито другото.

Каква е разликата между SAQ и Report on Compliance?

SAQ е самооценка, която отговарящите на условията търговци попълват сами, придружена от Attestation of Compliance. Report on Compliance (ROC) се изготвя от Qualified Security Assessor по време на оценка на място и по правило се изисква за търговците от Ниво 1 с най-голям обем и за големите доставчици на услуги.

Първични източници

• PCI Security Standards Council (PCI SSC) - органът, който поддържа PCI DSS и публикува стандартите, документите SAQ и придружаващите насоки. pcisecuritystandards.org.
• Стандартът PCI DSS v4.0.1 - текущата версия на стандарта, с 12-те изисквания и процедурите за тестване към тях, достъпна в PCI SSC Document Library. PCI SSC Document Library.
• Въпросниците за самооценка на PCI SSC - документите SAQ и насоките за допустимост, които определят кой въпросник се прилага. Инструкции и формуляри за SAQ.

Бележка за обхвата. Това ръководство обобщава PCI DSS на високо ниво и не замества самия стандарт. Нивата на валидация, праговете и допустимостта за SAQ се определят от картовите схеми и от вашия придобивател, затова потвърдете конкретиката спрямо официалните документи на PCI SSC и спрямо собствените си договори, преди да предприемете действия.

От Alexander Sverdlov, изпълнителен директор и основател, Venvera. Публикувано на 20 юли 2026 г. - Последен преглед на 20 юли 2026 г.