Персональные данные: почему комплаенс нельзя делегировать только юристам
Архитектура данных и прав доступа напрямую влияет на правовой риск. Технические решения принятые сегодня станут юридической проблемой завтра.
Когда компания начинает работу с требованиями 152-ФЗ, первый рефлекс - позвать юристов. Они составят политику, напишут согласия, подготовят документы для регулятора. Это правильный шаг, но недостаточный.
Проблема в том, что юрист не видит, как данные реально движутся внутри системы. Он работает с тем, что написано в документах. А разрыв между документом и реальной архитектурой - это и есть основной источник риска.
Я видел компании, у которых вся документация была безупречной. И в то же время персональные данные клиентов спокойно лежали в тестовой базе разработчиков, копировались в Excel для "быстрого анализа" и передавались в сторонние сервисы без каких-либо договорных оснований. Юристы об этом не знали, потому что им никто не рассказал.
Где риск живёт на самом деле
Правовой риск при работе с персональными данными не сосредоточен в документах. Он сосредоточен в трёх местах: фактических местах хранения данных, правах доступа и потоках передачи.
Первое - это места хранения. Знает ли компания, где физически находятся персональные данные? Не в теории, а фактически - все копии, все резервные копии, все промежуточные хранилища. На практике список всегда длиннее, чем кажется.
Второе - это права доступа. Кто имеет доступ к каким данным и на каком основании? В большинстве компаний среднего размера это не управляется системно. Доступ выдаётся по просьбе, накапливается годами и никогда не пересматривается.
Третье - это потоки данных. Куда данные уходят после того, как попадают в систему? В какие интеграции, в какие аналитические инструменты, в какие внешние сервисы? Каждая такая точка - это либо оформленный договор о передаче, либо незафиксированный риск.
Почему это технический вопрос, а не только правовой
Российский регулятор тоже движется в этом направлении - Приказ ФСТЭК №21 явно привязывает уровни защиты к реальному характеру систем, а не только к документам. Юрист может написать правильную политику обработки данных. Но он не может физически ограничить доступ к таблице в базе данных. Он не может настроить маскирование данных в тестовых окружениях. Он не может обеспечить логирование всех операций с персональными данными.
Это делает архитектор или разработчик. И если они принимают решения без учёта требований по защите данных - никакой документ это не исправит.
Конкретные вещи, которые должны быть решены на уровне системы:
- разделение данных по уровням чувствительности и ограничение доступа на уровне схемы базы данных, а не только на уровне приложения;
- тестовые и аналитические среды не должны содержать реальные персональные данные - нужны либо обезличивание, либо синтетические данные;
- интеграции с внешними системами должны быть задокументированы и иметь договорное основание до того, как данные начнут передаваться;
- логирование доступа к чувствительным данным - не для всего подряд, а для тех данных, по которым есть обязательства.
Где обычно находится разрыв
В большинстве проектов, которые я видел, разрыв возникает в момент, когда технические и правовые команды работают параллельно и не пересекаются.
Юристы пишут документы, исходя из идеальной модели. Разработчики строят систему, исходя из удобства и скорости. Когда документы и система наконец встречаются, часто оказывается, что они описывают разные реальности.
Решение здесь организационное: нужна точка пересечения, в которой технические решения проверяются на соответствие правовым требованиям, а правовые требования переводятся в конкретные технические ограничения. Это не аудит раз в год. Это участие в архитектурных решениях.
Проверочные вопросы
Несколько вопросов, которые позволяют быстро оценить реальное состояние:
- Есть ли актуальная карта всех мест хранения персональных данных - не по документам, а по факту?
- Проходили ли тестовые и аналитические среды проверку на отсутствие реальных данных?
- Когда последний раз пересматривались права доступа к чувствительным данным?
- Все ли внешние интеграции, через которые уходят данные, покрыты договорами?
- Знают ли разработчики, какие именно поля являются персональными данными в каждой из систем?
Если хотя бы на два из этих вопросов ответа нет - проблема не в документах. Она в том, что правовая и техническая части существуют отдельно друг от друга.