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 году проводится по новому стандарту, а правила отбора для самого лояльного опросника самопроверки ужесточились так, что это застает врасплох большинство интернет-магазинов на аутсорсинге. Хорошая новость заключается в том, что малый бизнес с ясной головой и списком проверок все еще может соответствовать стандарту. Плохая новость: ответ «мы используем 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 обнаружат, что их провайдер уже опубликовал аттестацию; некоторые более мелкие шлюзы — нет. Если ваш провайдер не может предоставить такое подтверждение в письменном виде, вам придется использовать SAQ A-EP или внедрять меры контроля самостоятельно.

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

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

Независимо от того, какой SAQ применяется, два изменения в управлении доступом в v4.0.1 застают врасплох почти каждый малый бизнес.

Требование 8.3.6: пароли должны содержать не менее 12 символов. Если система поддерживает только 8 символов, вы можете оставить 8, но возможности любой системы, позволяющей большее, должны быть использованы. Пароли должны включать как цифры, так и буквы. Старый минимум в 7 символов из v3.2.1 остался в прошлом.

Требование 8.4.2: многофакторная аутентификация для любого доступа к среде данных держателей карт. Ранее MFA требовалась только для удаленного доступа администраторов. В версии 4.0.1 любому лицу — администратору, разработчику, сотруднику сторонней поддержки или вам самому — требуется MFA каждый раз при доступе к любому системному компоненту в среде данных держателей карт, а не только при подключении извне сети. Сама MFA должна быть устойчивой к атакам повторного воспроизведения и требовать как минимум два фактора из: то, что вы знаете; то, что у вас есть; то, чем вы являетесь.

Для малого мерчанта практический перевод звучит так: включите 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 в месяц, а при хронических нарушениях могут достигать $100 000 и более. Эквайер также может повысить комиссию за обработку каждой транзакции или закрыть мерчант-аккаунт, что зачастую наносит больший ущерб, чем сами штрафы.

Подтвержденная утечка данных — это совсем другой уровень. Платежные системы накладывают штрафы в размере примерно от $50 до $90 за каждую скомпрометированную запись, в дополнение к обязательным расходам на криминалистическую экспертизу (от $15 000), комиссиям за перевыпуск карт, которые бренды перекладывают на мерчанта, и чарджбэкам по мошенническим транзакциям. Отраслевые исследования оценивают общую стоимость утечки данных платежных карт для среднего мерчанта в сумму от $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. Включите МФА везде, где администратор имеет доступ к платежным системам. Используйте приложение-аутентификатор, а не СМС.
7. Увеличьте длину паролей до 12+ символов, используя сочетание цифр и букв.
8. Запланируйте ежеквартальные ASV-сканирования, если того требует ваш SAQ (это необходимо для большинства систем, подключенных к интернету).
9. Задокументируйте адресный анализ рисков для любого контрольного показателя, периодичность которого вы устанавливаете самостоятельно.
10. Напишите политику информационной безопасности (Требование 12). Простого одностраничного документа, охватывающего правила допустимого использования, контакты для реагирования на инциденты и график ежегодных проверок, будет достаточно для малого предприятия.
11. Проводите ежегодное обучение всех сотрудников, имеющих доступ к платежам. Сохраняйте листы регистрации или записи об электронном обучении.
12. Своевременно подавайте SAQ и Аттестат соответствия (AoC) вашему эквайеру. Отметьте это в календаре.

Даже при такой детализации, одних ударных выходных и нескольких сотен долларов на ASV-сканирование достаточно для большинства малых предприятий.

Как бухгалтерия связана с общей картиной

Комплаенс PCI — это не только вопросы безопасности, он имеет прямые бухгалтерские последствия. Расходы на соответствие стандартам (инструменты SAQ, ASV-сканирования, оборудование для МФА, сервисы обнаружения взломов), комиссии платежных систем, которые зависят от вашего статуса комплаенса, а также любые штрафы или расходы на устранение последствий — всё это проходит через вашу бухгалтерию. То же касается влияния утечек данных на выручку: чарджбэки, возвраты, комиссии за перевыпуск карт, передаваемые вашим эквайером, и упущенные продажи во время реагирования на инцидент.

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

Держите ваши записи по комплаенсу готовыми к аудиту

Отвечаете ли вы на вопросы эквайера, андеррайтера киберстрахования или эксперта по расследованию инцидентов — те мерчанты, чьи книги и отчеты рассказывают ясную историю, проходят через события PCI успешнее других. Beancount.io предлагает текстовый учет с контролем версий, который дает вам прозрачный след с временными метками для каждой комиссии за обработку платежей, инструмента безопасности и расхода на комплаенс — без «черных ящиков», без привязки к вендору и в готовности к эпохе финансов с поддержкой ИИ. Начните бесплатно и совместите работу по комплаенсу с бухгалтерским учетом, который выдержит любую проверку.