Коротко
• PCI DSS 4.0.1 усиливает практическую работу с платежными страницами и клиентской стороной.
• Для e-commerce важны требования 6.4.3 и 11.6.1, а также доказательства для QSA.
• Главная задача бизнеса — не переписать всё сразу, а быстро обновить контуры, владельцев и доказательства.
Что такое PCI DSS 4.0.1
PCI DSS 4.0.1 — уточняющий релиз к PCI DSS 4.0. Он проясняет формулировки, примечания, сроки и ожидания к доказательствам, но не заменяет логику стандарта новым набором требований.
Для онлайн-бизнеса важнее всего не номер версии, а практический вывод: аудит всё сильнее смотрит на то, как компания управляет платежными страницами, скриптами и изменениями в браузере клиента.
Что изменилось для клиентской стороны
В e-commerce фокус сместился к client-side security. Командам нужно понимать, какие скрипты исполняются на странице оплаты, кто их разрешил, зачем они нужны бизнесу и как отслеживаются изменения.
Даже если карточные данные вводятся через встроенную форму провайдера, сайт продавца остаётся частью пользовательского сценария. Поэтому важно контролировать не только серверный код, но и фактическую страницу, которую получает браузер клиента.
- 6.4.3 требует управлять скриптами платежной страницы: инвентарь, разрешение, бизнес-обоснование и контроль целостности.
- 11.6.1 требует обнаруживать несанкционированные изменения страницы и важных HTTP-заголовков.
- Для аудита нужны воспроизводимые артефакты: реестры, события, владельцы, история изменений и процедура реакции.
Какие процессы нужно обновить
PCI DSS 4.0.1 делает видимыми слабые места, которые раньше часто оставались между командами: маркетинговые теги, менеджеры согласий, сторонние виджеты, CDN, tag manager и платежный провайдер.
Практически это означает ревизию процесса добавления скриптов, назначение владельцев, описание регулярного пересмотра и связку мониторинга с каналом реагирования.
Как подготовиться без тяжёлого проекта
Начинать лучше с узкого контура: одна платежная страница или один checkout-сценарий. На нём можно быстро собрать живой инвентарь скриптов, базовое состояние DOM и заголовков, список владельцев и первый пакет доказательств.
После этого проще масштабировать процесс на остальные страницы: команда уже показывает не абстрактный риск, а конкретные скрипты, изменения и пробелы в операционной модели.
Что читать дальше
Для практической реализации стоит отдельно разобрать контроль скриптов по 6.4.3 и мониторинг изменений по 11.6.1. Эти темы связаны, но не дублируют друг друга: первая отвечает за управляемость исполняемого кода, вторая — за обнаружение отклонений на фактической странице.