Материалы
Чек-лист PCI DSS 6.4.3 и 11.6.1 для платёжной страницы
Рабочий чек-лист связывает область применимости платёжных страниц, управление скриптами, контроль целостности и изменений, реагирование, владельцев и сохраняемые доказательства до внутренней проверки или QSA-аудита.
Для владельцев PCI DSS, ИБ и разработки, внутреннего аудита и аудиторов, проверяющих фактическую работу контролей платёжной страницы.
Что охватывает чек-лист
Область применимости и владельцы платёжных сценариев.
Инвентарь, авторизация, обоснование и целостность скриптов.
Утверждённый эталон, обнаружение изменений, оповещение и реакция.
Хранение доказательств, пересмотр, RACI и трассируемость для аудитора.
Обновлено: 27 июля 2026 г.
Основа проверки
Материал сверён с PCI DSS v4.0.1, актуальным руководством PCI SSC для электронной коммерции, изменениями SAQ A и связанными FAQ. Ведомость помогает планированию, но применимость и достаточность определяются при оценке среды.
Определённая область
Перечислены платёжные сценарии, варианты страниц, провайдеры, менеджер тегов и ответственные команды.
Работающий контроль
Инвентарь и мониторинг связаны с согласованиями, релизами, первичным разбором и периодическим пересмотром.
Пакет доказательств
Артефакты подтверждают и дизайн контроля, и его фактическую работу в проверяемом периоде.
1. Подтвердите область применимости до выбора контролей
Задокументируйте каждый платёжный сценарий, в котором страница продавца может влиять на то, что видит пользователь или как вводятся платёжные данные. Учтите перенаправление, встроенную форму, hosted fields и многошаговые схемы, локали, мобильные варианты, состояния согласия, менеджер тегов, CDN и зависимости от платёжного провайдера.
Зафиксируйте решение об области применимости и подтверждающие его материалы. Чек-лист не определяет применимость автоматически: организация и аудитор проверяют вывод по реальной архитектуре и способу валидации.
- Назначенный владелец каждого платёжного сценария и страницы в рабочей среде.
- Архитектурная схема с границами продавца, провайдера, третьих сторон и браузера.
- Задокументированный путь SAQ/ROC и согласованные с аудитором предположения об области применимости.
2. Подтвердите путь валидации и распределение ответственности
Не исходите из того, что у всех e-commerce-архитектур одинаковая отчётность. PCI SSC исключил требования 6.4.3 и 11.6.1 из SAQ A и добавил критерий применимости: организация должна подтвердить, что сайт не подвержен атакам через скрипты, способным повлиять на систему электронной коммерции.
Для встроенной формы сохраните подтверждение провайдера и условия корректного внедрения, если выбран этот подход, либо задокументируйте собственные или сторонние методы защиты страницы. Серверное перенаправление может приводить к другому выводу о применимости, если скрипты не влияют на редирект, но этот вывод проверяет и документирует аудитор.
- Назовите организацию, управляющую программой соответствия: аудитора, эквайера или платёжную систему.
- Опишите границы контроля продавца и провайдера и сторону, предоставляющую каждый артефакт.
- Храните инструкции провайдера, подтверждение, настройки внедрения и уведомления об изменениях вместе с решением об области.
3. Сформируйте реестр контроля скриптов по 6.4.3
Для каждого скрипта в области проверки зафиксируйте наблюдаемый источник, бизнес-назначение, владельца, авторизацию, обоснование и способ контроля целостности или подлинности. Сверяйте утверждённый реестр с фактической страницей после релизов и существенных изменений третьих сторон.
- Собственные пакеты приложения, сторонние SDK, правила менеджера тегов, виджеты и динамические загрузчики.
- Доказательство согласования, обработка исключений, дата проверки и решение по устаревшим записям.
- Технический способ: SRI, подписи, поддержка CSP, контролируемая доставка или мониторинг изменений.
4. Эксплуатируйте обнаружение и реагирование по 11.6.1
Определите утверждённый эталон каждого значимого состояния платёжной страницы и отслеживайте существенные изменения контента, скриптов, источников ресурсов и важных заголовков. Опишите, как штатные релизы обновляют эталон и как необъяснимые отклонения попадают в первичный разбор.
Одного оповещения недостаточно. Рабочая запись показывает получателя события, выполненную проверку, решение, действие по согласованию или сдерживанию и время закрытия. Сохраняйте доказательства работы не реже одного раза в семь дней либо с периодичностью, определённой применимым целевым анализом рисков.
5. Проверьте работу до установки статуса «выполнено»
Политика, настроенная панель или заполненная ведомость не подтверждают операционную эффективность. Проведите согласованный релиз, необъяснимое изменение скрипта или заголовка, проверку нормализации динамического значения, отказ наблюдения и извлечение выборки.
Для теста сохраните входное условие, ожидаемый и фактический результат, владельца, решение, исправление, повторную проверку и ссылку на доказательство. Неудачный тест остаётся открытым до исправления контроля или области.
6. Храните доказательства и проверяйте здоровье контроля
Согласуйте период проверки и сроки хранения с владельцем соответствия, ИБ, юристами и аудитором. Артефакты должны находиться по странице, скрипту, событию, владельцу, требованию и дате, чтобы выборку можно было воспроизвести без восстановления истории перед аудитом.
Периодически проверяйте, отвечают ли владельцы, актуален ли инвентарь, не скрывают ли правила эталона существенные изменения и достаточно ли контекста в экспорте для независимого проверяющего.
Содержание
Заполните одну контрольную ведомость на платёжный сценарий
Ведомость превращает общие требования в поля владельца, статуса, доказательства, проверяющего, срока и исключения. Заполняйте её совместно с владельцами приложения, ИБ, соответствия и провайдера, а не назначайте все строки одному специалисту PCI.
Критерий готовности
Для сценария задокументированы путь валидации, владельцы, проверенные контроли скриптов и изменений, протестированная реакция, доступные доказательства и явно обозначенные пробелы со сроками.
01
Опишите реальный платёжный путь
Зафиксируйте редирект или встроенную форму, границы продавца и провайдера, варианты страниц, состояния браузера и всех участников, способных изменить результат.
02
Запишите решение о применимости
Свяжите путь SAQ или ROC, подтверждение провайдера, обсуждение с аудитором и причину выбранного способа выполнения требования или критерия.
03
Приложите исходную запись к каждому статусу
Статус без заявки, экспорта, конфигурации, теста или согласованного решения остаётся планом, а не доказательством.
04
Проведите положительные и отрицательные тесты
Проверьте штатное и неожиданное изменение, нормализацию, маршрутизацию, обработку отказа и извлечение доказательств.
05
Закройте пробелы владельцев и сроков
Назначьте открытые строки, исключения, повторные тесты и периодические проверки конкретным ролям со сроком и эскалацией.
Переносимый чек-лист PCI DSS 6.4.3 / 11.6.1
PDF для рабочих встреч, обсуждения контролей и подготовки к проверке.
PDF · переносимая копия для проверки
Контрольная ведомость внедрения
Редактируемый CSV с областью, инвентарём, авторизацией, целостностью, эталоном, периодичностью, реакцией, доказательствами и управлением.
CSV · UTF-8 · для внутреннего реестра контролей
Заполненный шаблон не доказывает соответствие. Храните вместе с ним авторитетные публикации PCI SSC и выводы аудитора по конкретной среде.
Рекомендуемый порядок внедрения
Такой порядок снижает риск настройки мониторинга на неопределённое или неавторизованное состояние страницы.
01
Область
Карта сценариев, вариантов, зависимостей, владельцев и предположений валидации.
02
Инвентарь
Наблюдение скриптов и сверка с утверждённым реестром.
03
Авторизация
Назначение, владелец, согласование и способ контроля целостности.
04
Мониторинг
Утверждение эталона и сравнение значимых изменений в браузере.
05
Реакция и хранение
Маршрутизация событий, решения и сохранение доказательств.
Чек-лист контролей и доказательств
Используйте таблицу как рабочий индекс. Во внутреннем реестре добавьте владельца, систему учёта, статус, проверяющего и срок.
| # | Область | Что проверить | Пример доказательства | Основной владелец |
|---|---|---|---|---|
| 01 | Область | Все сценарии и варианты описаны | Архитектура, URL, решение об области применимости | Владелец PCI / архитектура |
| 02 | Инвентарь | Наблюдаемые скрипты совпадают с реестром | Экспорт, источник, первое и последнее наблюдение | AppSec / владелец приложения |
| 03 | Авторизация | Есть согласование и бизнес-обоснование | Заявка, владелец, дата, исключение | Бизнес- и технический владелец |
| 04 | Целостность | Выбран подходящий способ контроля | SRI/подпись, CSP, правило мониторинга | Разработка / AppSec |
| 05 | Эталон | Ожидаемые состояния описаны и согласованы | Снимок, релиз, владелец, согласование | Владелец приложения |
| 06 | Обнаружение | Значимые изменения создают события | Различия, время, страница и источник | Операционная ИБ |
| 07 | Периодичность и пробелы | Запуски соответствуют требуемой или риск-ориентированной частоте | История запусков, ошибки, повторы и решения по пробелам | Владелец контроля / эксплуатация платформы |
| 08 | Реагирование | События назначаются и закрываются | Оповещение, первичный разбор, действие, закрытие | SOC / реагирование на инциденты |
| 09 | Хранение | Артефакты доступны согласованный срок | Экспорт, настройка хранения, тест выборки | Владелец соответствия / владелец платформы |
| 10 | RACI | Роли контроля и эскалации приняты | RACI, процедура, контакты, тест | Владелец контроля |
| 11 | Тестирование контроля | Штатные, неожиданные и отказные сценарии пройдены | План тестов, результаты, исправление и повтор | Владелец контроля / внутренний аудит |
Материал является руководством по внедрению и не заменяет PCI DSS, решение аудитора и проверки конкретной среды.
Разделяйте официальное требование и рекомендации по внедрению
Авторитетным источником являются публикации PCI SSC. Чек-лист Cartelta систематизирует практические действия и примеры артефактов, но не добавляет требований, не гарантирует соответствие и не заменяет оценку QSA.
Вопросы по чек-листу
HTML-страница является обновляемой основной версией и связана с практическими руководствами. PDF — переносимый рабочий формат для встреч и внутреннего планирования.
Нет. Чек-лист помогает подготовиться и организовать доказательства. Применимость, эффективность контролей, выборка и итоговый вывод зависят от среды, метода валидации и проверки аудитора.
Требования 6.4.3 и 11.6.1 исключены из SAQ A, но текущий критерий применимости требует подтвердить, что сайт не подвержен атакам через скрипты, способным повлиять на e-commerce-систему. Выбранный способ защиты или подтверждение провайдера нужно задокументировать и проверить с владельцем программы соответствия.
Ненаблюдавшиеся состояния, неизвестные скрипты, отсутствующее подтверждение провайдера, непротестированная маршрутизация, сбои мониторинга, незакрытые исключения и недоступные независимому проверяющему доказательства должны оставаться открытыми с владельцем и сроком.
Первичные источники PCI SSC
Использовать чек-лист вместе с руководствами
Превратите чек-лист в работающий контроль
Начните с одного реального платёжного сценария, проверьте создаваемые доказательства и закройте пробелы в ответственности до расширения области.
Обсудить область внедрения