152-ФЗ: как проверить соответствие ИСПДН после волны GDPR-паники

После того как GDPR вступил в силу в мае, российские компании месяц пребывали в состоянии осознанной паники: юристы слали письма про штрафы до 4% годового оборота, ИТ-директора требовали срочно «поставить GDPR», а служба безопасности объясняла, что их это не касается, потому что они российская компания. Где-то в этот момент РКН тихо активизировал проверочную деятельность уже по 152-ФЗ - и несколько наших клиентов получили соответствующие запросы или узнали о плановых проверках.

Мы провели внутренние аудиты нескольких ИСПДН - информационных систем персональных данных - у клиентов разного масштаба. Итог оказался предсказуемым: технически у большинства всё относительно в порядке, а бумажная сторона выглядит как будто организация занималась ею один раз в 2012 году и потом забыла.

Что чаще всего оказывается не в порядке

Приказ о назначении ответственного за обработку ПДн. Это, наверное, самая частая находка. Приказ есть, но в нём фигурирует человек, который уволился год-два назад. Или должность, которой в компании давно нет. Или ответственный - генеральный директор, что само по себе нарушением не является, но создаёт вопросы при проверке, потому что он физически не может выполнять функцию.

Модель угроз. По требованиям Приказа ФСТЭК №21 для ИСПДН нужна актуальная модель угроз. «Актуальная» - это ключевое слово. У большинства она написана один раз при вводе системы в эксплуатацию и с тех пор не обновлялась. За это время система могла переехать в облако, добавились интеграции с внешними сервисами, сменился подрядчик на поддержке - ни одно из этих изменений в модель угроз не попало.

Политика обработки ПДн и согласия субъектов. Публичная политика на сайте либо отсутствует, либо написана под копирку с какого-то образца 2014 года и не описывает реальные процессы компании. Согласия на обработку - отдельная история: либо собираются не для всех категорий данных, либо формулировки настолько общие, что не покрывают фактические цели обработки.

Перечень лиц, допущенных к обработке ПДн. Требование формально простое - нужен список сотрудников с доступом к персональным данным. На практике список либо не ведётся вовсе, либо не обновляется при кадровых изменениях. Сотрудник уволился, его доступ в системах отозвали, но в перечне он остался.

Журнал учёта носителей. Если ПДн обрабатываются на съёмных носителях или выгружаются в файлы - должен быть учёт. У большинства его нет, потому что сотрудники выгружают данные «для работы» без каких-либо процедур.

Как мы строим проверку

Мы идём двумя параллельными треками.

Первый - организационно-документальный. Запрашиваем весь пакет документов: приказы, политики, положения, перечни, журналы, согласия. Смотрим на даты, на соответствие реальной структуре компании, на покрытие фактических процессов обработки. Здесь больше всего находок.

Второй - технический. Проверяем, как реально устроена ИСПДН: где хранятся данные, кто имеет доступ, как разграничены права, есть ли шифрование там, где оно требуется по классу системы, как организовано резервное копирование и что происходит с резервными копиями с точки зрения защиты ПДн. Техническая сторона обычно лучше - ИТ-команды в целом понимают, что данные нужно защищать, и базовые меры как правило приняты.

Класс ИСПДН - ещё один момент, который стоит перепроверить. Компании часто занижают класс при первичной оценке, чтобы снизить требования. Иногда это обосновано, иногда нет. Если система обрабатывает специальные категории данных - здоровье, биометрию, судимости - или данные большого числа субъектов, класс может быть выше, чем указан в документах.

Что делать с результатами

После аудита обычно получается два списка: то, что нужно исправить срочно (документы, которые либо отсутствуют, либо содержат критические несоответствия), и то, что можно планомерно подтягивать.

Срочное - как правило, именно организационная бумага. Перевыпустить приказ о назначении ответственного, обновить модель угроз, актуализировать перечень допущенных лиц - это работа нескольких дней, не месяцев. Технические изменения, если они нужны, занимают больше времени и ресурсов.

Отдельный разговор - уведомление в РКН. Многие операторы ПДн не уведомили регулятора вовсе, либо уведомили давно и с тех пор не обновляли данные. Уведомление - обязательное требование для большинства операторов, и его актуальность проверяется в первую очередь при плановой проверке.

GDPR при всей своей шумихе сделал одно полезное дело: заставил компании вспомнить про персональные данные и поднять вопрос о соответствии требованиям. Жаль, что большинство остановилось на вопросе и не дошло до ответа. РКН, судя по всему, помогает добраться.

Если есть вопросы по структуре аудита или хочется понять, с чего начать, - можно обсудить в рамках аудита информационной безопасности.