Требования стандарта PCI DSS касаются любой компании, которая принимает, обрабатывает или хранит данные платёжных карт. Для контакт-центра это одна из самых неудобных зон: клиент диктует номер карты оператору, разговор пишется в архив, реквизиты попадают в заметки и CRM. Каждое такое место превращает КЦ в часть защищаемого периметра. Ниже — что именно требует стандарт, где у колл-центра типичные уязвимости и как сузить область проверки, не отказываясь от приёма оплаты по телефону.
Что такое PCI DSS и кого касается стандарт
PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платёжных карт. Его разрабатывает совет PCI SSC, созданный международными платёжными системами. Актуальная линейка — версия 4.0: она заменила 3.2.1, которая перестала действовать 31 марта 2024 года, а требования с отложенным сроком стали обязательными с 31 марта 2025 года.
В российском контексте стандарт остаётся обязательным для компаний, которые работают с картами международных платёжных систем, и часто закладывается в договоры с банками-эквайерами. Финансовые организации дополнительно выполняют ГОСТ Р 57580 и требования Банка России, а участники платёжной системы «Мир» — правила НСПК. Даже там, где соответствие PCI DSS формально не требуют, стандарт используют как проверенный каркас защиты платёжных данных.
Какие данные защищает PCI DSS
- Данные держателя карты: номер карты (PAN), имя держателя, срок действия. Их можно хранить только в защищённом виде и только при обоснованной необходимости.
- Чувствительные аутентификационные данные: CVV2/CVC2, PIN, полные данные магнитной полосы или чипа. После авторизации платежа их запрещено хранить в любом виде, даже в зашифрованном.
Второй пункт — главная ловушка для колл-центра. Если клиент продиктовал код CVV, а разговор записан, в архиве оказались данные, которые хранить нельзя. Формально это нарушение, даже если к записи никто не обращался.
12 требований PCI DSS
Требования сгруппированы в шесть целей. В формулировках версии 4.0 они выглядят так:
- Устанавливать и поддерживать средства сетевой безопасности.
- Применять безопасные конфигурации ко всем компонентам системы.
- Защищать хранимые данные учётных записей.
- Шифровать данные держателей карт при передаче по открытым сетям.
- Защищать системы и сети от вредоносного ПО.
- Разрабатывать и поддерживать безопасные системы и ПО.
- Ограничивать доступ к данным карт по принципу служебной необходимости.
- Идентифицировать пользователей и аутентифицировать доступ к системам.
- Ограничивать физический доступ к данным карт.
- Протоколировать и отслеживать любой доступ к системам и данным карт.
- Регулярно тестировать безопасность систем и сетей.
- Поддерживать информационную безопасность организационными политиками.
Где контакт-центр нарушает требования чаще всего
- Запись разговоров. Реквизиты карты оседают в аудиоархиве, к которому имеют доступ супервизоры, группа качества, ИТ.
- Экран и заметки оператора. Номер карты вписывают в поле комментария CRM «чтобы не забыть» — и он хранится годами.
- Текстовые каналы. Клиент присылает фото карты в мессенджер или чат на сайте.
- Удалённые операторы. Домашняя сеть, посторонние рядом, личный телефон в руках — физический контроль практически отсутствует.
- Прослушка для контроля качества. Эталонные и проблемные звонки пересылают по почте и выгружают в общие папки.
Как сузить область PCI DSS в колл-центре
Самая эффективная стратегия — сделать так, чтобы данные карты вообще не проходили через контакт-центр. Чем меньше систем «видят» реквизиты, тем меньше периметр аудита и дешевле соответствие.
Ссылка на оплату
Оператор отправляет клиенту SMS или сообщение в мессенджер со ссылкой на платёжную страницу провайдера. Реквизиты вводятся на стороне платёжного сервиса, КЦ получает только статус «оплачено». Самый простой способ вывести колл-центр из зоны обработки карт.
Перевод в платёжный IVR
На этапе оплаты звонок уходит в автоматический сценарий, клиент вводит цифры с клавиатуры телефона, данные передаются платёжному провайдеру. После оплаты клиент возвращается к оператору.
Маскирование тонов DTMF
Клиент остаётся на линии с оператором и вводит номер с клавиатуры, но тоны подавляются: оператор слышит ровный сигнал, в запись цифры не попадают.
Пауза записи
Запись останавливается на время диктовки реквизитов. Ручная пауза по кнопке зависит от дисциплины оператора, поэтому надёжнее автоматическая — по переходу к шагу оплаты в скрипте.
Чек-лист соответствия PCI DSS для контакт-центра
- Нарисуйте карту потоков данных. Откуда реквизиты приходят, через какие системы проходят, где могут осесть.
- Выберите способ приёма оплаты. Ссылка, платёжный IVR или маскирование — вместо диктовки оператору.
- Сегментируйте сеть. Системы, работающие с картами, отделяются от остальной инфраструктуры КЦ.
- Настройте доступ. Ролевая модель, персональные учётные записи, многофакторная аутентификация для доступа к среде с данными карт.
- Включите протоколирование. Кто, когда и к чему обращался — с хранением журналов и регулярным просмотром.
- Почистите архивы. Найдите старые записи и заметки с реквизитами и удалите их по регламенту.
- Обучите операторов. Что делать, если клиент всё-таки начал диктовать номер или прислал фото карты.
- Проходите оценку. Крупные торговые точки — ежегодный аудит у аккредитованного аудитора (QSA), небольшие — анкету самооценки SAQ. Пороги задают платёжные системы.
PCI DSS и MightyCall
Соответствие PCI DSS — свойство процессов компании, а не отдельной программы. Задача платформы контакт-центра — не мешать, а помогать строить правильную схему. MightyCall устанавливается on-premise, поэтому записи разговоров и журналы остаются в контуре компании и попадают под её собственные политики сегментации и доступа.
Типовой сценарий для колл-центра с приёмом платежей выглядит так. Оператор ведёт клиента по скрипту разговора, на шаге оплаты звонок переходит в IVR-сценарий, связанный с платёжным провайдером через REST API, либо клиенту уходит ссылка на оплату. Доступ к записям разговоров ограничен ролями и протоколируется. Конкретную схему, включая исключение реквизитов из записи, фиксируют вместе со службой ИБ и аудитором на этапе проектирования.
Итоги
Требования стандарта PCI DSS проще выполнить, если реквизиты карт вообще не попадают в контакт-центр. Ссылка на оплату, платёжный IVR и маскирование тонов снимают с КЦ самую тяжёлую часть требований. Оставшееся — доступы, журналы, сегментация и обучение — это обычная гигиена информационной безопасности, которая нужна колл-центру и без PCI DSS.
