Коротко
• PCI DSS 4.0.1 не добавил и не удалил требования: это уточняющая редакция, которая стала единственной активной версией после 31 декабря 2024 года.
• Подготовка начинается с потоков данных и области применения, а не с заполнения анкеты.
• SAQ выбирают по архитектуре обработки платежей и критериям применимости, а не только по объёму транзакций.
• Cartelta закрывает узкую техническую часть защиты платёжных страниц; продукт и консультационный трек не заменяют полную оценку PCI DSS или решение QSA.
Короткий ответ: что такое PCI DSS 4.0.1 и какая версия действует
PCI DSS устанавливает базовые технические и организационные требования для организаций, которые хранят, обрабатывают или передают данные платёжных карт либо могут влиять на безопасность соответствующей среды. Версия 4.0.1 опубликована PCI SSC как ограниченная редакция: в ней исправлены ошибки и уточнены формулировки, но нет новых или удалённых требований.
PCI DSS v4.0 был выведен из обращения 31 декабря 2024 года. Отложенные требования сохранили дату вступления 31 марта 2025 года и сейчас должны оцениваться там, где применимы. Для проекта в 2026 году исходной точкой должна быть актуальная версия стандарта и актуальный документ SAQ, ROC или AOC из библиотеки PCI SSC.
Важно
Эта статья помогает организовать подготовку, но не определяет обязательства конкретной организации. Способ подтверждения соответствия и выбранную анкету нужно согласовать с эквайером, платёжной системой, заказчиком или QSA.
Кому применяется PCI DSS и как определить границы
Сначала нарисуйте поток данных: где пользователь вводит реквизиты, кто формирует платёжную форму, куда уходят данные, какие системы хранят или передают их и какие компоненты могут изменить безопасность этого пути. В область оценки могут входить не только серверы с данными карт, но и связанные системы, административный доступ, сетевые сегменты, поставщики услуг и страницы электронной коммерции.
Снижение области применения через перенаправление, iframe, токенизацию, сегментацию или P2PE может уменьшить объём проверки, но не является автоматическим исключением. Для каждого решения сохраните схему, основание, владельца, границы ответственности TPSP и подтверждение того, что архитектура соответствует заявленным критериям.
- Активы: приложения, сети, облачные сервисы, endpoints, CI/CD и административные пути, которые хранят, обрабатывают, передают данные или влияют на CDE.
- Поставщики: платёжный процессор, хостинг, CDN, WAF, сервисные аккаунты и другие TPSP с распределённой ответственностью.
- Люди и процессы: доступ, изменения, инциденты, обучение, управление рисками и периодические проверки.
- E-commerce: страница продавца, iframe или redirect, tag manager, сторонние скрипты и системы, способные изменить платёжный путь.
Все 12 требований PCI DSS: рабочая карта
Двенадцать групп работают как единая система. Нельзя закрыть соответствие только сканированием, политиками или защитой платёжной страницы. Таблица ниже переводит официальные названия в рабочий вопрос для владельца программы; конкретные процедуры тестирования нужно брать из действующего документа PCI DSS 4.0.1.
| № | Область | Что должно быть управляемым |
|---|---|---|
| 1 | Сетевые средства защиты | Правила потоков, конфигурации, изменения и проверка сетевых границ. |
| 2 | Безопасные конфигурации | Стандарты настройки, учёт компонентов, отключение небезопасных значений и сервисов. |
| 3 | Защита хранимых данных учётных записей | Минимизация хранения, шифрование или иная защита PAN, ключи и сроки удаления. |
| 4 | Защита данных при передаче | Сильная криптография, доверенные сертификаты и запрет небезопасной передачи PAN. |
| 5 | Защита от вредоносного ПО | Профилактика, обнаружение, обновления, анализ систем без типичного антивируса и защита от фишинга. |
| 6 | Безопасные системы и ПО | Уязвимости, патчи, безопасная разработка, изменения, web-защита и скрипты платёжных страниц. |
| 7 | Доступ по служебной необходимости | Роли, минимальные привилегии, регулярный пересмотр и управление системными аккаунтами. |
| 8 | Идентификация и аутентификация | Уникальные учётные записи, MFA, факторы аутентификации, жизненный цикл пользователей и приложений. |
| 9 | Физический доступ | Зоны, посетители, носители, устройства и физическая защита данных. |
| 10 | Журналирование и мониторинг | Полные журналы, синхронизация времени, защита логов, разбор событий и обнаружение сбоев. |
| 11 | Регулярное тестирование | Сканирование, penetration testing, сегментация, обнаружение атак и изменений платёжной страницы. |
| 12 | Политики и программа ИБ | Ответственность, риски, TPSP, обучение, инциденты, ежегодные подтверждения и управление программой. |
Что изменилось между PCI DSS 4.0 и 4.0.1
Обновление не создаёт новый набор обязанностей. Оно уточняет формулировки и применимость, поэтому проект миграции должен проверять не только номера требований, но и изменённые примечания, guidance и шаблоны отчётности.
| Раздел | Уточнение v4.0.1 | Практическое действие |
|---|---|---|
| Требование 3 | Уточнена применимость для эмитентов и keyed cryptographic hashes. | Проверить основание защиты PAN и применимость к issuing-сервисам. |
| Требование 6 | 30-дневный срок возвращён только для критических уязвимостей; добавлены пояснения по скриптам платёжной страницы. | Обновить SLA патчей и трактовку 6.4.3 для фактической архитектуры. |
| Требование 8 | Уточнено исключение MFA для доступа, использующего только phishing-resistant факторы. | Проверить метод аутентификации и документировать основание исключения. |
| Требование 12 | Уточнены отношения и ответственность между заказчиком и TPSP. | Сверить матрицу ответственности, AOC поставщиков и мониторинг их статуса. |
| Приложения | Шаблоны customized approach вынесены на сайт; добавлены определения. | Использовать актуальные внешние шаблоны и глоссарий PCI SSC. |
SAQ, ROC и AOC: какой путь подтверждения выбрать
SAQ — не облегчённая версия стандарта, а способ самостоятельной оценки для среды, которая полностью соответствует критериям конкретной анкеты. ROC — подробный отчёт об оценке; требования к его проведению зависят от правил платёжных систем и принимающей стороны. AOC подтверждает результат соответствующей оценки.
Для e-commerce сначала классифицируйте архитектуру, а затем проверьте все критерии выбранной анкеты. Если хотя бы один критерий SAQ A или A-EP не выполняется, нельзя просто оставить анкету и пометить неудобный критерий как неприменимый.
- Подробное дерево решения: SAQ A, A-EP или D: как выбрать анкету PCI DSS 4.0.1
- Разбор SAQ A, iframe и redirect: Защита платёжной страницы после PCI DSS 4.0.1: SAQ A, iframe и доказательства
Не выбирайте SAQ по числу транзакций
Уровни merchant/service provider и допустимый способ валидации задаются платёжными системами и принимающей стороной. Архитектура определяет критерии анкеты, а объём операций может влиять на требуемый формат подтверждения.
Что особенно важно для e-commerce в 2026 году
В браузере покупателя сходятся код продавца, платёжный компонент, tag manager, аналитика, consent manager, CDN и сторонние виджеты. Поэтому контроль только репозитория не показывает фактическую страницу, а наличие iframe само по себе не доказывает защиту окружения.
Требование 6.4.3 управляет авторизацией, целостностью и бизнес-обоснованием скриптов платёжной страницы. Требование 11.6.1 требует обнаруживать несанкционированные изменения страниц и значимых HTTP-заголовков с заданной периодичностью или через механизм, который непрерывно обнаруживает изменения.
- Контроль скриптов по 6.4.3: PCI DSS 6.4.3 — контроль клиентских скриптов на платёжной странице
- Мониторинг изменений по 11.6.1: PCI DSS 11.6.1 — мониторинг изменений платёжной страницы
- Практический чек-лист: Чек-лист внедрения PCI DSS
План подготовки на 30, 60 и 90 дней
Срок зависит от размера и состояния среды, но последовательность остаётся одинаковой: подтвердить границы, назначить владельцев, закрыть наиболее опасные пробелы, проверить работу контролей и только затем собирать финальный пакет. План ниже подходит как стартовый backlog, а не как обещание соответствия за 90 дней.
| Период | Основная задача | Проверяемый результат |
|---|---|---|
| Дни 1–30 | Потоки данных, CDE, TPSP, путь SAQ/ROC, владельцы, gap register и критические риски. | Утверждённая схема и реестр решений с ответственными и сроками. |
| Дни 31–60 | Конфигурации, доступ, патчи, журналы, сканирование, SDLC, клиентские скрипты и процедуры. | Работающие контроли и первые операционные записи, а не только проекты политик. |
| Дни 61–90 | Контрольные тесты, устранение пробелов, выборки доказательств, независимая проверка и готовность к оценке. | Воспроизводимый пакет с выводами, исключениями и остаточными задачами. |
Какие доказательства собирать и как использовать трекер
Для каждого применимого требования свяжите контроль с владельцем, системой, процедурой тестирования, периодом, исходным артефактом и результатом проверки. Скриншот без источника и контекста быстро устаревает; сильнее работают экспорт журнала, утверждённая конфигурация, ticket изменения, выборка доступа или событие, которое другой специалист может воспроизвести.
Ниже — стартовый CSV для управления готовностью. В нём нет данных конкретной среды и он не заменяет официальный reporting template. Добавьте свои requirement IDs, критерии, ссылки на evidence, владельцев, даты и решение проверяющего.
Трекер готовности PCI DSS 4.0.1
CSV с полями для требования, области, владельца, статуса, доказательства, теста, пробела и срока.
CSV · пример без чувствительных данных
Граница Cartelta: что продукт и консультационный трек реально закрывают
Cartelta специализируется на клиентской стороне платёжных страниц: наблюдаемом инвентаре скриптов, управлении ожидаемым состоянием, обнаружении изменений и подготовке технических артефактов по 6.4.3 и 11.6.1. Консультационный трек помогает разложить этот контур, владельцев, пробелы и план внедрения.
Cartelta не является заявлением о сертификации, не выпускает ROC или AOC и не закрывает остальные группы требований автоматически. Для полной программы нужны специалисты по сети, IAM, криптографии, SDLC, журналированию, уязвимостям, физической защите, рискам и управлению TPSP, а итоговый способ подтверждения согласуется с принимающей стороной.
- Техническая подготовка по платёжным страницам: /PCIDSSConsultingPage
- Возможности Cartelta JSIR: /JSIRPage
Практический порядок действий
1
Зафиксировать платёжные потоки, CDE, связанные системы и поставщиков услуг.
2
Согласовать допустимый путь SAQ, ROC и AOC с принимающей стороной.
3
Сопоставить все применимые требования с контролями, владельцами и системами.
4
Создать gap register и в первую очередь закрыть критические технические и процессные пробелы.
5
Проверить работу контролей на выборках и безопасных тестовых сценариях.
6
Собрать воспроизводимый пакет доказательств и провести независимую проверку до формальной оценки.
Вопросы по теме
PCI DSS 4.0.1 — это новая версия с новыми требованиями?
Нет. PCI SSC называет 4.0.1 ограниченной редакцией: она исправляет ошибки и уточняет формулировки без добавления или удаления требований.
Можно ли самостоятельно выбрать SAQ A?
Организация должна подтвердить выполнение всех критериев применимости конкретной анкеты. PCI SSC рекомендует согласовать право использовать SAQ и выбранный тип с эквайером, платёжной системой или другой принимающей стороной.
Iframe полностью выводит сайт продавца из области PCI DSS?
Нет. Он может сократить область обработки данных, но страница продавца и системы, способные изменить платёжный сценарий, всё равно требуют анализа. Для SAQ A действуют отдельные критерии защиты от скриптовых атак и требования ASV.
Можно ли закрыть PCI DSS одним продуктом?
Нет. Стандарт охватывает двенадцать групп технических и организационных контролей. Инструмент может поддерживать отдельные требования, но не заменяет область применения, процессы, тестирование и итоговую оценку.
Гарантирует ли 90-дневный план соответствие?
Нет. Это последовательность для управления работой. Реальный срок зависит от области, архитектуры, исходных пробелов, поставщиков и требуемого способа оценки.