Одного невстановленого скрипту на вашій сторінці оформлення замовлення достатньо. У 2024 році прихований JavaScript непомітно викачав номери карток з тисяч сторінок оформлення замовлень невеликих електронних магазинів, перш ніж хтось це помітив — це вид атаки, яку дослідники безпеки називають «е-скімінгом». Постраждалі компанії не використовували екзотичні технологічні стеки. Більшість були невеликими торговцями, що використовували звичайний плагін кошика для покупок, не підозрюючи, що стандарт безпеки під назвою PCI DSS щойно зробив обов'язковим захист саме від такого типу атак.
Якщо ви приймаєте кредитні або дебетові картки — онлайн, особисто або обома способами — ви вже пов'язані Стандартом безпеки даних індустрії платіжних карток (PCI DSS), незалежно від того, чи читали ви його хоча б сторінку, чи ні. І станом на 2026 рік правила помітно посилилися. Ось що насправді змінилося, за що ви відповідаєте, і як досягти відповідності, не наймаючи консультанта з безпеки.
Що насправді представляє собою PCI DSS (і чому це не є необов'язковим)
PCI DSS — це не закон, прийнятий Конгресом, — це договірна вимога. Visa, Mastercard, American Express, Discover та JCB спільно підтримують стандарт через Раду зі стандартів безпеки PCI, і кожен банк та платіжний процесор, що дозволяє вам приймати їхні картки, вимагає від вас дотримання цього стандарту як умови вашої торговельної угоди. Проігноруйте його, і ви ризикуєте не державним штрафом, а своєю здатністю обробляти картки взагалі, а також штрафами від вашого банку-еквайра, які зазвичай становлять від 5 000 до 100 000 доларів на місяць, доки ви не усунете проблему.
Ця відмінність має значення, оскільки пояснює, чому так мало малих підприємств сприймають PCI серйозно, доки щось не піде не так. Немає поліції PCI, яка стукає у ваші двері. Є лише пункт договору — і порушення, яке виявляє, що ви не виконували свою частину зобов'язань.
Стандарт ґрунтується на 12 основних вимогах, що охоплюють усе: від брандмауерів та шифрування до контролю доступу та щорічних перевірок політики безпеки. Більшість малих підприємств відповідають цим вимогам за допомогою Опитувальника самооцінки (SAQ), а не повноцінного аудиту на місці — платіжні мережі класифікують переважну більшість малих торговців як «Рівень 4», що означає близько 6 мільйонів транзакцій на рік, що дозволяє використовувати легший шлях SAQ замість офіційного Звіту про відповідність.
Перехід на версію 4.0 завершено — тепер усе є обов'язковим
Версія PCI DSS 4.0 була опублікована ще у 2022 році, але Рада надала галузі кілька років на впровадження найжорсткіших нових засобів контролю. Цей термін завершився 31 березня 2025 року. Кожна оцінка, проведена з 2026 року, оцінюється за поточною редакцією (v4.0.1, оновлення, що уточнює, без нових вимог), і кожне з приблизно 50+ доповнень, запроваджених у v4.0, тепер повністю входить до сфери застосування — більше ніяких винятків на кшталт «краща практика, але ще не обов'язково».
Для малого торговця три з цих нових обов'язкових вимог мають значно більше значення, ніж решта.
1. Управління скриптами на платіжній сторінці (Вимоги 6.4.3 та 11.6.1)
Це пряма відповідь на атаки е-скімінгу, такі як Magecart, коли злочинці впроваджують шкідливий JavaScript на сторінку оформлення замовлення, щоб захопити номери карток, коли клієнти їх вводять — непомітно, не торкаючись ваших серверів чи бази даних.
Якщо ви керуєте будь-яким процесом оформлення замовлення в електронній комерції, тепер ви повинні:
- Інвентаризувати кожен скрипт, який завантажується та виконується на вашій платіжній сторінці, з документованим діловим обґрунтуванням для кожного.
- Авторизувати кожен скрипт явно — без мовчазної довіри до того, що підтягує плагін або рекламний тег.
- Перевіряти цілісність, як правило, за допомогою хешів цілісності підресурсів (SRI), щоб скомпрометований сторонній скрипт не міг бути замінений непомітно.
- Виявляти втручання в реальному часі — механізм моніторингу, який сповіщає вас, коли HTTP-заголовки або вміст скриптів вашої платіжної сторінки несподівано змінюються.
Якщо ваша система оформлення замовлення працює на хостинговій платформі (Shopify, Square Online, Stripe Checkout, BigCommerce), ваш провайдер обробляє більшу частину цього на рівні платформи — підтвердіть це письмово. Якщо ви налаштували своє оформлення замовлення за допомогою сторонньої аналітики, віджетів чату або маркетингових пікселів, ви несете відповідальність за інвентаризацію та авторизацію цих скриптів.
2. Багатофакторна автентифікація для всіх, всюди (Вимога 8.4.2)
Згідно зі старим стандартом, MFA була потрібна лише для адміністраторів, які отримували доступ до середовища даних власників карток. Згідно з версією 4.0, MFA потрібна для будь-якого неконсольного доступу до середовища даних власників карток, для кожної ролі, з будь-якого місця — включно з вашою офісною мережею. Якщо працівник входить до вашої панелі адміністратора POS, панелі управління платіжного шлюзу або будь-якої системи, що має справу з даними карток, йому потрібен другий фактор, а не лише пароль.
Це вимога, яку більшість малих підприємств виявляють, що не виконали, лише коли оцінювач їхнього процесора запитує докази. Виправлення зазвичай дешеве: більшість POS-систем та платіжних платформ (Square, Stripe, Clover, Toast) пропонують вбудовану MFA — завдання полягає у її ввімкненні для кожного облікового запису та усуненні будь-яких звичок спільного входу, які сформувалися у вашого персоналу.
3. Аутентифіковане внутрішнє сканування вразливостей (Вимога 11.3.1.2)
Раніше внутрішнє сканування вразливостей могло виконуватися без аутентифікації, що упускало багато реальних загроз — сканер, який не може увійти, не бачить, до чого може дістатися авторизований зловмисник (або недобросовісний інсайдер). Нова вимога зобов'язує проводити аутентифіковане сканування внутрішніх систем, виявляючи неправильні конфігурації та незапатчене програмне забезпечення, які зазвичай пропускають неаутентифіковані сканування.
Скільки насправді коштує недотримання вимог
Цифри говорять краще, ніж будь-який контрольний список відповідності. Останній звіт Verizon з розслідування витоків даних зафіксував понад 7000 витоків у малих і середніх організаціях за один рік, і в найгірших 2,5% випадків витік коштував бізнесу понад 7% річного доходу. Окремо дослідження IBM щодо вартості витоків показує, що недотримання застосовних правил додає в середньому $173 692 до вартості витоку — на додаток до того, що сам витік вже коштував у вигляді усунення наслідків, повідомлення та втраченого бізнесу.
І це ще до того, як почнуть діяти щомісячні штрафи від вашого банку-еквайра. Відповідність вимогам не є дешевою з точки зору часу персоналу, але недотримання вимог є надійно дорожчим — одна галузева оцінка встановлює множник майже в 3 рази, якщо врахувати штрафи, усунення наслідків витоку та перебої в бізнесі разом.
Практичний контрольний список відповідності для малих продавців
Вам не потрібна корпоративна команда безпеки, щоб зробити це правильно. Пройдіть по пунктах у такому порядку:
- З'ясуйте свій тип SAQ. Ваш платіжний процесор може підказати, який Опитувальник самооцінки (Self-Assessment Questionnaire) застосовується на основі того, як ви приймаєте картки (повністю аутсорсинговий електронний комерція, термінал особисто, індивідуальна каса тощо). Це визначає, які саме з 12 вимог стосуються вас.
- Запитайте свою платформу, що вона покриває. Якщо ви використовуєте Shopify, Square, Stripe або подібний хостинговий процесор, отримайте письмове підтвердження того, що вони покривають зі свого боку (зазвичай більшість вимог до технічної інфраструктури) та що залишається вашою відповідальністю (зазвичай контроль доступу, політики для співробітників та будь-які додані вами налаштування).
- Увімкніть MFA скрізь, де є доступ до даних карток. Входи адміністратора POS, панелі керування платіжними шлюзами, інструменти віддаленого доступу — без винятків, без спільних облікових записів.
- Проведіть інвентаризацію сторонніх скриптів на сторінці оформлення замовлення. Перелічіть кожен скрипт, який завантажується на сторінці, де клієнти вводять дані картки. Якщо ви не можете обґрунтувати, чому він там, видаліть його.
- Припиніть зберігати те, що вам не потрібно. Найбільш дешевий спосіб зменшити навантаження на відповідність вимогам і ризик витоку — це не зберігати номери карток, CVV або повні дані магнітної смуги взагалі — дозвольте вашому процесору токенізувати їх замість цього.
- Оформіть свою політику безпеки письмово та переглядайте її щорічно. Вимога 12 передбачає документовану, розповсюджену політику інформаційної безпеки — це не формальність, а справді корисно для послідовного залучення нових співробітників.
- Щорічно заповнюйте свій SAQ і зберігайте підписану атестацію — ваш процесор запитає її, і ви не захочете відновлювати свою історію відповідності під час розслідування витоку.
Вибір (або переоцінка) платіжного процесора
Не всі "PCI-сумісні" процесори знімають з вас однакову кількість роботи. Коли ви вибираєте або оновлюєте платіжну платформу, запитайте безпосередньо:
- Чи їхня хостингова каса повністю зберігає дані картки поза вашими серверами (зводячи вас до найпростішого SAQ, зазвичай SAQ A)?
- Чи надають вони MFA на кожному рівні облікового запису, чи лише на платних планах?
- Чи нададуть вони письмову Заяву про відповідність (AOC), яку ви можете надати своєму власному процесору або страховику за запитом?
- Чи публікують вони, які з 12 вимог вони покривають, а які залишаються вашою відповідальністю?
Процесор, який не може чітко відповісти на ці питання письмово, перекладає на вас більше тягаря відповідності, ніж передбачає зазначена ціна — варто враховувати це при прийнятті рішення поряд з комісіями за транзакції.
Як це пов'язано з вашою бухгалтерією
Витрати на відповідність вимогам — інструменти сканування, ліцензії MFA, будь-які години консультантів — це реальні бізнес-витрати, і вони підлягають відрахуванню. Але більш корисний зв'язок працює в іншому напрямку: та сама дисципліна, яка робить відповідність PCI керованою (точно знаючи, що торкається конфіденційних даних і чому), є тією ж дисципліною, яка робить ваші фінансові записи надійними. Бізнес, який може на вимогу надати чисту інвентаризацію скриптів, зазвичай також є бізнесом, який може на вимогу надати чисту, перевірену бухгалтерську книгу. Ні те, ні інше не відбувається випадково — обидва виникають з ставлення до "ми можемо показати свою роботу" як до постійної вимоги, а не до щорічної метушні.
Зробіть свої фінанси такими ж перевіряємими, як і вашу платіжну сторінку
Так само, як PCI DSS 4.0 вимагає від вас точно довести, що саме торкається даних карт ваших клієнтів і чому, так і якісний бухгалтерський облік ставить те саме питання до кожного долара, який проходить через ваш бізнес. Beancount.io пропонує текстовий бухгалтерський облік, який є повністю прозорим і контрольованим версіями — кожна транзакція є інспектованою, перевіряємою і ніколи не заблокована в "чорному ящику". Почніть безкоштовно і дізнайтеся, чому розробники та фінансово-орієнтовані власники бізнесу переходять на текстовий бухгалтерський облік.