«Соблюдение требований разных юрисдикций, это не про выбор одного стандарта, а про создание гибкой системы управления, где российские 152-ФЗ и ФСТЭК становятся базовым каркасом, а требования других стран — модулями, которые можно подключать и отключать. Главная ошибка — пытаться построить отдельный забор для каждого регулятора. Правильный путь — построить один высокий и прочный забор, а потом документировать, какие его секции соответствуют каким требованиям.»
Почему простое сложение требований не работает
Первое интуитивное решение — взять все требования из 152-ФЗ, GDPR, HIPAA, PCI DSS и других стандартов, объединить их в один список и начать выполнять. Этот подход терпит неудачу по нескольким причинам. Во-первых, требования разных юрисдикций часто противоречат друг другу. Например, GDPR требует удалять персональные данные по истечении срока их хранения или по запросу субъекта (право на удаление). В то же время российский 152-ФЗ и отраслевые регуляторы могут предписывать хранить определённые данные (логи транзакций, переписку) в течение нескольких лет. Выполнить оба требования для одного и того же массива данных физически невозможно.
Во-вторых, ресурсы любой организации ограничены. Попытка закрыть все контрольные точки всех стандартов одновременно приводит к распылению бюджета, человеческих ресурсов и внимания. Команда безопасности начинает заниматься формальным «чекбоксингом» вместо построения реальной защищённой архитектуры. В итоге создаётся видимость compliance при наличии фундаментальных уязвимостей.
В-третьих, фокус на множестве юрисдикций размывает понимание базового уровня безопасности. Специалисты погружаются в нюансы зарубежных стандартов, в то время как не выполнены базовые требования ФСТЭК по аттестации или классификации ИСПДн.
Базовый принцип: российское регулирование как фундамент
Для компании, ведущей деятельность в России, требования 152-ФЗ, приказов ФСТЭК и ФСБ являются обязательным минимумом. Их нельзя игнорировать или откладывать в угоду иностранным стандартам. Более того, эти требования часто оказываются наиболее детализированными и жёсткими в технической части, особенно для государственных информационных систем и критической информационной инфраструктуры.
Поэтому стратегия должна строиться от внутреннего к внешнему. Сначала создаётся система защиты информации, соответствующая российским нормам. Этот процесс даёт конкретные артефакты: модель угроз, политики безопасности, аттестованные средства защиты, протоколы проверок. Эта система становится вашим «ядерным» compliance.
Затем вы накладываете на эту базу требования других юрисдикций. Ключевой вопрос: что из уже реализованного покрывает иностранные стандарты, а что требует дополнительных мер? Например, реализованные в рамках ФСТЭК мероприятия по управлению доступом, аудиту и шифрованию данных с большой вероятностью покроют значительную часть требований PCI DSS или ISO 27001.
Картирование требований: от чекбоксов к общей модели
Следующий шаг — системное сопоставление. Необходимо перевести требования разных стандартов на язык вашей внутренней системы управления безопасностью.
- Создайте единый реестр активов. Все информационные системы, базы данных, сервисы должны быть учтены с указанием, какие данные (персональные, платежные, медицинские) они обрабатывают и в каких юрисдикциях находятся (физическое расположение серверов, гражданство субъектов данных).
- Проведите картирование контроля. Для каждого требования внешнего стандарта найдите соответствие во внутренних политиках, процедурах или технических мерах. Результат удобно представить в виде таблицы.
| Требование стандарта (напр., GDPR Ст. 32) | Соответствующее требование 152-ФЗ/ФСТЭК | Реализующая мера в компании | Статус покрытия |
|---|---|---|---|
| Псевдонимизация и шифрование ПДн | Приказ ФСТЭК №21, треб. 4, 9 (защита ПДн при передаче и хранении) | Шифрование дисков на серверах, TLS 1.2+ для передачи | Полное |
| Постоянная конфиденциальность, целостность, доступность | Требования к СЗИ от НСД, антивирусной защите, резервному копированию | Настройка SIEM, WAF, ежедневное бэкапирование | Частичное (требуется документирование процессов восстановления) |
Такой подход превращает разрозненные требования в управляемую матрицу. Вы видите, какие меры являются мультифункциональными, а какие придётся реализовывать исключительно под конкретный стандарт.
Техническая архитектура: изоляция и локализация данных
Самый эффективный способ снизить сложность compliance — минимизировать количество юрисдикций, которые затрагивают одну и ту же систему. Архитектурные решения здесь первичны.
- Географическая сегментация. Если вы обрабатываете данные граждан ЕС, рассмотрите возможность размещения соответствующей инфраструктуры и административной команды в пределах ЕС. Это физически выводит эти данные из-под прямого действия 152-ФЗ (хотя трансграничная передача правил всё равно требует учёта) и упрощает соблюдение GDPR. Аналогично для других регионов.
- Логическая изоляция. Если географическая сегментация невозможна, используйте строгое логическое разделение. Данные, подпадающие под разные режимы (например, российские персональные данные и данные для международного платежного шлюза), должны обрабатываться в разных виртуальных средах, с разными правами доступа и разными контурами мониторинга.
- Локализация метаданных и ключей шифрования. Даже если данные хранятся в облаке провайдера, контроль над ключами шифрования и управляющими сервисами должен оставаться в нужной юрисдикции. Требование ФСТЭК о хранении ключей шифрования на территории РФ — яркий пример.
Эти меры позволяют применять разные наборы политик к разным сегментам инфраструктуры, а не ко всему дата-центру сразу.
Управление документацией и аудитами
Разные регуляторы и аудиторы запрашивают доказательства compliance в разном формате. Подготовка к этому — отдельная задача.
Создайте «ядро» документации на русском языке, соответствующее требованиям ФСТЭК (Политика ИБ, Регламенты, Процедуры). Это ваш основной пакет.
Разработайте производные документы для других юрисдикций. Вместо написания с нуля отдельной политики конфиденциальности под GDPR, создайте документ «Интерпретация Политики обработки ПДн в части требований GDPR (Регламент ЕС 2016/679)». В нём сделайте отсылки к разделам вашей основной политики и добавьте специфические положения, которых нет в российском праве (например, процедуры исполнения запросов субъектов данных на перенос данных).
Проводите внутренние аудиты по модульному принципу. Сначала проводится полный аудит на соответствие 152-ФЗ/ФСТЭК. Затем, на его основе, выполняются точечные проверки по матрице соответствия для GDPR, PCI DSS и т.д. Это экономит время аудиторов и позволяет увидеть картину целиком.
Культура и операционные процессы
Технические меры и документация — только часть решения. Без интеграции в бизнес-процессы система будет давать сбои.
Внедрите обязательный этап «Оценка compliance» в жизненный цикл любого нового продукта, сервиса или партнёрства. Чек-лист должен включать вопросы:
- Какие категории данных будут обрабатываться?
- На территории каких стран будут находиться серверы и администраторы?
- Какие регуляторные режимы включаются?
- Какие дополнительные меры защиты потребуются?
Обучите не только специалистов безопасности, но и разработчиков, продукт-менеджеров, юристов основам ключевых регуляторных режимов. Разработчик должен понимать, чем обработка номера паспорта россиянина отличается от обработки email пользователя из Германии с точки зрения архитектуры базы данных и логгирования.
Когда без конфликта не обойтись
Несмотря на все усилия, некоторые конфликты требований неустранимы. Самый острый — противоречие между требованием иностранного регулятора предоставить данные и запретом российского законодательства на такую передачу (например, из-за статуса информации как составляющей КИИ).
Здесь стратегия должна быть проактивной:
- Юридический анализ. Чётко определите, подпадают ли ваши системы и данные под действия законов типа 187-ФЗ (о КИИ) или постановлений о запрете передачи данных.
- Архитектурное решение. Максимально изолируйте данные, которые потенциально могут стать предметом такого конфликта.
- Документирование позиции. Имейте подготовленное юридическое обоснование, почему вы не можете выполнить противоречащее российскому закону требование иностранного регулятора. Это обоснование должно опираться на конкретные нормы.
- Диалог с регулятором. В некоторых случаях возможно вступить в переписку с иностранным регулятором, объяснив правовые коллизии. Иногда это приводит к нахождению компромисса.
Полное избегание конфликтов невозможно в глобальном цифровом мире, но их можно предвидеть и управлять их последствиями.
Инструменты и автоматизация
Управлять всеми этими процессами вручную, на таблицах, невозможно при росте компании. Нужна специализированная платформа GRC (Governance, Risk, Compliance).
Хорошая GRC-система позволяет:
- Вести единый реестр активов, нормативных требований и рисков.
- Строить и поддерживать матрицы соответствия между стандартами.
- Автоматически собирать доказательства compliance с технических систем (например, выгружать конфигурации, логи доступа).
- Управлять планом мероприятий по устранению несоответствий.
- Готовить отчёты для разных стейкхолдеров (совет директоров, ФСТЭК, иностранный аудитор) на основе одних и тех же актуальных данных.
Выбор такой платформы — критически важное решение. Она должна поддерживать российские нормативные базы и иметь возможность гибкой настройки под вашу уникальную матрицу требований.
Соблюдение требований разных юрисдикций, это непрерывный процесс управления сложностью, а не разовая задача. Успех лежит в построении сильного, соответственного российским нормам ядра безопасности и надстройке над ним адаптивных, документированных процессов для работы с дополнительными регуляторными рамками. Цель — не просто пройти очередной аудит, а создать устойчивую операционную среду, в которой бизнес может развиваться глобально, не подвергаясь неожиданным регуляторным рискам.