Коротко
• Сначала подтвердите, что организация вообще вправе использовать самооценку и какой документ принимает эквайер или платёжная система.
• SAQ A возможен только при полном выполнении критериев анкеты; iframe или redirect сами по себе этого не доказывают.
• SAQ A-EP относится к электронной коммерции, где сайт не получает данные карт, но влияет на безопасность транзакции; фактические критерии нужно проверять по актуальной анкете.
• Если среда не соответствует критериям более узкого SAQ, для продавца обычно остаётся SAQ D; для SAQ-eligible service provider доступен только SAQ D for Service Providers.
Короткий ответ и пределы этого дерева
SAQ выбирают не по желанию команды, а по типу организации, платёжным каналам, архитектуре и полному набору критериев применимости. Перед самостоятельной оценкой PCI SSC рекомендует уточнить у эквайера, платёжной системы или другой принимающей стороны, может ли организация использовать SAQ и какой именно.
Эта статья сравнивает наиболее частые e-commerce варианты A, A-EP и D для продавца. Она не заменяет инструкции конкретной анкеты и не определяет merchant level, обязанность проходить QSA assessment или допустимость SAQ для конкретного договора.
Правило остановки
Если архитектура не подтверждена или хотя бы один критерий выбранного SAQ не выполняется, не продолжайте заполнять анкету как будто она подходит. Зафиксируйте пробел и согласуйте другой путь валидации.
SAQ A, A-EP и D в одной таблице
Таблица нужна для первичной классификации. Окончательное решение принимается только после проверки всех eligibility criteria в актуальном документе PCI SSC.
| Анкета | Типичный кандидат | Главный вопрос перед выбором |
|---|---|---|
| SAQ A | Card-not-present продавец, который полностью передал функции с данными карт PCI DSS-совместимым TPSP и не хранит, не обрабатывает и не передаёт электронные account data в своей среде. | Выполнены ли все критерии для фактического iframe или redirect, включая требования к сайту продавца, TPSP, бумажным данным и применимому ASV-сканированию? |
| SAQ A-EP | E-commerce продавец, который передал обработку данных карт, но его сайт или системы могут влиять на безопасность платёжной транзакции и не подходят под более узкий SAQ A. | Действительно ли данные карт не поступают в среду продавца и соответствует ли архитектура каждому критерию A-EP? |
| SAQ D for Merchants | Продавец, который не соответствует критериям других SAQ, имеет более широкую или смешанную среду либо сам хранит, обрабатывает или передаёт account data. | Полностью ли определена область и не требуется ли принимающей стороне ROC или оценка QSA вместо самостоятельной анкеты? |
| SAQ D for Service Providers | Поставщик услуг, которому разрешено подтверждать соответствие через SAQ. | Подтвердила ли принимающая сторона право на самооценку? Для SAQ-eligible service provider это единственный тип SAQ. |
Дерево решения для e-commerce
Пройдите вопросы последовательно и сохраняйте не только ответ, но и ссылку на схему или договор, который его подтверждает. Нельзя компенсировать отрицательный критерий тем, что риск кажется низким.
- 1. Организация — продавец или service provider, и разрешена ли ей самооценка принимающей стороной?
- 2. Есть ли электронное хранение, обработка или передача account data в системах продавца?
- 3. Кто создаёт каждый элемент платёжной формы и куда браузер отправляет данные?
- 4. Может ли сайт, скрипт, tag manager, сервер или администратор продавца изменить безопасность транзакции?
- 5. Выполняются ли все критерии актуального SAQ A? Если нет, проверьте A-EP; если не выполняется и он, рассматривайте D.
- 6. Есть ли смешанные каналы: e-commerce, MOTO, call center, бумажные записи, POS или другие процессы, которые меняют область?
- 7. Подтверждены ли итоговый документ и период оценки эквайером, платёжной системой, заказчиком или QSA?
Какие технические факты нужны вместо слов «у нас iframe»
Термин из коммерческого описания интеграции недостаточен. Для embedded fields, iframe, redirect и Direct Post зафиксируйте происхождение элементов формы, endpoint отправки, код продавца вокруг формы, возможность подмены перехода, сторонние скрипты, административные пути и системы, которые публикуют страницу.
Для TPSP соберите актуальный AOC, список покрываемых услуг, матрицу ответственности и инструкцию интеграции. AOC поставщика не подтверждает, что собственная реализация продавца выполнена правильно или что все обязанности переданы.
- Разбор iframe и redirect: Защита платёжной страницы после PCI DSS 4.0.1: SAQ A, iframe и доказательства
- Почему iframe не снимает весь клиентский риск: Почему встроенная форма оплаты не всегда снимает риск на стороне клиента
Пример: один магазин, три разных вывода
Вариант 1: магазин перенаправляет клиента на страницу процессора, не получает данные карт, выполняет критерии анкеты и имеет подтверждённую принимающей стороной модель. SAQ A может быть кандидатом, но остаются требования к сайту, поставщику, ASV и другим каналам.
Вариант 2: платёжная форма встроена, а скрипты продавца, tag manager и приложение могут влиять на страницу. SAQ A не следует объявлять автоматически: нужно подтвердить критерий защиты от скриптовых атак и остальные условия. При невыполнении критериев проверяется A-EP или более широкий путь.
Вариант 3: сервер продавца принимает данные формы или сохраняет account data. Узкие e-commerce анкеты A и A-EP обычно не соответствуют такой архитектуре; область и способ подтверждения нужно строить по более широкому набору требований.
Запись решения, которую можно проверить через полгода
Хорошее решение содержит дату, версию анкеты, тип организации, принимающую сторону, каналы оплаты, диаграмму потока, ответы по каждому критерию, TPSP, AOC, исключения, владельца и срок пересмотра. Пересматривайте его после смены процессора, формы, домена оплаты, tag manager, CDN, checkout-кода или договорной модели.
CSV ниже помогает собрать решение без данных карт и других секретов. Строки в файле — примеры; замените их фактами своей среды и приложите ссылки на защищённое хранилище доказательств.
Журнал выбора SAQ для e-commerce
CSV для архитектурных фактов, критериев, доказательств, принимающей стороны, владельца и пересмотра.
CSV · пример без платёжных данных
Пять ошибок, которые делают вывод недостоверным
Большинство ошибок возникает не при заполнении ответов, а раньше — когда команда подгоняет архитектуру под желаемую анкету. Отдельно проверьте следующие ситуации.
- Выбор SAQ A только потому, что на странице есть iframe.
- Выбор анкеты по объёму транзакций без проверки архитектуры и правил принимающей стороны.
- Игнорирование tag manager, CMS, CI/CD, CDN и административных систем, способных изменить страницу.
- Использование AOC поставщика как доказательства соответствия собственной интеграции.
- Копирование прошлогоднего решения после изменения checkout или условий TPSP.
Что делать после выбора анкеты
Сопоставьте каждое применимое требование с владельцем, контролем, системой, тестом и доказательством. Затем проведите gap analysis и проверьте контроль на реальной выборке. Сам заполненный PDF не доказывает, что контроль работал весь заявленный период.
Для e-commerce отдельно проверьте ASV-сканирование, управление TPSP, уязвимости публичного приложения, защиту от скриптовых атак, состояние скриптов и обнаружение изменений там, где это применимо к выбранной архитектуре.
- Полный обзор PCI DSS 4.0.1: PCI DSS 4.0.1: 12 требований и план подготовки
- Карта доказательств: Карта доказательств PCI DSS
Практический порядок действий
1
Подтвердить тип организации и право на самооценку у принимающей стороны.
2
Нарисовать фактический поток данных и происхождение элементов платёжной формы.
3
Определить системы продавца и TPSP, способные влиять на безопасность транзакции.
4
Проверить каждый критерий актуальных SAQ A и A-EP без исключений.
5
Зафиксировать выбор или переход к SAQ D с доказательствами и владельцем.
6
Получить подтверждение выбранного пути и назначить дату пересмотра.
Вопросы по теме
SAQ A всегда подходит магазину с redirect?
Нет. Redirect является только одним архитектурным фактом. Нужно выполнить все критерии актуальной анкеты и подтвердить выбранный способ с принимающей стороной.
Чем SAQ A-EP отличается от SAQ A?
Оба варианта относятся к card-not-present e-commerce архитектурам с переданной обработкой платежей, но A-EP охватывает среду продавца, которая может влиять на безопасность транзакции и не соответствует более узким критериям A. Решение принимается только по полным официальным критериям.
Можно ли отметить невыполненный критерий SAQ как N/A?
Нет, если речь о критерии применимости самой анкеты. N/A для отдельного требования требует обоснования внутри подходящего SAQ, но не делает неподходящую анкету допустимой.
Service provider может выбрать SAQ A или A-EP?
Нет. PCI SSC указывает, что для service provider, которому разрешена самооценка, единственным SAQ является SAQ D for Service Providers.