PCI DSS 4.0.1 у 2026 році: Посібник для малого бізнесу щодо SAQ A, втручання в скрипти та MFA

Якщо ваш інтернет-магазин завантажує хоча б один сторонній скрипт на сторінку, що містить платіжну форму, ви більше не можете вважати, що до вас застосовується найпростіша версія відповідності стандарту PCI. Цей єдиний рядок, прихований у FAQ до PCI DSS v4.0.1, тихо перекроїв карту комплаєнсу для сотень тисяч малих торговців у 2026 році — і багато хто з них не усвідомить цього, доки їхній еквайр не попросить надати докази, які вони не зможуть підготувати.

PCI DSS v4.0.1 — це не просто косметичне оновлення. 64 нові або оновлені вимоги стали обов'язковими з 31 березня 2025 року, кожна оцінка у 2026 році проводиться відповідно до нового стандарту, а правила відповідності для найпростішого опитувальника самооцінки (SAQ) посилилися так, що це застало зненацька більшість аутсорсингових e-commerce магазинів. Хороша новина полягає в тому, що стандарт все ще цілком зрозумілий для малого бізнесу з тверезим підходом і контрольним списком. Погана новина — відповідь «ми використовуємо Stripe Checkout, тому у нас все добре» більше не є автоматичною.

Цей посібник розповідає про те, що змінилося, який опитувальник насправді потрібен вашому бізнесу, про дві нові вимоги (6.4.3 та 11.6.1), які «з'їли» старий SAQ A, правила автентифікації, на яких спотикаються невеликі команди, та реальну ціну помилки в цих питаннях.

Стан PCI DSS у 2026 році

Стандарт безпеки даних індустрії платіжних карток (PCI DSS) — це договірний звід правил, які основні карткові бренди (Visa, Mastercard, American Express, Discover, JCB) накладають на будь-який бізнес, що зберігає, обробляє або передає дані власників карток. Ви не «подаєте його уряду». Ваш еквайр (банк або процесор, який дозволяє вам приймати картки) забезпечує його виконання через вашу угоду з мерчантом, і саме вони стягують штрафи, якщо щось піде не так.

PCI DSS v4.0 було опубліковано у березні 2022 року. Версія 4.0.1 — реліз із роз'ясненнями, а не новий стандарт — стала чинною в середині 2024 року. Перехідний період завершився 31 березня 2025 року: від цієї дати кожна з 51 вимоги з відстроченим терміном стає обов'язковою без жодного пільгового періоду, а кожна оцінка, що проводиться протягом 2026 року, здійснюється за версією v4.0.1. Варіанту повернутися до v3.2.1 більше не існує.

12 високорівневих груп вимог залишаються незмінними, організованими у шість цілей контролю:

• Побудова та підтримка безпечної мережі: брандмауери та налаштування за замовчуванням від постачальників (Вимоги 1–2)
• Захист даних власників карток: збережені дані та дані, що передаються (Вимоги 3–4)
• Підтримка програми управління вразливостями: антивірусне ПЗ та безпечна розробка (Вимоги 5–6)
• Впровадження суворих заходів контролю доступу: службова необхідність, ідентифікація, фізичний доступ (Вимоги 7–9)
• Регулярний моніторинг та тестування мереж: логування та тестування (Вимоги 10–11)
• Підтримка політики інформаційної безпеки: управління (Вимога 12)

У v4.0.1 змінилася глибина, а не охоплення. Тепер стандарт очікує від вас роздумів про те, як виконуються скрипти на платіжних сторінках, як часто ви переглядаєте власні заходи контролю, як ви автентифікуєте адміністраторів і чи є пароль, який ваш бухгалтер обрав п'ять років тому, досі прийнятним.

Рівні торговців: де знаходиться більшість малих підприємств

Карткові бренди присвоюють кожному торговцю один із чотирьох рівнів на основі річного обсягу транзакцій. Рівень визначає, як підтверджується відповідність, а не те, чи застосовується стандарт взагалі.

• Рівень 1: понад 6 мільйонів операцій за картками на рік або будь-який торговець, який постраждав від підтвердженого зламу даних рахунків. Вимагає щорічної перевірки на місці Кваліфікованим аудитором з безпеки (QSA) та щоквартального сканування Схваленим постачальником послуг сканування (ASV).
• Рівень 2: від 1 до 6 мільйонів транзакцій на рік. Зазвичай щорічний SAQ або перевірка QSA на місці залежно від бренду.
• Рівень 3: від 20 000 до 1 мільйона транзакцій в електронній комерції на рік. Щорічний SAQ плюс щоквартальні сканування ASV.
• Рівень 4: менше 20 000 транзакцій в електронній комерції на рік або до 1 мільйона транзакцій сумарно через усі канали. Щорічний SAQ і, для більшості каналів, щоквартальні сканування ASV.

Якщо ви керуєте онлайн-бутіком, процесом виставлення рахунків у SaaS, регіональним сервісним бізнесом або рестораном з одним закладом, ви майже напевно належите до 4-го рівня. Це переважна більшість торговців у всьому світі. Валідація простіша, але базовий стандарт ідентичний — витік номера картки у торговця з 200 транзакціями на рік розглядається так само серйозно, як і витік у великої корпорації.

Опитувальники для самооцінки: як обрати правильний

Опитувальник для самооцінки (SAQ) — це спосіб, за допомогою якого торговці 2–4 рівнів підтверджують свою відповідність. Рада PCI підтримує дев'ять типів SAQ, і вибір правильного залежить від того, як саме проходять ваші платіжні дані. Вибір неправильного SAQ — найпоширеніша помилка малого бізнесу.

• SAQ A: торговці електронної комерції або ті, що приймають замовлення поштою/телефоном, які повністю передають усі функції з обробки даних власників карток третім особам, що пройшли валідацію PCI DSS. Раніше це був «найлегший шлях» для користувачів Shopify, Stripe Checkout та PayPal, але зверніть увагу на наступний розділ, оскільки правила відповідності посилилися.
• SAQ A-EP: торговці електронної комерції, які частково делегують обробку платежів, але чий вебсайт все ще впливає на безпеку транзакції (наприклад, сайти, які створюють власну сторінку оформлення замовлення та звертаються до API платіжної системи).
• SAQ B: торговці, які використовують лише імпринтери або автономні термінали з дозвоном через телефонну лінію. Жодне інтернет-з'єднання не торкається даних карток.
• SAQ B-IP: торговці, які використовують автономні платіжні термінали з підключенням по IP (більшість сучасних настільних терміналів).
• SAQ C-VT: торговці, які вводять дані карток через віртуальний термінал на ізольованій робочій станції.
• SAQ C: торговці з платіжним додатком, підключеним до інтернету, де дані не зберігаються.
• SAQ P2PE: торговці, які використовують перевірене рішення для наскрізного шифрування (point-to-point encryption).
• SAQ D-Merchant: універсальний тип для торговців, які не підпадають під жоден інший SAQ — і він наразі найдовший.
• SAQ D-Service Provider: для постачальників послуг, які мають право на самооцінку.

Кожен SAQ містить лише ту частину з понад 300 заходів контролю, яка стосується відповідної моделі прийому платежів. SAQ A має менше 30 питань; SAQ D-Merchant — понад 250. Різниця в зусиллях величезна, саме тому торговці прагнуть відповідати вимогам SAQ A всюди, де це обґрунтовано можливо.

Пастка відповідності вимогам SAQ A

Найбільша зміна, яку повинні зрозуміти малі підприємства електронної комерції у 2026 році, — це те, хто насправді має право на використання SAQ A. Рада зі стандартів безпеки PCI опублікувала FAQ 1588 на початку 2025 року та значно посилила критерії.

Згідно з версією 4.0.1, SAQ A доступний лише в тому випадку, якщо ви можете підтвердити, що ваші сторінки електронної комерції — включаючи сторінку, яка містить вбудований платіжний iframe або перенаправлення — не є вразливими до атак за допомогою скриптів, які можуть вплинути на ваше платіжне середовище. Це реакція на хвилю атак цифрового скімінгу (часто званих «Magecart»), під час яких зловмисники зламують сторонню бібліотеку JavaScript і викрадають дані карток навіть із сайтів, які вважали, що повністю передали обробку платежів на аутсорсинг.

На практиці ви можете задовольнити цю вимогу одним із двох способів:

1. Самостійно впровадити засоби захисту скриптів відповідно до вимог 6.4.3 та 11.6.1. Провести інвентаризацію кожного скрипту, який завантажується на вашій платіжній сторінці, авторизувати кожен із них, обґрунтувати необхідність його використання та розгорнути механізм виявлення змін і втручань, який сповіщатиме вас про неочікувану зміну HTTP-заголовка або вмісту сторінки. Механізм повинен перевіряти платіжну сторінку принаймні кожні сім днів або з періодичністю, яку ви обґрунтуєте за допомогою цільового аналізу ризиків.
2. Отримати письмове підтвердження від вашого платіжного процесора, що їхнє вбудоване рішення включає вбудовані засоби захисту від атак на основі скриптів від вашого імені.

Другий шлях — це те, чого дотримуватиметься більшість малих підприємців, але це не відбувається автоматично. Вам потрібна задокументована заява від процесора, а не просто маркетингова сторінка. Багато мерчантів Stripe, Adyen, Braintree та Square виявлять, що їхній процесор опублікував відповідне підтвердження (attestation); деякі дрібніші платіжні шлюзи цього не зробили. Якщо ваш процесор не може надати вам таке підтвердження в письмовій формі, вам доведеться використовувати SAQ A-EP або розробляти власні засоби контролю.

Якщо ваша «аутсорсингова» платіжна сторінка фактично завантажує будь-який керований мерчантом JavaScript, який може впливати на платіжну форму — аналітику, A/B-тестування, віджети чату, менеджери тегів — то, згідно з консервативним тлумаченням, ви більше не маєте права на SAQ A, незалежно від того, що каже ваш процесор.

Автентифікація: два правила, які створюють проблеми для невеликих команд

Незалежно від того, який SAQ застосовується, дві зміни в контролі доступу у версії 4.0.1 застають зненацька майже кожне мале підприємство.

Вимога 8.3.6: паролі повинні містити щонайменше 12 символів. Якщо система підтримує лише 8 символів, ви можете залишити 8, але в будь-якій більш сучасній системі мінімум має бути підвищений. Паролі повинні містити як цифри, так і літери. Старий мінімум у 7 символів із версії 3.2.1 скасовано.

Вимога 8.4.2: багатофакторна автентифікація для будь-якого доступу до середовища даних власників карток. Раніше MFA була обов’язковою лише для віддаленого доступу адміністраторів. Згідно з версією 4.0.1, будь-хто — адміністратор, розробник, стороння служба підтримки, ви самі — потребує MFA щоразу, коли отримує доступ до будь-якого компонента системи в межах середовища даних власників карток, а не лише під час підключення ззовні мережі. Сама MFA має бути стійкою до атак повторного відтворення (replay attacks) і вимагати принаймні два з таких факторів: те, що ви знаєте, те, що ви маєте, або те, ким ви є.

Для малого підприємця практична реалізація означає: увімкніть MFA на порталі вашого процесора, у панелі керування хостингом, у реєстратора доменів, у провайдера DNS, в адмінпанелі електронної комерції, у бек-офісі POS-термінала та на будь-якому ноутбуці, який має доступ до цих систем. Використовуйте додаток для автентифікації або апаратний ключ — MFA на основі SMS все частіше розглядається як недостатня, хоча стандарт технічно все ще дозволяє її.

Цільовий аналіз ризиків: документ, який вам імовірно знадобиться

PCI DSS v4.x запроваджує цільовий аналіз ризиків (TRA) — короткий письмовий аналіз, який дозволяє вам обґрунтувати частоту виконання певних контрольних заходів. Близько десятка вимог включають варіант «періодичність, визначена в цільовому аналізі ризиків організації».

Вимога 12.3.1 детально описує, що має містити TRA: ідентифікацію активу, що захищається, загрозу, яка нівелюється, фактори, що впливають на ймовірність та наслідки, а також обґрунтування обраної періодичності. Рада PCI публікує шаблон у Додатку E2 стандарту.

Для мерчанта 4-го рівня це зазвичай односторінковий документ для кожного заходу контролю. Помилка, якої слід уникати, — це повне ігнорування цього документа. Якщо ваш аудитор або еквайр запитає вас, чому ви перевіряєте свою платіжну сторінку на наявність втручань кожні 30 днів замість 7, відповідь «ми думали, що цього достатньо» не буде прийнятною; натомість відповідь «ось наш TRA від 14 січня 2026 року, підписаний власником» — буде.

Тримайтеся подалі від індивідуального підходу (customized approach) версії v4.0. Він існує для зрілих з точки зору ризиків підприємств із власними командами безпеки; для малих мерчантів визначений підхід (defined approach) з його чітким контрольним списком є швидшим, дешевшим і простішим для захисту.

Скільки насправді коштує невідповідність вимогам

Малі підприємці недооцінюють фінансові ризики, оскільки штрафи здаються гіпотетичними, доки вони не стають реальністю. Цифри, зібрані з графіків еквайрів та галузевих звітів, протвережують.

Систематичне недотримання вимог — неподання SAQ, протерміновані сканування ASV — зазвичай призводить до щомісячних штрафів від вашого еквайра, що починаються від 5 000 до 10 000 доларів США на місяць. Після трьох-шести місяців невідповідності ці штрафи зазвичай зростають до 25 000–50 000 доларів на місяць, а хронічні порушення можуть сягати 50 000–100 000+ доларів на місяць. Еквайр також може підвищити комісію за кожну транзакцію або закрити мерчант-рахунок, що часто завдає більшої шкоди, ніж самі штрафи.

Підтверджений витік даних — це зовсім інший рівень. Карткові бренди нараховують штрафи у розмірі приблизно від 50 до 90 доларів за кожен скомпрометований запис, на додачу до обов'язкових витрат на форензичне розслідування (від 15 000 доларів), зборів за перевипуск карток, які бренди перекладають на мерчанта, та зворотних платежів (chargebacks) за шахрайські транзакції. Галузеві дослідження оцінюють середню загальну вартість витоку даних платіжних карток для середнього мерчанта від 150 000 до 3 мільйонів доларів, а для великого витоку ця цифра обчислюється мільйонами. Для мерчанта 4-го рівня щорічна відповідність вимогам може коштувати 3 000 доларів на рік, тоді як один витік даних може знищити прибуток за десятиліття.

Державні закони та Федеральна торгова комісія (FTC) також додають проблем. Витрати на сповіщення, гонорари адвокатів, ризики колективних позовів та подальші дії регуляторів зазвичай перевищують штрафи самих карткових брендів.

Практичний контрольний список відповідності на 2026 рік для малого бізнесу

Стандарт виглядає страхітливим у сукупності, але контрольний список для типового малого підприємства у сфері електронної комерції або послуг є цілком осяжним. Опрацьовуйте його в такому порядку.

1. Підтвердьте свій рівень мерчанта у вашого еквайра письмово. Рівні призначаються окремо для кожного еквайра, а не глобально.
2. Складіть карту потоку даних власників карток. Намалюйте діаграму, що показує, де дані карток надходять, куди вони рухаються і де залишають систему. Якщо дані карток потрапляють на ваші сервери, обсяг перевірки значно розширюється.
3. Оберіть правильний SAQ. Уважно прочитайте кожен варіант. Якщо ви є мерчантом у сфері електронної комерції та обираєте SAQ A, перевірте свою відповідність вимогам згідно з FAQ 1588.
4. Отримайте письмове підтвердження від вашого платіжного процесора щодо захисту від атак на скрипти в їхньому інтегрованому рішенні. Додайте його до своїх записів про відповідність.
5. Проведіть інвентаризацію кожного скрипту на ваших платіжних сторінках. Якщо ви не можете отримати підтвердження від процесора, підготуйтеся до впровадження Вимоги 6.4.3 (авторизовані скрипти) та 11.6.1 (виявлення втручань).
6. Увімкніть MFA всюди, де адміністратор може мати доступ до платіжних систем. Використовуйте додаток-автентифікатор, а не SMS.
7. Збільште довжину паролів до 12+ символів із поєднанням цифр та літер.
8. Заплануйте щоквартальні сканування ASV, якщо ваш SAQ цього вимагає (більшість вимагає для систем, що мають вихід в інтернет).
9. Задокументуйте цільовий аналіз ризиків для будь-якого контролю, частоту якого ви встановлюєте самостійно.
10. Напишіть політику інформаційної безпеки (Вимога 12). Простого односторінкового документа, що охоплює правила використання, контакти для реагування на інциденти та графік щорічного перегляду, цілком достатньо для малого бізнесу.
11. Проводьте щорічне навчання для кожного співробітника, який працює з платежами. Зберігайте листи реєстрації або записи електронного навчання.
12. Вчасно подавайте SAQ та Підтвердження відповідності своєму еквайру. Внесіть це в календар.

Навіть за такої деталізації, один вікенд зосередженої роботи та кілька сотень доларів за сканування ASV покривають потреби більшості малих підприємств.

Як бухгалтерія пов'язана з цією картиною

Відповідність PCI — це не просто заходи безпеки, вона має прямі бухгалтерські наслідки. Витрати на комплаєнс (інструменти SAQ, ASV-сканування, обладнання для MFA, сервіси виявлення втручань), комісії процесора, які залежать від вашого статусу відповідності, а також будь-які штрафи чи витрати на усунення наслідків — усе це проходить через ваші рахунки. Так само як і вплив витоку даних на дохід: чарджбеки, повернення коштів, комісії за перевипуск карток, виставлені вашим еквайром, та втрачені продажі під час реагування на інцидент.

Ведення чіткого постатейного бухгалтерського обліку для кожного витратного елемента, пов'язаного з платежами — з розбивкою за процесором, інструментами безпеки та послугами з комплаєнсу — приносить три переваги. Це документує факт здійснення інвестицій у відповідність (корисно, коли еквайр або страховик робить запит). Це виявляє справжню вартість кожного каналу прийому платежів, що допомагає вам вести переговори щодо тарифів процесора. І якщо стався витік даних, це дає вашому бухгалтеру-експерту чіткий слід для оцінки збитків для страхового відшкодування.

Тримайте свої записи про відповідність готовими до аудиту

Незалежно від того, чи відповідаєте ви на запитання еквайра, анкети страховика з кіберризиків або працюєте з бухгалтером-експертом після інциденту, мерчанти, які успішно долають події PCI, — це ті, чиї книги та записи розповідають чітку історію. Beancount.io пропонує текстову бухгалтерію з контролем версій, яка надає вам прозорий, позначений мітками часу слід кожної комісії за обробку платежів, інструменту безпеки та витрат на комплаєнс — без «чорних скриньок», без прив’язки до постачальника та в готовності до епохи фінансів з підтримкою ШІ. Почніть безкоштовно і поєднайте свою роботу над комплаєнсом з бухгалтерським обліком, який витримає будь-яку перевірку.