Правила обработки персональных данных в информационных системах
Документ, который переводит язык закона на язык конкретных систем: какие действия с персональными данными происходят в каждой из них, кто их выполняет, что при этом разрешено и что запрещено.
Зачем нужен документ
Закон описывает обработку как перечень действий: сбор, запись, систематизация, накопление, хранение, уточнение, извлечение, использование, передача, обезличивание, блокирование, удаление, уничтожение. Организация мыслит иначе — процессами: принять сотрудника, оформить заказ, ответить на обращение. Правила обработки нужны для того, чтобы эти два языка совпали: по каждой информационной системе становится видно, какие юридические действия в ней фактически совершаются и кем.
Именно перевод и даёт документу практическую ценность. Пока обработка описана процессами, из виду выпадают операции, которые никто не считает обработкой: выгрузка в таблицу перед совещанием, копия базы для тестирования новой версии, отчёт, отправленный по почте подрядчику. С точки зрения закона каждая из них — полноценное действие с персональными данными, у которого должно быть основание и правило.
Второе назначение — границы допустимого. Правила прямо называют, что в системе делать нельзя: выгружать за пределы контура без разрешения, использовать боевые данные в тестовой среде, передавать доступ коллеге, хранить локальные копии на рабочих станциях. Запреты в этом документе работают лучше, чем в любом другом, потому что привязаны к конкретной системе и конкретной операции.
Чем грозит отсутствие
Собственного состава у отсутствия правил обработки в кодексе нет — ответственность наступает по общей норме. Но настоящая цена этого документа не в штрафе за его отсутствие, а в том, что без него организация не контролирует операции, за каждую из которых наказывают отдельно.
Как ещё называют этот документ
Что должно быть в документе
Состав закон не фиксирует. Рабочий ориентир: по каждой системе должно быть понятно, какие данные в ней есть, какие действия с ними допустимы, кто их выполняет и что происходит с данными в конце.
Требования законодательства
Как связан с другими документами
Когда обновлять документ
Что спросит проверяющий
Проверка по этому документу почти всегда идёт от системы к бумаге, а не наоборот: смотрят, что происходит в системе, и сверяют с тем, что написано.
Разбор эксперта
Этот документ единственный в комплекте, который заставляет посмотреть на обработку так, как на неё смотрит закон, — через действия, а не через процессы. Разница кажется схоластической ровно до первого разбора. Организация уверенно перечисляет: принимаем сотрудников, ведём клиентов, отвечаем на обращения. Задаёшь другой вопрос — какие действия с данными выполняются в вашей системе за неделю — и выясняется, что там есть ежедневная выгрузка в таблицу для руководителя, копия базы на тестовом сервере, автоматическая отправка списков подрядчику и архив, куда складывается всё, что удаляют из основной системы. Ни одна из этих операций в процессном описании не видна, и ни одна не была описана как обработка.
Самое дорогое здесь — выгрузки. Организация покупает средства защиты, настраивает разграничение доступа, иногда аттестует систему, а потом сотрудник выгружает базу в файл и отправляет себе на почту, чтобы поработать вечером. В этот момент данные оказываются за пределами всего защищённого контура: файл лежит в почтовом ящике, на домашнем компьютере, в мессенджере. Мы видели инциденты, где система была защищена безупречно, а утечка произошла из выгрузки полугодовой давности, о которой никто не помнил. Формально система не была скомпрометирована — фактически утекла вся база.
Поэтому правило, которое я советую закладывать сразу: выгрузка — не обычная операция, а исключение с разрешением, сроком жизни и местом хранения. Кто вправе выгружать, в каком объёме, куда сохраняет, когда удаляет. И, если система позволяет, подкреплять это техническим ограничением, а не только текстом, — право выгружать базу целиком нужно двум-трём людям, а не всем, у кого есть доступ к разделу. Отдельный пункт — тестовые среды: перенос боевых данных в тестовую систему должен быть либо запрещён, либо сопровождаться обезличиванием. Это одно из немногих требований, которое разработчики принимают спокойно, если объяснить его до, а не после инцидента.
Соберите полный перечень систем — включая те, что появились без участия ИТ-службы: таблицы общего доступа, сервисы рассылок, кадровые платформы. По каждой системе выпишите действия языком закона, а не интерфейса. Отдельным разделом опишите выгрузки: кто, что, куда, на какой срок — это единственная часть документа, которая реально снижает риск. Запретите использование боевых данных в тестовых средах или потребуйте обезличивания. Пропишите сроки хранения по каждой системе и назначьте ответственного за удаление. И проследите, чтобы правила не пересказывали положение о защите ИСПДн: у них разный предмет, и дублирование делает бесполезными оба.
Александр КеллерманнГенеральный директор, ведущий аудитор ISO/IEC 27001, Комитет по информационной и правовой безопасностиПодробнее об экспертеЧастые вопросы
Предметом. Правила обработки описывают, что происходит с данными в системе: какие действия совершаются, кем, на каком основании и сколько данные хранятся. Положение о порядке работ по защите отвечает на вопрос, как система защищена от угроз. Это соседние документы, и один не заменяет другой.
Не обязательно. Организации с несколькими системами обычно делают один документ, внутри которого каждая система описана отдельным блоком: перечень данных, действия, основания, доступ, сроки. Отдельные правила имеет смысл заводить для систем с принципиально иным режимом — например, для биометрической.
Да. Извлечение и последующее использование данных — полноценные действия, а полученный файл остаётся персональными данными со всеми требованиями к ним. Разница только в том, что за пределами системы он не защищён ничем из того, что внедрено внутри неё.
Юридически это обработка в новой среде с новым кругом доступа, и обосновать её целью почти невозможно. Правильное решение — обезличивание данных перед переносом в тестовую среду. Если это по каким-то причинам невозможно, тестовая среда должна защищаться наравне с боевой, что обычно дороже обезличивания.
Вместе. Юрист знает, как называются действия в терминах закона и какие основания требуются; ИТ знает, что фактически происходит в системах. Документ, написанный одной стороной, либо не совпадает с реальностью, либо не совпадает с законом.
Да, но объём будет небольшим: одна система, понятный состав данных, ограниченный круг пользователей. Даже в этом случае стоит описать выгрузки и сроки хранения — именно они создают риск, а не сама программа.
Правила адресованы организации и описывают порядок целиком. Инструкция — выжимка для конкретного работника, которую он подписывает. Без инструкции правила остаются документом, о котором исполнители не знают, а претензии за их нарушение предъявить невозможно.