Цифровизация множит точки, где компания собирает и обрабатывает персональные данные: CRM, личный кабинет, мобильное приложение, чат-бот, формы на сайте. Каждая такая точка попадает под 152-ФЗ. Роскомнадзор в 2021 году усилил проверки локализации, а поправки лета подняли планку требований к согласиям и публичным данным. Разберём, где именно цифровые проекты спотыкаются о закон и что заложить в систему заранее.

Классификация и локализация – фундамент

Первый шаг – определить, какие данные вы собираете и к какой категории они относятся: общедоступные, специальные (здоровье, политические взгляды) или биометрические. От категории зависит уровень защищённости информационной системы персональных данных (ИСПДн) и набор организационных мер по приказу ФСТЭК №21.

Второе требование, которое срывает сроки чаще всего, – локализация. Первичный сбор и хранение персональных данных граждан РФ должны идти в базах на территории России. Это касается и облачной инфраструктуры. Если вы переносите нагрузку в облако, проверяйте регион размещения дата-центра до запуска, а не после жалобы в Роскомнадзор. Тему географии и стоимости облака мы разбирали в материале про управление облачными расходами – там же видно, что выбор провайдера в РФ часто экономичнее, чем кажется.

Согласие, минимизация и сроки хранения

Согласие на обработку должно быть конкретным, информированным и сознательным. Чекбокс «согласен со всем» с предзаполненной галочкой не работает. Для рекламных рассылок и передачи данных третьим лицам нужны отдельные согласия. С учётом летних поправок 2021 года для распространения персональных данных требуется отдельное согласие на их публикацию – молчание пользователя больше не трактуется как разрешение.

Принцип минимизации означает: собирайте только то, что нужно для заявленной цели. Если форме заказа не нужна дата рождения – не запрашивайте её. Заложите в систему автоматическое удаление или обезличивание данных по истечении срока хранения. В мобильных продуктах это особенно важно: приложение легко тянет лишние идентификаторы и геолокацию. При проектировании кросс-платформенных мобильных приложений мы согласуем перечень собираемых полей с юристами ещё на этапе ТЗ.

Защита ИСПДн на пиковых нагрузках

Требования закона не отключаются в час пик. Когда трафик кратно растёт – например, в распродажу, – соблазн отключить лишние проверки ради скорости велик. Делать этого нельзя: шифрование каналов, разграничение доступа, журналирование и контроль целостности должны работать под любой нагрузкой. Архитектуру, которая держит и пиковый трафик, и контур защиты одновременно, мы описывали в статье про подготовку к пиковым нагрузкам в продажах.

На практике защита ИСПДн – это связка организационных и технических мер: модель угроз, разграничение прав, шифрование, резервирование, аудит доступа и план реагирования на инциденты. Весь этот контур, от классификации систем до подготовки документов для проверки регулятором, выстраивается единым проектом, а не набором разрозненных настроек.

Вывод

152-ФЗ не противоречит цифровизации – он задаёт рамку, в которой её нужно проектировать. Дешевле учесть классификацию, локализацию, согласия и защиту ИСПДн на этапе архитектуры, чем переделывать систему после предписания. Начните с инвентаризации данных и модели угроз, а технические меры закладывайте в проект с первого дня.