Требования к защите ПДн в 2026 году: ПП 1119, приказы ФСТЭК и что это значит для видео

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Защита медданных в 2026 году опирается на те же акты, что и десять лет назад: ст. 19 152-ФЗ, постановление Правительства № 1119 об уровнях защищённости и приказ ФСТЭК № 21 о составе мер. Но вокруг них за 2025–2026 годы изменилось почти всё: появились оборотные штрафы за утечки, запрет зарубежных баз данных, согласие отдельным документом, приказ ФСТЭК № 117 для государственных систем и трёхчасовой срок сообщения об инцидентах на значимых объектах критической инфраструктуры. В июле 2026 года ФСТЭК опубликовала проект замены приказа № 21, и по данным на 24 сентября 2026 года он всё ещё не подписан. Вместо фиксированного набора мер «под уровень» проект вводит риск-ориентированную модель с показателем «уровень зрелости». Оценивать защиту предлагается до начала обработки, раз в три года и после каждого инцидента; появляются отдельные меры для ИИ, контейнеров и API и требования к подрядчикам-обработчикам. В телемедицинской видеоплатформе эти требования касаются конкретных мест: хранилища записей, парка TURN- и SFU-серверов, сигналинга, входа через ЕСИА и каждого договора с подрядчиком. Почти всё это стандартная инженерная практика, которую стоит внедрять уже сейчас. Когда проект вступит в силу, неизвестно (указанная в нём дата 1 сентября 2026 года уже прошла), поэтому соответствуйте действующим актам, а архитектуру стройте с учётом проекта.

Зачем это читать

Если вы строите или эксплуатируете телемедицинский продукт, от этих актов зависит, как пройдёт ближайшая проверка, на каких условиях вы подпишете контракт с крупной клиникой и что придётся делать при инциденте. Государственные больницы с 1 марта 2026 года работают по приказу ФСТЭК № 117 с его показателями защищённости и зрелости, и требования к подрядчикам они будут формулировать в его терминах. Почти все материалы о новых требованиях написаны для специалистов по ИБ и не отвечают на вопрос продуктовой команды: какое требование относится к какому компоненту видеостека? Здесь мы проходим по требованиям одно за другим и для каждого показываем, где именно оно реализуется в телемед-платформе. Базовые понятия здесь не пересказываются: если оператор, поручение и спецкатегория для вас новые слова, начните с базовой статьи о 152-ФЗ и врачебной тайне, а потом возвращайтесь.

Где сейчас регулирование: статус на 12 октября 2026 года

Нормы меняются поэтапно, и сейчас процесс на середине пути. Проект нормативного акта – это черновик, опубликованный для общественного обсуждения на regulation.gov.ru; он никого ни к чему не обязывает. ФСТЭК России опубликовала проект нового приказа о мерах по обеспечению безопасности персональных данных в июле 2026 года (ID 169583), обсуждение было назначено до 8 августа.

Текущее состояние, сверенное с источниками 12 октября 2026 года:

• Приказ ФСТЭК № 21 действует. По данным на 24 сентября 2026 года проект его замены не подписан, не зарегистрирован в Минюсте и не опубликован. Дата вступления, указанная в самом проекте (1 сентября 2026 года), прошла; итоговый срок определит подписанная редакция.
• ПП 1119 и уровни защищённости УЗ-1…УЗ-4 действуют без изменений. Как новый приказ будет соотноситься с уровнями, из открытых разборов проекта не следует.
• Для государственных систем новая модель уже работает. С 1 марта 2026 года приказ ФСТЭК № 117 действует для ГИС, информационных систем госорганов и государственных учреждений, то есть и для медицинских информационных систем (МИС) госбольниц. Он вводит риск-ориентированный выбор мер, показатели защищённости и зрелости, классы К1–К3; ранее выданные аттестаты сохраняются.
• Критическая информационная инфраструктура (КИИ) здравоохранения конкретизирована. С 1 сентября 2025 года Правительство утверждает отраслевые перечни типовых объектов КИИ (58-ФЗ); распоряжение № 360-р от 26 февраля 2026 года включило в перечень информационные системы медорганизаций, лабораторные системы, сегменты ЕГИСЗ и управление медоборудованием. С 30 января 2026 года об инциденте на значимом объекте нужно сообщить в НКЦКИ не позднее 3 часов (приказ ФСБ № 547).
• 152-ФЗ ужесточён. Оборотные штрафы за утечки действуют с 30 мая 2025 года, запрет зарубежных баз – с 1 июля 2025-го, согласие отдельным документом – с 1 сентября 2025-го.

Зачем тогда планировать по черновику? Все технические требования в нём (измеряемая зрелость, переоценка после инцидента, меры для API и контейнеров, контроль подрядчиков) давно стали общепринятой практикой, а для государственных систем уже действуют через приказ № 117. Проект могут переписать, сроки могут сдвинуть, но направление вряд ли изменится. Если строить систему с учётом проекта, в худшем случае вы окажетесь готовы раньше срока. Если его игнорировать, в лучшем случае вас ждёт спешная доработка после подписания приказа.

Нажмите, чтобы увеличить

Почему регулятор ужесточает требования: цифры

Состав мер защиты для информационных систем персональных данных задан приказом 2013 года. С тех пор изменились рынок и цена ошибки. По оценке Smart Ranking, у 70 крупнейших медтех-компаний выручка от телемедицины в 2025 году достигла 21 млрд ₽ (+17,6%), это 35% их совокупной выручки против 30% годом раньше. По опросу брокера Remind среди 11 страховщиков, в 2025 году телемедициной пользовались 25% застрахованных по ДМС против 12% в 2022-м. Каждая такая консультация порождает специальную категорию персональных данных (сведения о здоровье), а клиническое видео стало частью поверхности атаки в здравоохранении. Пересмотр требований касается как раз таких платформ, как ваша.

Законодатель ответил штрафами. С 30 мая 2025 года утечка данных о здоровье стоит юрлицу 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП), а повторная – 1–3% выручки, но не менее 25 млн и не более 500 млн ₽ (ч. 18). Посчитаем для двух платформ. При выручке 2 млрд ₽ 1–3% составляют 20–60 млн ₽, но нижняя граница поднимается до 25 млн, итого 25–60 млн ₽. При выручке 20 млрд ₽ 1–3% составляют 200–600 млн ₽, но верхняя граница ограничена 500 млн, итого 200–500 млн ₽. Скидка 50% за быструю оплату к этим штрафам не применяется, а с 11 декабря 2024 года действует ещё и уголовная ст. 272.1 УК РФ. С учётом этих цифр понятно, зачем проект требует переоценивать защиту после каждого инцидента.

Главный сдвиг: от набора мер «под уровень» к измеряемой зрелости

Действующая схема состоит из трёх шагов. ПП 1119 определяет уровень защищённости по типу актуальных угроз, категории данных и числу субъектов. Приказ ФСТЭК № 21 даёт для этого уровня базовый набор мер, который оператор адаптирует (исключает меры для технологий, которых у него нет), уточняет под актуальные угрозы и дополняет мерами из других актов (п. 9). Если меру технически невозможно реализовать или она экономически нецелесообразна, разрабатываются компенсирующие меры, а их применение обосновывается при разработке системы защиты (п. 10). Эффективность мер оценивается самостоятельно или с лицензиатом ФСТЭК не реже раза в три года (п. 6).

Компенсирующие меры никогда не означали свободы выбора (механику мы разбирали в базовой статье), но они оставляли документируемый обходной путь, который легко превратить в папку обоснований. Многофакторной аутентификации в тексте приказа № 21 нет: группа мер «идентификация и аутентификация» (ИАФ) число факторов не задаёт. Шифрование появляется не отдельной строкой «шифруйте всё», а через меры защиты систем связи и передачи данных (ЗИС) и модель угроз.

Проект меняет логику. Фиксированный перечень уступает место риск-ориентированной модели: оператор сам подбирает меры под архитектуру системы и характер обработки, а эффективность оценивает через показатель «уровень зрелости». Это как разница между пожарными нормами «ставьте датчики дыма, если сочтёте нужным» и «покажите измеренный уровень пожарной безопасности и подтверждайте его после каждого возгорания». Гибкость сохраняется, но теперь её ограничивает измерение, а не папка с обоснованиями.

Нажмите, чтобы увеличить

Для продуктовой команды это значит, что как только защищённость придётся измерять, а не описывать, каждое «мы обосновали компенсирующую меру» в папке комплаенса превратится в задачу бэклога. Два самых заметных следствия:

Оценка проводится не только раз в три года. Сегодня контроль и оценка эффективности проводятся не реже раза в три года (п. 17 ПП 1119, п. 6 приказа № 21), плюс оценка до ввода системы в эксплуатацию (ст. 19 ч. 2 п. 4 152-ФЗ). Проект добавляет оценку до начала обработки и внеплановую, после каждого компьютерного инцидента. Для платформы с круглосуточно работающим медиапарком инцидент – не редкость, поэтому оценка должна стать дешёвой и повторяемой процедурой.

Для подрядчиков появляется норматив. Сегодня поручение требует от обработчика соблюдать ст. 19 и по запросу оператора предоставлять документы (ст. 6 ч. 3 152-ФЗ). По проекту оператор заранее определяет требуемый уровень зрелости обработчика, фиксирует его и проверяет с той же периодичностью, а также после инцидента на стороне исполнителя. Требование распространяется на облака, SaaS-платформы и ИТ-подрядчиков. Если вы телемед-SaaS для клиник, этот обработчик – вы.

Все требования, сгруппированные по смыслу

Если группировать требования не по номерам пунктов, а по смыслу, получается пять групп. Ссылки даны на действующие акты; пометка «проект» означает, что формулировка может измениться.

1. Инвентаризация. Модель угроз (ст. 19 ч. 2 п. 1), тип актуальных угроз и уровень защищённости (п. 6–12 ПП 1119), утверждённый перечень лиц с доступом (п. 13 ПП 1119), учёт машинных носителей (ст. 19 ч. 2 п. 5), карта размещения баз данных в России (ст. 18 ч. 5). Проект: отдельные меры для облаков, контейнеров и API, а значит, их придётся перечислить.

2. Защита по умолчанию. Меры приказа № 21 для вашего уровня: идентификация и аутентификация (ИАФ), управление доступом (УПД), защита среды виртуализации (ЗСВ), защита систем связи и передачи данных (ЗИС), управление конфигурацией. Средства защиты, прошедшие оценку соответствия (ст. 19 ч. 2 п. 3), и сертифицированные ФСБ средства криптографической защиты (СКЗИ) там, где защита держится на криптографии.

3. Постоянная проверка. Регистрация событий безопасности (РСБ) и регистрация всех действий с персональными данными (ст. 19 ч. 2 п. 8), антивирусная защита, обнаружение вторжений, контроль (анализ) защищённости, то есть поиск и устранение уязвимостей. При угрозах 1-го и 2-го типа дополнительно может применяться тестирование на проникновение (п. 11 приказа № 21).

4. Устойчивость к атакам. Обнаружение несанкционированного доступа и реагирование на компьютерные инциденты (ст. 19 ч. 2 п. 6), восстановление изменённых или уничтоженных данных (п. 7), обеспечение доступности. Уведомления: Роскомнадзор за 24 и 72 часа (ст. 21 ч. 3.1), ГосСОПКА (ст. 19 ч. 12), для значимых объектов КИИ – НКЦКИ за 3 часа.

5. Регулярные доказательства. Оценка эффективности до ввода в эксплуатацию и не реже раза в три года, внутренний контроль и аудит (ст. 18.1), документы по запросу оператора (ст. 6 ч. 3). Проект: уровень зрелости, переоценка после инцидента, проверка обработчиков.

Нажмите, чтобы увеличить

Кратко о том, что действует сейчас и куда движется регулирование:

Что каждое требование значит для телемедицинской видеоплатформы

Типовые руководства по 152-ФЗ рисуют информационную систему одним прямоугольником. Телемед-платформа устроена сложнее. В ней есть приложение пациента, сигналинг, TURN-реле (резервные серверы, которые пересылают медиа, когда устройства не могут соединиться напрямую), SFU (Selective Forwarding Unit, медиасервер, маршрутизирующий видеопотоки в групповых звонках), конвейер записей, транскрипты, мост в МИС и ЕГИСЗ и целый ряд подрядчиков. К каждому компоненту требования применяются по-своему. В материалах о комплаенсе такую раскладку встречаешь редко, поэтому пройдём по ней подробно.

Нажмите, чтобы увеличить

Модель угроз и перечень: медиаконвейер на бумаге

Модель угроз и перечень систем кажутся бюрократией, пока не попробуешь составить их для видеоплатформы. Где находятся медданные во время приёма? В браузере пациента и в браузере врача. При прохождении через SFU: в стандартных топологиях WebRTC медиа расшифровывается на SFU, и модель обязана это отражать. Возможно, в TURN-реле, которое пересылает зашифрованные пакеты, не имея возможности их прочитать; модель должна указать и это, потому что от этого зависит оценка угроз. В хранилище записей, в транскриптах, в истории чата, в базе сигналинга, в логах (если вы были неосторожны) и у каждого подрядчика в цепочке. И каждое из этих мест, включая бэкапы, должно физически находиться в России.

Отдельный пункт модели – объём. При угрозах 3-го типа платформа со сведениями о здоровье менее чем 100 000 пациентов попадает в УЗ-3, а при превышении порога – в УЗ-2 (п. 10–11 ПП 1119). Рост базы меняет требования, поэтому планируйте уровень под целевой объём, а не под пилот. Если вы уже ведёте диаграмму границы медданных, которую мы рекомендуем, большая часть работы сделана. А если нарисовать её сегодня не получается, ваша главная проблема не в проекте приказа.

Шифрование: в канале почти всё готово, проваливаются на хранении

WebRTC, браузерный стек реального времени, на котором построен почти каждый телемед-продукт, шифрует медиа по умолчанию: обмен ключами DTLS-SRTP и шифрование полезной нагрузки SRTP обязательны в самом стандарте, режима «без шифрования» там нет. (Детали протоколов – в разделе Video Streaming: безопасность WebRTC: DTLS и SRTP.) Сигналинг и API работают поверх TLS. Российская специфика в другом: если модель угроз говорит, что угрозы в канале нейтрализуются криптографией, нужны СКЗИ, сертифицированные ФСБ, а браузерный WebRTC шифрует не по ГОСТ. Как это решение фиксируют в модели угроз и где применяют ГОСТ-TLS, рассказано в статье о шифровании, ГОСТ и СКЗИ.

С хранением ситуация другая, и именно на нём телемед-продукты проваливают проверки. Шифрование нужно хранилищу записей, базе транскриптов, архивам чатов, кэшированным вложениям, бэкапам и ноутбукам всех, кто может всё это выгрузить. Две типичные ошибки, которые стоит поискать у себя уже на этой неделе. Первая: записи в объектном хранилище зашифрованы на уровне бакета, но ссылки на них доступны любому и никогда не истекают. Вторая: «временные» буферы композитной записи на узлах SFU пишут незашифрованное медиа на локальный диск. Помните и про срок: если запись сделана, аудио- и видеоматериалы консультации хранятся 1 год (193н, п. 49–51), значит, ключи и права доступа должны сохраняться не меньше.

Вход: ЕСИА для пациента и сильная аутентификация для персонала без потери пациентов

Со стороны врача всё понятно: медработники входят через систему единого входа клиники, от вас требуется интеграция с её провайдером идентификации, а документы врач подписывает усиленной квалифицированной электронной подписью (УКЭП). Сложнее со стороной пациента. Участников телемедицинской консультации нужно идентифицировать через ЕСИА (ч. 6 ст. 36.2 323-ФЗ, п. 7 193н); Sber ID и VK ID удобны для входа, но ЕСИА не заменяют. Пациенту 78 лет, который заходит на видеоприём по ссылке из СМС, достаточно одной неудачной попытки войти через «Госуслуги», чтобы приём сорвался. Рабочие схемы есть: идентификация через ЕСИА при регистрации или перед первой консультацией, затем привязка устройства и дополнительная проверка (step-up-аутентификация) для чувствительных действий вроде доступа к записям. Как часто требовать повторную идентификацию через ЕСИА, согласуйте с юристом. Худший сценарий – за месяц до запуска добавить её ко всем входам и наблюдать, как падает доля состоявшихся визитов. Архитектура разобрана в статье об аутентификации и идентификации пациентов и врачей.

Не забудьте и о служебных входах: облачная консоль, панель оркестрации SFU, инструменты поддержки, CI/CD. Приказ № 21 не задаёт число факторов, но модель угроз, в которой администраторская консоль с доступом к медданным защищена одним паролем, вряд ли выдержит проверку. Любой вход, через который можно добраться до медданных, должен требовать второй фактор.

Сегментация, анализ защищённости, обновления: медиапарк под контролем

Для видеоплатформы сегментация сети складывается естественно: медиаплоскость (узлы SFU и TURN), плоскость сигналинга и управления, плоскость данных (записи, транскрипты, мост в МИС) и корпоративная ИТ-инфраструктура, каждая в своей зоне с контролируемыми переходами. Если сегодня с заражённого ноутбука маркетолога можно добраться по сети до хранилища записей, это проблема, которую найдёт любая модель угроз. Сегментация здесь ещё и дешёвая страховка: медиаузлы по самому своему назначению открыты в интернет больше любых других ваших серверов.

По той же причине анализ защищённости и обновления важнее всего для медиаузлов. TURN-серверы слушают публичные UDP- и TCP-порты, для этого они и нужны. SFU-узлы принимают шифрованное медиа из произвольных сетей. Критическую уязвимость в реализации TURN, в среде выполнения SFU или в ядре под ними нужно закрывать в срок, записанный в вашем регламенте управления уязвимостями, и этот срок не подстраивается под релизный цикл. Отсюда конкретные задачи: автоматическая пересборка медиаузлов (развёртывание из образов вместо долгоживущих серверов, которые патчат вручную), умение перевести трафик и заменить узлы SFU, не обрывая идущие приёмы, и сканирование, которое охватывает медиаплоскость, а не только веб-слой. Если вас пугает замена SFU-узла посреди рабочего дня, это проблема надёжности, которая лишь выглядит как вопрос комплаенса (см. статью о надёжности соединения).

Восстановление: кто отвечает за доступность

152-ФЗ требует восстанавливать данные, изменённые или уничтоженные вследствие несанкционированного доступа (ст. 19 ч. 2 п. 7), а приказ № 21 – обеспечивать доступность. Закон не называет число часов, поэтому срок восстановления задаёте вы и записываете его в SLA с клиниками. Приоритеты для телемед-платформы определяются клинической, а не технической логикой: завтрашнее расписание и возможность провести приём почти наверняка важнее архива записей за прошлый месяц. Полезное упражнение, которое мы проводим с клиентами: представьте, что в понедельник в 09:00 вашего облачного аккаунта больше нет (отказ региона, шифровальщик, неудачный запуск Terraform). Какой задокументированный и проверенный путь ведёт к первому проведённому приёму? Состояние сигналинга, учётные данные TURN, образы SFU, DNS, сертификаты моста в МИС: каждый незадокументированный шаг отнимает час, которого у вас нет. В регламенте реагирования на инциденты нужна не только техническая часть, но и раздел о коммуникациях: как обработчик вы обязаны уведомить клинику-оператора в срок, указанный в поручении (реагирование на инциденты и уведомление об утечках).

Регулярные доказательства: подрядчики, заказчики и вы сами

Сегодня проверка подрядчиков в основном договорная: подписали поручение с требованиями ст. 19 и полагаетесь на право запросить документы (из чего состоит поручение, разобрано в отдельной статье). Проект превращает проверку в регулярный обмен доказательствами. Клиники-заказчики будут задавать вам требуемый уровень зрелости и проверять его. А вы будете получать то же от каждого субподрядчика, имеющего дело с медданными: облака, видеохостинга или готовой ВКС-платформы, API транскрибации, хранилища, стека мониторинга, если он видит медданные (а он не должен).

Посчитаем плановые события за год для платформы среднего размера с шестью подрядчиками, которые работают с медданными. Два прохода анализа защищённости, один пентест, один внутренний контроль по ст. 18.1, одно обновление модели угроз, одни учения по плану действий при утечке, одно обновление перечня систем и карты данных, шесть пакетов доказательств от подрядчиков и один пакет для ваших заказчиков. Итого 2 + 1 + 1 + 1 + 1 + 1 + 6 + 1 = четырнадцать плановых событий по комплаенсу в год. Юридический минимум скромнее (оценка эффективности раз в три года), но всё остальное и есть то, чем по проекту подтверждается зрелость. Либо у этих событий есть календарь и ответственный, либо при проверке вы получите четырнадцать замечаний.

У этого сдвига есть коммерческая выгода: телемед-вендор, который по запросу может выдать клинике пакет доказательств своей защиты, закрывает сделки быстрее остальных. Фактически проект стандартизирует опросник по безопасности, на который вы и так тратите недели. Если относиться к пакету доказательств как к инструменту продаж, требование станет конкурентным преимуществом.

Сроки при инциденте: пример расчёта

Пока проект ждёт подписания, сроки при инцидентах уже действуют, и в 2026 году их стало больше. Роскомнадзор: 24 часа на первичное уведомление и 72 часа на итоги расследования (ст. 21 ч. 3.1). ГосСОПКА: 24 часа для операторов с соглашением с НКЦКИ, остальные подают сведения через Роскомнадзор (приказ ФСБ № 77). Значимый объект КИИ: не позднее 3 часов (приказ ФСБ № 547). Подрядчик уведомляет оператора в срок, указанный в поручении.

Возьмём условную дату. Мониторинг обнаруживает, что бакет с записями консультаций был открыт и его читали извне, в субботу, 14 ноября 2026 года, в 02:30. Через 3 часа, в 05:30 субботы, заказчик, если его система – значимый объект КИИ, должен сообщить в НКЦКИ. Через 24 часа, в 02:30 воскресенья, 15 ноября, истекает срок первичного уведомления Роскомнадзора. Через 72 часа, в 02:30 вторника, 17 ноября, нужно направить результаты внутреннего расследования. Выходные ни один из этих сроков не останавливают. Для договора отсюда следует: если у заказчика окно в 3 часа, ваша обязанность уведомить его должна измеряться минутами, а дежурный инженер должен иметь право разбудить ответственного за ИБ ночью. По проекту к этому добавится внеплановая оценка защищённости после инцидента; это ещё одна причина собирать доказательства автоматически.

Типичная ошибка: считать проект либо «законом», либо «шумом»

Ошибаются в обе стороны, и причина одна. Команды первого типа читают блог вендора и решают, что новый приказ уже действует (в его тексте ведь стоит 1 сентября 2026 года). Они тратят квартал на «уровень зрелости», методика расчёта которого в открытых разборах не раскрыта, а иногда ещё и покупают инструменты «соответствия-2026» под документ, которого пока нет. Команды второго типа слышат «всего лишь проект» и откладывают тему целиком. Они забывают, что действующие ПП 1119 и приказ № 21 уже требуют модель угроз, уровень защищённости и оценку эффективности, которых у многих стартапов нет, и что утечка данных о здоровье уже стоит 10–15 млн ₽, а повторная – до 500 млн ₽.

Есть и третья, чисто российская ошибка: перепутать приказы. ИСПДн коммерческой клиники подпадает под приказ № 21, а не № 117 (если это не ГИС и не госучреждение). МИС государственной больницы с 1 марта 2026 года подпадает под № 117. Платформа, которая обслуживает и тех и других, должна знать, в каком режиме работает система каждого заказчика. Правильная позиция учитывает всё сразу: соответствуйте действующим актам сегодня, а техническую часть проекта внедряйте по собственному графику, потому что это разумная инженерная практика, а не потому, что ФСТЭК назначила дату. И когда говорите заказчикам о «соответствии», уточняйте, о каком приказе речь: путаница в продающей презентации почти гарантированно заставит юристов переписывать договоры.

Что ещё может измениться до подписания

В открытых разборах проекта остаётся несколько белых пятен: шкала и методика «уровня зрелости», соотношение с уровнями защищённости ПП 1119, переходный период. Возможны разные исходы: от подписания почти в опубликованном виде с новой датой до переработки перечней мер или долгой паузы. Параллельно идут и другие процессы. Отраслевые особенности категорирования объектов КИИ здравоохранения пока существуют в виде проекта, сроки перехода значимых объектов на доверенные программно-аппаратные комплексы в открытых источниках не подтверждены, а 243-ФЗ об ИИ (с 1 сентября 2026 года) касается в основном больших фундаментальных моделей и классификацию медизделий не меняет. Следите за тремя сигналами: статус проекта ID 169583 на regulation.gov.ru, регистрация в Минюсте и публикация на publication.pravo.gov.ru, информационные сообщения ФСТЭК. Ни один правдоподобный исход не меняет инженерных рекомендаций выше; меняются только дата и документы.

Ваш план на одной странице

Мы свели статью в чек-лист для печати: пять групп требований, по каждой – контрольные точки для видеоплатформы из раскладки выше и место для отметки. Пройдите его по своей платформе за вечер; пустые клетки и есть ваш бэклог, сверху вниз.

Скачать чек-лист защиты ПДн 2026 для видеоплатформ (PDF)

Где здесь Фора Софт

Фора Софт разрабатывает видеософт с 2005 года: телемедицину, видеоконференции, стриминг, видеонаблюдение, e-learning. Работа на стыке с комплаенсом, описанная в этой статье, занимает незаметную, но большую часть каждого нашего медицинского проекта. Мы проектируем телемед-архитектуры, в которых требования заложены в саму систему, а не добавлены потом: шифрованные конвейеры записи в российской инфраструктуре, сегментированные медиаплоскости, парки SFU, которые собираются из образов и обновляются без обрыва приёмов, и доказательства для оценки эффективности, которые архитектура порождает сама. Когда новый приказ подпишут, у наших клиентов почти все доработки должны быть уже выполнены. Если вы оцениваете новую разработку или доработку существующей системы, с этого разговора и стоит начать.

Главное

• По данным на 24 сентября 2026 года проект замены приказа ФСТЭК № 21 не подписан; действуют 152-ФЗ, ПП 1119 и приказ № 21.
• Суть изменений: от набора мер «под уровень» с обоснованием компенсирующих мер к измеряемой зрелости и переоценке после каждого инцидента; для государственных систем это уже приказ № 117.
• WebRTC шифрует канал по умолчанию; продукты проваливаются на хранении (записи, транскрипты, бэкапы) и на вопросе, где нужны СКЗИ.
• Больше всего работы с медиапарком: сегментация, анализ защищённости, обновления из образов, восстановление без обрыва приёмов.
• Проект превращает поручение в обмен доказательствами: заказчик задаёт вам уровень зрелости и проверяет его.
• Сроки при инцидентах уже действуют: 3 часа для значимых объектов КИИ, 24 и 72 часа для Роскомнадзора.

Что читать дальше

• Поручение обработки ПДн и договоры с подрядчиками: контракт, на котором держится весь стек
• Шифрование для телемедицины: при передаче, при хранении, сквозное. Где нужны ГОСТ и СКЗИ
• Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек