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