Коротко
• С 31 марта 2025 года будущие требования PCI DSS 6.4.3 и 11.6.1 стали обязательными там, где они применимы.
• В SAQ A изменился способ валидации: для встроенной платёжной формы действует критерий защиты страницы продавца от скриптовых атак.
• Перенаправление и iframe по-разному трактуются в FAQ 1588, но FAQ 1604 относит ASV-сканирование SAQ A к обоим вариантам.
• Решение о применимости и достаточности доказательств нужно подтверждать с эквайером, платёжной системой или QSA для конкретной среды.
Решение за одну минуту: iframe, перенаправление или собственная форма
Сначала зафиксируйте фактическую архитектуру. При встроенном iframe или hosted fields страница продавца окружает платёжный компонент и может влиять на безопасность сценария. При перенаправлении пользователь уходит на страницу TPSP, но механизм перехода и сайт продавца всё равно требуют защиты. Если форма и клиентская логика создаются продавцом, область применимости обычно шире, чем SAQ A.
Не выбирайте контроль по названию интеграции. Проверьте, откуда приходят элементы формы, какие скрипты исполняются на странице продавца, кто управляет перенаправлением, какие системы могут изменить страницу и какой способ валидации подтвердил принимающий орган.
- Встроенная форма: подтвердить критерий SAQ A по защите страницы от скриптовых атак.
- Перенаправление: критерий FAQ 1588 для встроенной формы не применяется, но защита перехода и ASV-требования SAQ A остаются отдельными вопросами.
- Форма, созданная продавцом, или Direct Post: не предполагать применимость SAQ A без проверки архитектуры и критериев.
Что изменилось после 31 марта 2025 года
Требования 6.4.3 и 11.6.1 имели отложенный срок действия в PCI DSS v4.x и стали обязательными 31 марта 2025 года там, где они применимы. Они направлены на авторизацию и целостность скриптов платёжной страницы, а также на обнаружение несанкционированных изменений страниц и значимых HTTP-заголовков.
30 января 2025 года PCI SSC сообщил об изменении SAQ A: сами строки 6.4.3 и 11.6.1 и связанный целевой анализ рисков были удалены из анкеты, а в критериях применимости появился отдельный пункт о защите сайта от скриптовых атак. Это изменение способа валидации для SAQ A, а не заявление о том, что клиентский риск исчез.
Что именно разъясняет FAQ 1588 для встроенной платёжной формы
FAQ 1588 указывает, что критерий SAQ A о скриптовых атаках относится к продавцам, на странице которых встроена платёжная страница или форма TPSP, например iframe. Подтверждение возможно двумя путями: собственными или сторонними техниками защиты, подобными подходам 6.4.3 и 11.6.1, либо подтверждением PCI DSS-совместимого TPSP/процессора о том, что его решение при корректной интеграции защищает страницу продавца.
Подтверждение поставщика не нужно понимать как универсальный сертификат для любой интеграции. Команде требуется сохранить актуальную инструкцию TPSP, доказательство корректной реализации, границы ответственности, версию интеграции и согласованный вывод о применимости.
Почему перенаправление не означает отсутствие обязанностей
FAQ 1588 отделяет перенаправление от критерия защиты встроенной формы: если страница только переводит пользователя на TPSP, этот конкретный критерий не применяется. Но это не выводит сайт продавца из-под контроля. Компрометация механизма перенаправления способна отправить пользователя на поддельный платёжный ресурс.
Опубликованный в июне 2026 года FAQ 1604 отдельно подтвердил, что внешнее ASV-сканирование по включённым в SAQ A требованиям 11.3.2 и 11.3.2.1 распространяется и на страницы с перенаправлением, и на страницы со встроенным iframe. Это отдельный контроль уязвимостей, а не замена управлению скриптами и изменениями.
Какие доказательства подготовить для проверки
Начните с архитектурной схемы и решения об области применимости. Затем свяжите платёжные сценарии с реестром скриптов, владельцами, авторизацией, бизнес-обоснованием, способом контроля целостности, эталонным состоянием страницы, событиями изменений и процессом реагирования.
Для встроенной формы дополнительно сохраните подтверждение TPSP или собственную модель защиты. Для перенаправления — описание механизма, систем, способных его изменить, и результаты применимых ASV-сканирований. В обоих случаях доказательства должны относиться к реальной интеграции в рабочей среде и проверяемому периоду.
Практический план на ближайшие две недели
Зафиксируйте один приоритетный платёжный сценарий, подтвердите его архитектуру и способ валидации, запросите у TPSP актуальные инструкции и подтверждение ответственности, соберите фактически исполняемые скрипты и проверьте существующий процесс обнаружения изменений.
Завершите этап тестовой выборкой: одно ожидаемое изменение, одно необъяснимое отклонение и полный путь от наблюдения до решения и сохранённого артефакта. Такой результат показывает операционную готовность лучше, чем общий документ о намерениях.
Вопросы поставщику до закупки решения
Покупателю важно проверить не количество экранов в панели, а способность решения поддержать реальный контроль. Попросите показать один платёжный сценарий от наблюдения до закрытого события и отделить функции продукта от процессов, которые остаются у заказчика.
- Какие состояния страницы и динамические загрузчики решение действительно наблюдает?
- Какие данные собираются, какие исключаются и как это можно проверить технически?
- Как версия эталона связывается с релизом, владельцем и согласованием?
- Что произойдёт при неизвестном источнике: кто получает событие и какие данные доступны для решения?
- Можно ли выгрузить воспроизводимую выборку с устойчивыми идентификаторами, временем и историей решения?
- Какие обязанности по области применимости, авторизации и реагированию остаются у заказчика?
Как оформить решение для руководства
Итогом оценки должен быть не вывод «инструмент понравился», а документированное решение: архитектура оплаты, способ подтверждения соответствия, текущие пробелы, выбранные контроли, владельцы, стоимость внедрения и остаточный риск. Для каждого пробела укажите доказательство закрытия и дату повторной проверки.
Cartelta можно оценивать на одной реальной выборке: фактический инвентарь, утверждённое состояние, два контролируемых изменения, маршрут события и экспорт для независимой проверки. Такой критерий помогает сравнивать поставщиков по результату, а не по обещаниям.
Практический порядок действий
1
Определите фактический тип интеграции: встроенная форма, перенаправление или сценарий, созданный продавцом.
2
Подтвердите путь SAQ/ROC и применимость требований с органом, принимающим подтверждение соответствия.
3
Соберите область применимости, скрипты, владельцев, эталонное состояние и существующие защитные механизмы.
4
Получите и проверьте подтверждения TPSP и результаты применимого ASV-сканирования.
5
Проведите контролируемое изменение и сохраните полную цепочку доказательств.
Вопросы по теме
Удаление 6.4.3 и 11.6.1 из SAQ A отменило эти требования?
Нет. Изменилась анкета и способ валидации для соответствующих сред SAQ A. Применимость требований и достаточность альтернативного подтверждения зависят от архитектуры, критериев и решения органа, принимающего подтверждение соответствия.
Для перенаправления больше не нужна защита страницы продавца?
Нет. FAQ 1588 исключает перенаправление только из конкретного критерия для встроенной формы. Механизм перехода и системы, влияющие на него, всё равно нуждаются в защите; FAQ 1604 также подтверждает применимость ASV-сканирования SAQ A.
Подтверждение TPSP автоматически закрывает вопрос для iframe?
Требуется проверить, что поставщик соответствует PCI DSS, подтверждение относится к конкретному решению, а интеграция выполнена по его инструкциям. Итоговый способ валидации согласуется с эквайером, платёжной системой или QSA.