Соответствие облачного сервиса 152-ФЗ: чек-лист проверки провайдера перед договором

Стоит поднять трубку и спросить про конкретный номер аттестата соответствия ИСПДн — тишина. Либо ответ «отправим в коммерческом предложении». Либо PDF на пять мегабайт с водяным знаком «конфиденциально», где половина страниц замазана. Это не паранойя — это рабочая рутина проверки облака на соответствие 152-ФЗ.

Законы не меняются по мановению маркетингового отдела. Федеральный закон № 152-ФЗ «О персональных данных» требует от оператора конкретных действий, а не веры в красивый сайт провайдера. С 30 мая 2025 года за утечку данных от 1 тыс. до 10 тыс. субъектов персональных данных компания или ИП платит от 3 млн до 5 млн рублей штрафа. Забыли уведомить Роскомнадзор об инциденте — ещё от 1 млн до 3 млн. Это не страшилка, это буква закона, принятого 30 ноября 2024 года (№ 420-ФЗ). А теперь пересчитайте, во что обойдётся «доверие» к поставщику, который не смог предоставить даже базовый пакет документов.

Юридический фундамент: что провайдер обязан показать на стол

Аттестат соответствия ИСПДн — это не маркетинговая брошюра и не «сертификат партнёра». Это документ, выданный органом по аттестации, лицензированным ФСТЭК, который подтверждает: информационная система персональных данных провайдера соответствует требованиям безопасности. Без него говорить о соответствии облачного сервиса требованиям 152-ФЗ — то же самое, что ссылаться на диплом, который «где-то есть».

Какие документы должны лежать на столе перед подписанием договора:

• Аттестат соответствия ИСПДн с указанием класса информационной системы и фактического адреса размещения ЦОД. Копия заверяется, номер вносится в реестр — иначе бумага ничего не стоит.
• Лицензия ФСТЭК на техническую защиту конфиденциальной информации. Деятельность по ТЗКИ — это не «консультирование по безопасности», а конкретный вид работ, на который нужна лицензия.
• Лицензия ФСБ на работу с криптографическими средствами (шифрование, СКЗИ). Если провайдер шифрует ваши данные — он обязан иметь эту лицензию, а не просто «использовать ГОСТ-алгоритмы».
• Модель угроз и нарушителя — документ, описывающий, от кого именно защищают ваши данные. Без актуальной модели любой аттестат превращается в формальность.
• Отчёт о результатах оценки рисков или результаты внутреннего аудита. Не «всё хорошо, поверьте», а конкретные показатели с перечнем выявленных уязвимостей и сроками их устранения.

Провайдер, который не может показать номер аттестата соответствия ИСПДн, не продаёт вам безопасность. Он продаёт виртуальные машины и надеется, что вы не спросите.

Стандарт ГОСТ Р 57580.1-2017 обязателен для финансового сектора, но и за его пределами является хорошим ориентиром. Если провайдер прошёл сертификацию по ISO/IEC 27001, ISO/IEC 27017 (облачная безопасность) и ISO/IEC 27018 (защита персональных данных в публичных облаках) — это плюс. Но международные сертификаты не заменяют российские лицензии и аттестаты. Запомните: ISO — это про менеджмент процессов, ФСТЭК — про конкретные технические меры. Одно без другого не работает.

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

Модель разделяемой ответственности: где кончается облако

Самая частая ловушка, в которую попадают операторы данных, — убеждение, что аренда аттестованного облака автоматически делает их compliant. Это не так. Безопасность в облаке строится на модели разделения ответственности, и провайдер честно об этом скажет в нормальном SLA. Если не говорит — ищите другого.

Разделение выглядит так:

Зоны УЗ-1 и УЗ-2 требуют применения сертифицированных СЗИ. УЗ-3 и УЗ-4 — менее жёсткие, но тоже требуют конкретных мер. Провайдер обеспечивает инфраструктуру, но не вашу гостевую систему, не ваши парольные политики, не ваш контроль доступа и не вашу классификацию данных. Если в вашей виртуалке крутится MySQL с дефолтным паролем root/root — аттестат провайдера вас не спасёт.

Аттестат провайдера закрывает физику и платформу. Всё, что вы ставите поверх, — ваша зона. Забыли эту границу — штрафы ваши.

Практический тест: попросите провайдера описать в договоре или SLA, какие конкретно меры он берёт на себя по каждому уровню защищённости. Если ответ «по умолчанию всё защищено» — это красный флаг размером с серверную стойку. Нормальный провайдер предоставляет матрицу ответственности с чётким распределением: за что платим мы, за что отвечаете вы, и где проходит граница. Без этой матрицы вы не управляете рисками — вы играете в рулетку.

Договор поручения: что должно быть внутри, чтобы не сесть в лужу

По закону, размещая персональные данные в облаке, оператор поручает их обработку провайдеру. Это требует договора поручения (ст. 6 152-ФЗ). Без него передача ПДн третьему лицу — прямое нарушение, даже если провайдер трижды аттестован.

Критические пункты договора поручения, без которых документ — филькина грамота:

1. Цели обработки — конкретно перечисленные, а не «для оказания услуг». Размытая формулировка даёт провайдеру carte blanche на любые действия с данными.

2. Перечень обрабатываемых ПДн — не «персональные данные клиентов», а конкретный состав: ФИО, телефоны, email, паспортные данные, платёжные реквизиты. Всё, что не входит в перечень, обрабатывать запрещено.

3. Меры по обеспечению безопасности — ссылка на конкретные СЗИ, классы защиты, применяемые стандарты. «Применяет необходимые меры» — не катит.

4. Ответственность провайдера за нарушение — в части, не противоречащей закону. Штрафные санкции за инцидент — отдельный пункт.

5. Уведомление об инцидентах — провайдер обязан сообщить оператору о любом инциденте в течение конкретного срока (часы, не дни). «Без промедления» — это не срок, это лазейка.

6. Условия возврата и уничтожения данных — при расторжении договора провайдер обязан вернуть все ПДн оператору и уничтожить копии в течение конкретного срока с подтверждением. «По завершении оказания услуг» — сколько это дней? Месяцев? Пропишите цифры.

7. Аудит — право оператора на проведение аудита или запрос отчёта о мерах безопасности у провайдера. Без этого пункта вы слепы.

8. Субподрядчики — если провайдер использует субподрядчиков для обработки ПДн, их перечень и условия привлечения должны быть в договоре.

Договор поручения — это не формальность. Это документ, который Роскомнадзор запросит при проверке. Если там написано «услуги по обработке данных на условиях SLA», а конкретного перечня мер нет — оператор получает штраф и остаётся один на один с утечкой.

Локализация и физика: почему серверы должны быть в РФ

Статья 18 152-ФЗ требует: первичный сбор и хранение персональных данных граждан РФ должны осуществляться на серверах, физически расположенных на территории Российской Федерации. Не «преимущественно», не «по возможности», не «с учётом бизнес-целесообразности» — исключительно на территории РФ. Это не рекомендация, это закон.

На практике это означает:

• ЦОД провайдера должен находиться в России. Запросите точный адрес и проверьте по публичным реестрам, существует ли этот ЦОД физически. Не абстрактный «Московский регион», а конкретная площадка с действующим аттестатом.
• Резервные копии — тоже в РФ. Географически распределённые ЦОД — это хорошо, но все они должны быть на территории страны. Один провайдер может держать основную площадку в Москве и реплику в Новосибирске — обе в рамках закона. Но если реплика уехала в Хельсинки или Франкфурт «для отказоустойчивости» — это нарушение.
• Трансграничная передача — только при наличии отдельного согласия субъекта или при внесении страны-получателя в перечень Роскомнадзора. Если ваш провайдер тащит данные в зарубежную реплику «для отказоустойчивости» — это нарушение, о котором вы, возможно, не знаете.

Физическая безопасность ЦОД — биометрический доступ, видеонаблюдение, охрана 24/7, контроль температуры и влажности, резервирование питания. Не верьте презентациям, требуйте фотоотчёт или результаты аудита. Серьёзные провайдеры проводят экскурсии по площадкам — если вам отказывают, задумайтесь, что скрывают.

Штрафы 2025 года: почему эта тема перестала быть «для юристов»

До 30 мая 2025 года за утечку персональных данных штрафовали на суммы, которые бизнес воспринимал как «расходы на маркетинг». Сейчас это другая математика. За утечку от 1 тыс. до 10 тыс. субъектов ПДн юрлицо или ИП платит от 3 млн до 5 млн рублей. За неуведомление Роскомнадзора об инциденте — отдельный штраф от 1 млн до 3 млн. Эти санкции складываются, не заменяют друг друга. Утекли данные 5 тыс. клиентов и забыли сообщить — получите 4–8 млн рублей убытков плюс репутационный шрам, который не смывается.

3–5 млн за утечку плюс 1–3 млн за молчание. Это не страховка, это цена выбора плохого провайдера.

Что это меняет на практике:

• Выбор провайдера перестаёт быть технической задачей — это задача управления рисками. Один инцидент у поставщика облака = прямой финансовый удар по оператору.
• Договор с провайдером должен включать его финансовую ответственность за инцидент. Без этого оператор платит штрафы из своих денег, а провайдер отвечает «у нас всё по SLA».
• Проверка аттестатов и лицензий провайдера должна происходить до подписания договора, а не после первой жалобы Роскомнадзора.
• Логирование и мониторинг инцидентов у провайдера — обязательный пункт аудита. Если провайдер не ведёт журнал событий безопасности и не предоставляет к нему доступ — это красный флаг.

Чек-лист перед подписанием договора

Список конкретных действий, которые нужно выполнить до переноса персональных данных в облако. Без галочек «на словах», только документы.

1. Запросить и получить копию действующего аттестата соответствия ИСПДн с указанием класса ИСПДн и адреса ЦОД. Проверить номер в реестре ФСТЭК.

2. Запросить копии лицензий ФСТЭК на ТЗКИ и ФСБ на работу с СКЗИ. Проверить номера в публичных реестрах.

3. Получить модель угроз и нарушителя, актуальную на текущий год. Сравнить с собственной моделью оператора.

4. Согласовать модель разделяемой ответственности: кто за что отвечает по каждому уровню защищённости.

5. Включить в договор поручения конкретный перечень обрабатываемых ПДн, цели обработки и меры безопасности. Без размытых формулировок.

6. Зафиксировать в договоре сроки уведомления об инцидентах, условия возврата и уничтожения данных, право на аудит.

7. Проверить физическое расположение серверов — все ЦОД и резервные площадки должны быть в РФ.

8. Убедиться, что провайдер ведёт журнал событий безопасности и предоставляет к нему доступ по запросу.

9. Согласовать условия финансовой ответственности провайдера за инциденты, приведшие к утечке.

10. Запросить информацию о субподрядчиках провайдера, имеющих доступ к ПДн, и условия их привлечения.

Что осталось за кадром, но важно

Аттестованное облако не снимает с оператора юридическую ответственность за утечку. Штрафы платит оператор, а не провайдер. Это значит, что выбор поставщика облака — это не «выбрал и забыл», это постоянный процесс: аудиты, проверки, сверки версий аттестатов, контроль журналов. Провайдер, который меняет ЦОД, переносит данные в новую юрисдикцию или привлекает новых субподрядчиков без уведомления — это приговор вашему бюджету.

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

Безопасность — это процесс, а не сертификат в рамке на стене. Провайдер с тремя аттестатами и отсутствующей оперативной реакцией на инцидент проиграет провайдеру с одним аттестатом, но с работающим SOC и журналом событий, доступным клиенту. Документы важны. Практика важнее документов.