Требования к локализации данных: что на самом деле должна делать организация с иностранным капиталом
Обязательства по локализации данных часто обсуждают абстрактно и редко переводят в то, что должно измениться в системах конкретной организации. Вот практический облик этого вопроса.
Консультационная группа HainanInc по данным и конфиденциальности
· 3 мин чтения
Приводит ли тот или иной поток данных к обязанности локализации или трансграничной передачи, зависит от вопросов классификации, которые большинство организаций на деле не прорабатывали: к какой категории относятся данные, какой порог объёма применяется и подпадает ли собственная обработка организации под тот вид деятельности, на который нацелены правила. Ни на один из этих вопросов нельзя ответить в абстрактном виде — каждый зависит от того, что на самом деле делают системы самой организации, а не от общего описания регуляторной области.
Классификация предшествует соблюдению требований, а не идёт рядом с ним
Обязанность локализации или трансграничной передачи возникает из характера и объёма конкретных данных, а не из того, что организация находится в иностранной собственности или ведёт деятельность на международном уровне. Две организации с похожей численностью персонала и выручкой могут оказаться по разные стороны обязанности — всё зависит от того, какие категории данных они реально хранят и какой их объём пересекает границу за период. Если исходить из посылки «мы организация с иностранным капиталом, значит, это, вероятно, относится к нам», пропускается шаг, который и определяет ответ, — классификация на уровне данных, а не на уровне организации.
Где организации обычно обнаруживают пробел
На практике пробел редко выявляется при формальном аудите. Он всплывает, когда в рядовых отношениях с поставщиком — облачном аналитическом инструменте, платформе клиентской поддержки с головным офисом за рубежом, обработчике заработной платы, чьи серверы расположены в иной юрисдикции, чем кто-либо предполагал, — обнаруживается, что данные передаются способом, который никто не картировал, потому что эти отношения возникли раньше любой целенаправленной проверки соблюдения требований. Поставщика выбирали за его продукт, а не проверяли архитектуру его данных, и вопрос о том, куда на самом деле уходят данные, при подключении не задали, потому что никому не пришло в голову его задать.
Вопрос никогда не в том, пересекают ли данные границу. Вопрос в том, может ли сейчас кто-нибудь предъявить карту всех мест, где они её пересекают.
Составление реестра: что это на самом деле означает
Реестр потоков данных на начальном этапе — скорее операционная, чем юридическая работа: он начинается с систематического перечня каждой системы, каждого поставщика и каждой интеграции, затрагивающих данные организации, и для каждого из них — с выяснения, где эти данные реально обрабатываются и хранятся, а не где утверждают рекламные материалы поставщика. На практике это значит свести в один разговор ИТ, кадры, финансы и все клиентские системы, поскольку вопросы локализации данных редко считаются с границами подразделений: платформа клиентской поддержки, выбранная одной командой, и платёжная система, выбранная другой, могут каждая по отдельности породить обязанность, которую никто не рассматривал в совокупности.
Обязанность определяют объём и категория, а не намерение
Организация, которая никогда не собиралась вывозить чувствительные данные за границу, всё равно может попасть под обязанность лишь потому, что категории хранимых ею данных и объём обработки оказались выше соответствующих порогов, — намерение не служит защитой, а «мы не осознавали» описывает сам пробел, а не исключение из него. Поэтому описанный выше шаг составления реестра должен быть по-настоящему исчерпывающим, а не сосредоточенным только на тех потоках, которые организация сама считает чувствительными; значимые категории определяет регуляторная рамка, а не интуиция организации о том, что кажется чувствительным.
Кто должен отвечать за реестр, когда он уже есть
Реестр, составленный один раз и убранный в архив, теряет бо́льшую часть своей ценности в течение года, поскольку новые поставщики и системы добавляются непрерывно, и каждая из них — потенциальный новый поток данных. Поддерживают его в актуальном состоянии те организации, которые назначают чёткого ответственного — человека, в чьи обязанности входит задавать вопрос о потоках данных при каждом подписании контракта с новым поставщиком, а не оставлять это той команде, которая случайно вспомнит. Где именно находится эта ответственность, зависит от размера организации, но сценарий сбоя одинаков: реестр без ответственного устаревает ровно так же быстро, как меняются отношения организации с поставщиками.
Практическая последовательность, чтобы опередить вопрос
- Внесите в реестр каждую систему и каждого поставщика, затрагивающих данные организации, включая выбранных командами вне комплаенса и ИТ.
- По каждому установите, где данные реально обрабатываются и хранятся, а не где их размещение описывает реклама поставщика.
- Классифицируйте задействованные категории данных по реальной регуляторной экспозиции организации, не исходя из того, что её определяет одна лишь иностранная собственность.
- Отметьте любые отношения с поставщиками, где ответ неясен, и рассматривайте эту неопределённость как приоритет для разрешения, а не как деталь, к которой можно вернуться позже.
- Пересматривайте реестр при подключении нового поставщика или системы, а не считайте это разовой работой.
Практическая отправная точка — реестр потоков данных, составленный до того, как конкретная передача становится срочной, а не после. Это общий комментарий по развивающейся регуляторной области, он не является юридической консультацией; конкретные вопросы классификации следует направлять юристу, знакомому с реальными системами организации.