Как эффективно уберечь бизнес от критичных privacy-рисков

Контекст для ведения бизнеса стремительно меняется, и потребность в privacy-комплаенсе растет на глазах. Трансформация процессов и ИТ-систем в связи с локализацией «софта и железа», изменение цепочек поставок, цифровизация рутинных процессов ради экономии, новые угрозы атак privacy-экстремистов и конкурентов, увеличение ответственности и административной нагрузки на бизнес — весь этот комплекс факторов увеличивает спрос на комплаенс. С другой стороны, этот же контекст означает сокращение финансовых и кадровых ресурсов на обеспечение комплаенса. А значит, теперь нужен максимально эффективный комплаенс: необходимо устранить критичные для бизнеса риски, все иные можно «припарковать». Независимо от риск-аппетита критичные — это те риски, которые влекут для бизнеса незамедлительные проблемы или попросту могут дорого стоить. О том, как эффективно устранять уязвимости без проведения дорогих аудитов, рассказывает Артем Дмитриев, руководитель комплаенс-бутика Comply.

Недостатки privacy-by-design в IT-системах

При выборе бизнес-систем (CRM, HRM, BPM и модного нынче кадрового ЭДО) важно заранее обратить внимание на их privacy-механизмы, чтобы потом не испытывать мучений, внедряя их в уже готовое решение. О чем речь?

Как минимум о дата-менеджменте. Большинство корпоративных IT-систем крайне редко поддерживают хотя бы минимальный функционал контроля сроков хранения данных: учетных записей, метаданных, документов и прочего. Обычно данные хранятся в системах так долго, насколько позволяет место на сервере, а после этого — еще и в бэкапах. И, конечно, такое бессрочное хранение противоречит требованиям закона. В случае проверки Роскомнадзор обязательно проверит сроки обработки данных в системах.

Другой пример — дедупликация данных. Плохо настроенная CRM, получая заявку по каждому из каналов (от отдела продаж, с разных веб-форм на сайте, лендинга, из почты), каждый раз создает новую карточку клиента, не проверяя, заведен ли он в системе ранее. И если однажды клиент направит запрос на отзыв согласия и удаление своих данных, то его выполнение превратится в «увлекательный» ручной поиск всех его карточек в CRM. Что, в свою очередь, не всегда просто, ведь данные могут быть записаны в разных раскладках, с ошибками, карточек может быть попросту много. Такая ситуация легко приведет к ошибке — к примеру, сотрудник маркетинга отменит согласие на рассылки для двух найденных вручную карточек клиента из трех существующих — тогда клиент продолжит получать рекламу и, вероятно, пожалуется на это в ФАС и Роскомнадзор. И наоборот: излишне агрессивная и непродуманная склейка лидов и карточек также влечет риски.

Абсолютное большинство CRM-систем и даже систем сбора согласий не содержат функционала управления согласиями в необходимом объеме. Но без этого функционала ценность собранной с таким трудом клиентской базы стремительно сокращается, ведь ее юридическая чистота не ясна. Почему? Например, не ведется учет различных оснований обработки данных, их версионности. Более того, клиентские данные не привязываются к конкретным текстам договоров, политик, согласий. Представим, что клиент в привязке к его адресу электронной почты и телефону дал одно согласие, а в другом — адрес почты и регистрации. Когда срок первого согласия истечет, оставите вы его телефон, удалите все данные или не удалите никакие? Способны ли алгоритмы вашей CRM-системы автоматически отслеживать эти зависимости при истечении сроков действия согласий или договоров? К сожалению, для девяти из десяти компаний это риторические вопросы.

И это лишь точечные примеры — без базовых требований к локализации данных в России, обеспечению безопасности и т. д. Поэтому требования privacy-by-design, то есть «проектируемой приватности», надо учитывать непосредственно при выборе и внедрении систем, заранее обкатывая возможные кейсы с вендорами.

Бреши в процедурах реагирования на запросы субъектов

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

Конечно, важен не столько формальный документ, сколько отлаженный бизнес-процесс. Однако 70% компаний, опрошенных нами с начала года, никогда не проверяли, насколько они способны отработать такие запросы. Обычно в компаниях есть локальные акты об обработке данных, где среди прочего упоминается возможность запросов. Но этого недостаточно.

Компании не учитывают, что субъекты могут направить целый ряд запросов с разными сроками и требованиями к исполнению для каждого из них. Более того, недавно появился новый вид запросов: по требованию клиента придется обосновать необходимость сбора данных, и, что любопытно, на письменный запрос можно ответить в течение семи дней, а если требование устное — то немедленно. Очевидно, что без работающего процесса сотрудники компании попросту не смогут вовремя сориентироваться.

Кроме этого, зачастую субъекту доступно многообразие каналов для коммуникации с компанией. Хотя создание выделенного канала (например, privacy@company.ru) повышает шансы получить запрос именно на него, субъекту ничто не мешает обратиться и по любому другому каналу, например воспользовавшись услугами колл-центра или заказной корреспонденцией. Такие запросы одинаково обязательны для компании, а потому процессы реагирования по всем возможным каналам должны быть настроены и, что важно, проверены на практике.

При получении клиентского запроса компании иногда запрашивают у него дополнительные персональные данные, чтобы убедиться, что к ним обращается тот самый клиент. Бывает, что такая просьба обоснованна, но чаще — нет. И это распространенная ошибка. Если клиент пишет вам с адреса e-mail, использовавшегося им при регистрации, то, чтобы исключить его из рекламных рассылок, не стоит запрашивать дополнительную информацию для его идентификации. В противном случае это приведет к жалобам в ФАС и Роскомнадзор.

В последнее время Роскомнадзор уделяет таким процедурам пристальное внимание. Кроме того, проект изменений закона «О персональных данных» предлагает существенно сократить сроки ответов на запросы. Наконец, запросы субъекта — самый доступный инструмент атаки на компанию для privacy-экстремиста.

Неготовность к инцидентам с данными

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

Как и в случае с запросами субъектов, для предотвращения утечки важно наличие реального «боевого» процесса и распределения ролей, а не еще одного формального регламента. Проактивные действия имеют здесь ключевое значение. Например, важно собрать фактуру как для защиты от претензий регуляторов, так и для корректной работы с пострадавшими клиентами и организации damage-control в публичном пространстве. Однако на практике мы видим, что в случае утечки компании теряются и не могут реагировать на нее оперативно, хотя счет идет на часы.

В этом году мы представляли при общении с Роскомнадзором две известные компании по результатам не менее известных утечек. Стало очевидно, что действует «презумпция виновности» бизнеса. Насколько это справедливо, особенно с учетом грядущего беспрецедентного увеличения размера ответственности для бизнеса, можно рассуждать долго, но чтобы не потерять все шансы на защиту в рамках административного и затем гражданских дел, нужно иметь заранее проработанную стратегию: от оценки масштабов и публичности утечки до подачи заявлений в правоохранительные органы и выверенных ответов на запросы. Важно держать руку на пульсе — дополнительные инсайты появятся по результатам рассмотрения первых коллективных исков.

Разумеется, предотвращение утечек — это по большей части забота кибербезопасности. Однако privacy-комплаенс позволяет смягчить наносимый утечкой ущерб, например за счет сбора артефактов, подтверждающих добросовестность компании при внедрении и следовании процедурам защиты прав субъектов персональных данных (ПД).

Способы минимизировать риски

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

Во-первых, крайне важен так называемый front-end комплаенс. Все, до чего могут дотянуться внешние пользователи, конкуренты или инспектор Роскомнадзора, должно быть максимально выверенным, ведь именно в публичном периметре больше всего рисков. В то время как недостатки во внутренних процессах или документах возможно выявить только в ходе выездной проверки, количество которых год от года сокращается, здесь же все на виду.

Front-end комплаенс включает все публичные и пользовательские документы, пользовательский путь (CJM), работу с запросами субъектов (DSR). Комплаенс внешнего периметра компании позволяет исключить порядка 90% рисков в сфере privacy. Чтобы его проверить и обеспечить, мы, пользуясь опытом коллег из кибербезопасности, проводим privacy-пентест, суть которого в следующем. Тестируя внешний контур компании на предмет уязвимостей по всем возможным каналам коммуникации и векторам атаки, мы, как правило, находим массу именно уязвимостей. Они могут эксплуатироваться любым третьим лицом, а значит влекут критичные риски для компании. Однако закрыть их несложно. Притом что privacy-пентест закрывает почти 90% всех рисков, он гораздо менее трудоемок в сравнении с полноценным аудитом.

Во-вторых, важно быть в авангарде выбора и внедрения новых IT-систем. Если не проверить комплаенс на ранних этапах и отдать эти вопросы на откуп бизнес-заказчикам или IT, то велика вероятность пропустить «врожденную» privacy-уязвимость, дальнейшее устранение которой обойдется дорого. Проверяйте самостоятельно или как минимум подготовьте для коллег чек-листы.

И последнее: если в компании нет отработанных контролей, то нет и возможности превентивно управлять рисками. В этом случае компания обречена на тушение пожаров вместо выстраивания полноценной системы управления privacy-рисками: то и дело обнаруживаются забытые и не согласованные с privacy-функцией лендинги, маркетинговые активности, формы сбора данных, новые провайдеры, получающие доступ к данным и не слышавшие про privacy-комплаенс. Отлаженная и рабочая система гораздо эффективнее, чем вовлечение ad-hoc. Поэтому privacy-функция нужна каждой компании. И это вовсе не обязательно FTE в роли ответственного за обработку персональных данных. Возможен режим dpo-as-a-service и privacy-чемпионов в ключевых подразделениях компании. Опять же, такой формат privacy-функции гораздо дешевле, но позволит превентивно управлять рисками.