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

Автор: Николай СапуновОбновлено: август 202621 мин чтения
Содержание статьи +

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

Кратко

Поручение оператора на обработку персональных данных – договор, без которого клиника не вправе допустить подрядчика к данным пациентов. Что в нём должно быть, перечисляет ст. 6 ч. 3 152-ФЗ: данные и действия с ними, цели, конфиденциальность, хранение в российских базах, меры защиты, уведомление об инцидентах и документы по запросу. Требование распространяется на всю цепочку, по которой идут данные: облако, видеосервис, распознавание речи, SMS-шлюз, аналитику. Если хотя бы у одного звена нет договорных условий, нарушением становится сам поток данных, утечка для этого не нужна. Шифрование договор не заменяет, а иностранный подрядчик для медданных почти всегда исключён: мешают локализация (ст. 18 ч. 5), правила трансграничной передачи (ст. 12) и ответственность наравне с оператором (ст. 6 ч. 6). Статья переводит 152-ФЗ и врачебную тайну в продуктовые решения (реестр подрядчиков, сроки уведомления в часах, отказ от «удобных» зарубежных SDK), к ней прилагается одностраничный чек-лист.

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

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

Договор перед выдачей ключа

Основные понятия мы разобрали в базовой статье о 152-ФЗ и врачебной тайне, а здесь поможет простая аналогия. Данные пациентов – это здание, а поручение – обещание, которое подрядчик подписывает до того, как получит от него ключ. Ключ получает любая компания, которая работает с данными по заданию клиники, и 152-ФЗ запрещает выдавать ключи без договора с нужными условиями.

Правила записаны в ст. 6 152-ФЗ (в редакции 266-ФЗ от 14.07.2022). Оператор, то есть тот, кто определяет цели и состав обработки (обычно медорганизация), вправе поручить обработку другому лицу на основании договора (ч. 3). Часть 3 начинается с оговорки «с согласия субъекта, если иное не предусмотрено федеральным законом». Как она применяется к медданным, которые клиника обрабатывает без согласия в медицинских целях, решает юрист клиники; с инженерной точки зрения надёжнее, когда согласие и политика оператора прямо упоминают обработчиков. Лицо, обрабатывающее данные по поручению (дальше – обработчик), соблюдает правила 152-ФЗ, конфиденциальность и меры защиты, а собственное согласие пациента ему не нужно (ч. 4).

От трёх свойств этой конструкции зависит архитектура. Первое: поручение – не формальность. Без него передача данных подрядчику означает обработку без основания, а для медорганизации ещё и ставит вопрос о врачебной тайне, даже если ни одна запись никуда не утекла. Второе: ответственность ступенчатая. Перед пациентом за действия обработчика отвечает оператор, обработчик отвечает перед оператором (ч. 5); если обработчик иностранный, перед пациентом отвечают оба (ч. 6). Третье: требования передаются вниз по цепочке. Отдельной нормы о «субпоручении» в законе нет, поэтому цепочку выстраивают договорами: оператор разрешает привлечь конкретных субподрядчиков, а условия ч. 3 переходят на каждого из них. Проверять приходится всю цепочку, а не отдельные звенья.

Следуйте за данными: в цепочке не должно быть разрывов

Возьмём типичный проект. Сеть клиник заказывает у вашей компании видеоприёмы. Платформа работает в российском облаке, проводит звонки через видеосервис, отправляет аудио приёмов в сервис распознавания речи, рассылает пациентам SMS-напоминания и собирает продуктовую аналитику. Посчитаем договоры. Клиника даёт вам поручение (№ 1). Вы заключаете договоры с условиями обработки с облачным провайдером (№ 2), видеосервисом (№ 3), сервисом распознавания речи (№ 4), SMS-шлюзом (№ 5) и подрядчиком по аналитике (№ 6). Если сервис распознавания запускает модели в облаке стороннего провайдера, появляется седьмое звено – договор между ним и этим облаком. Подписываете его не вы, но ваш договор должен этого требовать, а оператор – об этом знать.

Рисунок 1. Цепочка поручений типичного телемед-проекта. Каждый узел, где медданные попадают на чужую инфраструктуру, требует договорных условий по ст. 6 ч. 3, поэтому проверять нужно всю цепочку, а не отдельные звенья.

Итог обычно удивляет команды. Одно поручение от клиники-оператора и пять договоров с подрядчиками: 1 + 5 = 6 подписанных документов до первого приёма в продакшене, и это ещё скромный стек. Добавьте сервис email-рассылок, трекер ошибок, который видит тела запросов, и внешнюю службу поддержки с доступом к тикетам: 6 + 3 = 9. Реестр подрядчиков совпадает с картой медданных. Если модель угроз показывает, что данные пациентов куда-то попадают, это место должно быть закрыто договором, иначе придётся менять архитектуру.

Ещё два правила не дают цепочке ослабнуть. Условия для субподрядчиков не должны быть мягче тех, что пришли от оператора: по мере передачи вниз обязательства не размываются. И если вы знаете, что подрядчик нарушает условия, но продолжаете передавать ему данные, вы сами нарушаете поручение клиники. Сроки здесь жёсткие: неправомерную обработку оператор обязан прекратить в течение 3 рабочих дней, в том числе добиться её прекращения у обработчика, а если сделать обработку правомерной нельзя – уничтожить данные в течение 10 рабочих дней (ст. 21 ч. 3). Хотите вы того или нет, эти сроки становятся вашими SLA.

Кому поручение не нужно и где граница обманчива

Не каждый подрядчик на вашей схеме – обработчик. Если точно знать границы, можно избежать и лишних бумаг, и ложной уверенности.

Ваши сотрудники. Работники в вашем прямом подчинении обработчиками не являются: для них нужны трудовой договор, допуск, локальные акты, обязательство о неразглашении и ознакомление с требованиями (ст. 18.1), а не договор с самим собой.

Самостоятельные операторы. Страховщик ДМС, получающий данные для оплаты помощи, или платёжный сервис, через который проходит оплата приёма, обрабатывают данные в собственных целях и на собственных основаниях. Это отдельные операторы, а не ваши субподрядчики, и вопрос к ним другой: на каком основании вы передаёте данные и что именно передаёте. Граница определяется содержанием: платёжному сервису и облачной кассе для чека нужны сумма и наименование услуги, но не жалоба пациента и не диагноз. Подробнее – в статье о платежах, ДМС, ОМС и фискализации.

Подрядчик, который не получает данных пациентов. Аналитика, которая видит только агрегаты без возможности выделить человека, или сервис, работающий на синтетических данных, в цепочку не входят. Но граница тонкая: псевдонимизированные записи, где ID пациента заменён токеном, а таблица соответствия хранится у вас, остаются персональными данными. Как обезличивать по-настоящему, рассказано в статье об обезличивании и аналитике медданных.

Отдельно о ловушке «мы всё шифруем». Команды часто считают, что шифрование данных до отправки выводит провайдера хранения из-под требований. Мы придерживаемся консервативной позиции: облако, в котором лежат зашифрованные записи пациентов, остаётся звеном цепочки. Если у провайдера нет ключа, меняется распределение мер защиты, но не обязанность оператора знать, где лежат данные. Ст. 18 ч. 5 говорит о любых базах на территории России, а не только о незашифрованных, а 193н (п. 37) требует сообщить пациенту место хранения материалов. Шифрование и поручение решают разные задачи, и нужны оба.

Рисунок 2. Как классифицировать подрядчика. Безопасное правило по умолчанию для всего, что хранит или обрабатывает данные пациентов: считать его обработчиком и сначала заключить договор с условиями ст. 6 ч. 3.

Иностранный подрядчик: почему для медданных ответ почти всегда «нет»

Для зарубежного подрядчика в ст. 6 есть отдельная норма: если обработка поручена иностранному физическому или юридическому лицу, перед пациентом за его действия отвечают и оператор, и этот подрядчик (ч. 6). Но для медданных вопрос обычно решают раньше две другие статьи.

Локализация. С 1 июля 2025 года запись, систематизация, хранение и другие операции с персональными данными граждан России в базах данных за рубежом прямо запрещены (ст. 18 ч. 5 в редакции 23-ФЗ). Требование ч. 5 ст. 18 входит в обязательное содержание поручения (ст. 6 ч. 3), то есть обработчик обязан соблюдать его ещё и по договору. Штраф за нарушение – до 6 млн ₽, за повторное – до 18 млн ₽ (ч. 8 и 9 ст. 13.11 КоАП).

Трансграничная передача. До начала передачи данных за рубеж оператор уведомляет Роскомнадзор и оценивает получателя, а регулятор вправе передачу запретить или ограничить (ст. 12, с 1 марта 2023 года). Для данных о здоровье, то есть специальной категории, это тяжёлая процедура с непредсказуемым итогом, и строить на ней продуктовый поток неразумно.

Для телемедицины отсюда следует, что зарубежный сервис не может быть звеном, через которое проходят данные пациентов: ни облако, ни ИИ-API, ни аналитика, ни рассылки. Это касается и сервисов с российской вывеской, у которых модель, логи или поддержка находятся у зарубежного партнёра: проверяйте не бренд, а страну, где физически обрабатываются данные. Подробности – в статье о локализации и трансграничной передаче медданных.

Врачебная тайна у подрядчиков

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

Отдельного пункта о передаче врачебной тайны ИТ-подрядчику в ст. 13 нет, поэтому надёжная конструкция строится вокруг поручения. Подрядчик работает как часть информационной системы оператора, в его целях и по его правилам, а сотрудники подрядчика с доступом к данным связаны обязательством о неразглашении. В договоре это превращается в три пункта: конфиденциальность и неразглашение врачебной тайны; перечень ролей подрядчика с доступом к данным (конкретные функции, а не «вся компания»); обязанность вести журнал такого доступа и выдавать его оператору по запросу. Технически всё устроено так же, как у вашей команды: ролевой доступ и журнал аудита, а для поддержки – метрики качества звонка вместо карты пациента.

Что прописать в договоре: от закона к бэклогу

Обязательное содержание поручения не придумано практиками, это перечень из ч. 3 ст. 6. К нему добавляются условия, которых закон прямо не требует, но без которых цепочку не удержать. Каждое условие во что-то превращается в продукте или процессе, поэтому этот раздел стоит читать с открытым бэклогом.

#Условие договораОткудаЧто это значит для продукта
1Перечень персональных данныхст. 6 ч. 3Схема данных подрядчика: только поля, нужные для его функции (минимизация, ст. 5)
2Перечень действий с даннымист. 6 ч. 3Права сервисного аккаунта и API: «хранить и отдавать», а не «всё»
3Цели обработкист. 6 ч. 3Запрет обучать модели и «улучшать сервис» на данных пациентов; «данные всё равно есть» – не разрешение
4Конфиденциальность и неразглашение врачебной тайныст. 6 ч. 3; ст. 13 323-ФЗПеречень ролей подрядчика с доступом, обязательства сотрудников, журнал доступа
5Хранение в базах на территории Россиист. 6 ч. 3 → ст. 18 ч. 5Регион хранения; бэкапы, логи и реплики – тоже в РФ; перенос – только с согласия оператора
6Меры по ст. 18.1 и требования к защите по ст. 19ст. 6 ч. 3Уровень защищённости, меры приказа ФСТЭК № 21, СКЗИ там, где защита держится на криптографии
7Уведомление оператора об инцидентах по ч. 3.1 ст. 21ст. 6 ч. 3Срок в часах, канал и формат сообщения; строка в регламенте реагирования на инциденты
8Документы о соблюдении требований по запросу, в том числе до начала обработкист. 6 ч. 3Папка доказательств: модель угроз, аттестаты, результаты оценки эффективности мер
9Субподрядчики – только с согласия оператора и на тех же условияхдоговорная практикаПроверка при подключении: нет субподрядчика без договора и строки в реестре
10Запросы пациентов, прекращение обработки, возврат и уничтожениест. 20, 21API выгрузки, исправления и удаления; удаление из реплик и бэкапов; акт об уничтожении

Пункт 10 в медицине требует осторожности. На запрос пациента о его данных оператор отвечает в течение 10 рабочих дней (ст. 20), и ваша функция выгрузки помогает ему уложиться в срок. Ст. 21 даёт 30 дней на уничтожение данных после достижения цели или отзыва согласия, но с оговоркой: иное может предусматривать закон, а у медицинской документации и материалов телемедицинских консультаций собственные сроки хранения (193н, п. 49–51; приказ 209н). Поэтому при расторжении договора обработчик сначала возвращает данные оператору в пригодном формате и только потом уничтожает свои копии. Если порядок завершения работы нельзя выполнить на практике, считайте, что этого пункта в договоре нет.

Второй проблемный пункт – третий. Условие «мы можем использовать данные клиентов для улучшения продукта» приемлемо для телеметрии серверов подрядчика, но превращается в готовое нарушение, если распространяется на данные пациентов. Рядом ищите право подрядчика обезличить данные и оставить результат себе. Такое решение оператор принимает осознанно и письменно, иначе чужой продукт будет обучаться на приёмах ваших пациентов.

Как прочитать договор подрядчика за двадцать минут

Крупные облака и платформы обычно предлагают договор по принципу «принимай как есть», поэтому важно не умение торговаться, а точное понимание, что проверить, прежде чем на договор полагаться. Пять проверок закрывают большую часть риска.

Охват: какой сервис, какой сегмент. Аттестат и условия обработки распространяются на названные в них сервисы и сегменты, а не на всё, что есть у провайдера. Аттестат облака на УЗ-1 относится к аттестованному сегменту; разместить медданные в обычном значит выйти за пределы того, на что вы ссылаетесь в модели угроз. Проверочный вопрос: покрыт ли письменно именно тот сервис в том сегменте и регионе, за который мы платим?

Ваши обязанности по настройке. Облачные условия строятся на разделённой ответственности: провайдер защищает инфраструктуру, вы настраиваете сервисы. Аттестат провайдера не распространяется на ваше приложение и задним числом не оправдывает публичный бакет с записями. Подписанный договор плюс настройки по умолчанию – самый распространённый источник ложной уверенности.

Срок уведомления об инциденте. У оператора 24 часа на первичное уведомление Роскомнадзора и 72 часа на итоги расследования (ст. 21 ч. 3.1), а если его система – значимый объект КИИ, то 3 часа на сообщение в НКЦКИ (приказ ФСБ № 547). Отсчёт идёт с момента выявления. Поэтому в договорах с подрядчиками срок указывают в часах, а не в днях и не формулировкой «без неоправданной задержки». Знайте и входящие сроки (что подрядчики должны вам), и исходящий (что требует поручение клиники) и впишите оба в регламент реагирования на инциденты.

Порядок расторжения. Пункт «вернуть или уничтожить» выглядит понятным, пока не спросишь подрядчика, как именно он это сделает. В какие сроки данные удаляются из реплик и бэкапов? Будет ли акт об уничтожении? Можно ли сначала выгрузить данные в пригодном формате?

Особенности ИИ-подрядчиков. Сервисы распознавания речи, ИИ-ассистенты для документирования приёма и языковые модели становятся обработчиками, как только к ним попадает аудио или текст приёма. Письменно проверяйте три вещи: данные не используются для обучения; обработка и логи остаются в России; договор покрывает именно тот API или режим (облако провайдера или установка в вашем контуре), которым вы пользуетесь. «Сервис российский» и «наш поток обрабатывается в России по поручению» – два разных факта. Подробнее – в статье о слое комплаенса и безопасности клинического ИИ.

Рисунок 3. Двадцатиминутная проверка договора подрядчика. Начинайте с сервиса и сегмента: чаще всего ложную уверенность даёт настоящий аттестат, выданный на другой сегмент.

Телемед-стек по подрядчикам

Ниже карта типичного телемед-стека на 2026 год. Категории стабильны, а конкретные сервисы, сегменты и условия меняются, поэтому подтверждайте их у подрядчика письменно, до того как к нему пойдут медданные.

Слой стекаПримеры (2026)Можно пустить медданные?На что смотреть
Облачная инфраструктураYandex Cloud, Cloud.ru, Selectel, MWSДа – в аттестованном сегменте, по договору с условиями обработкиАттестат покрывает инфраструктуру провайдера, а не ваше приложение; уровень сегмента VK Cloud уточняйте
Видеосервисы и SDKVoximplant, SaluteJazz SDK, VK Звонки API, TrueConfУточняйте письменноГде хранятся записи, кто видит медиа, подписывает ли подрядчик условия обработки
Свой SFU и TURNmediasoup, Janus, LiveKit OSS, JitsiПоручение вендору не нужно: данные к нему не уходятВся защита ложится на вашу команду и облако – см. свой видеослой или готовое решение
Распознавание речи и ИИSaluteSpeech, Yandex SpeechKit (в т. ч. on-prem), GigaChat, Alice AI; Whisper on-premОблачный российский – по поручению; в своём контуре данные никуда не уходятЗапрет обучения на ваших данных, логи в РФ, охват конкретного API
Интеграционные шиныN3.Health, МедФлекс, прямой мост в МИСДа – это суть их работыЦепочки субподрядчиков здесь длинные; запросите их перечень
Продуктовая аналитикаЗарубежные SDK; собственный конвейер в РФЗарубежные – нетМедданным туда нельзя; используйте аналитику на своих серверах в РФ или передавайте только агрегаты
SMS, email, pushТиповые сервисы рассылокОбычно нет – без порученияНапоминание без специальности и диагноза; push доставляется через инфраструктуру производителей мобильных ОС
Трекинг ошибок и мониторингОблачные и на своих серверахПо-разномуВ любом случае лучше вычищать медданные до отправки
Платежи и чекиЮKassa, CloudPayments, Т-Касса, Robokassa; облачные кассыСамостоятельные операторы в своей частиСумма и наименование услуги – да; жалоба и диагноз – нет

Условия зависят от подрядчика, продукта, сегмента и даты. Таблица – карта категорий на 2026 год, она не заменяет письменного подтверждения из чек-листа ниже.

Отсюда короткий список сервисов, которые нельзя подключать к контуру с медданными, какими бы удобными они ни были: зарубежные SDK аналитики, рекламы и сбора краш-репортов; зарубежные ИИ-API для аудио, текста и снимков приёма; зарубежные облака, хранилища и площадки для бэкапов; почта и мессенджеры на зарубежных серверах для пересылки медданных; личные облачные диски и аккаунты сотрудников; любой сервис, с которым нет договора с условиями ст. 6 ч. 3.

Где рвётся цепочка

Типичные ошибки, которые регулярно находят при проверках. Аналитический SDK, который инициализируется при запуске приложения и отправляет на зарубежный сервер IP-адрес, идентификатор устройства и URL страницы приёма; в связке с пациентом это медданные. Записи сессий, синхронизированные с облачным диском на личном аккаунте разработчика: этот аккаунт не упомянут ни в одном договоре и ни в одной модели угроз. Напоминания через SMS-шлюз без поручения: «Напоминание: контрольный приём у дерматолога после биопсии» – это сведения о здоровье прямо в тексте сообщения. Договор на аттестованный сегмент облака, тогда как хранилище развёрнуто в обычном. Подрядчик, который незаметно привлёк субподрядчика, и ваш договор на того уже не распространяется. И самый незаметный вариант: договор согласовали, отправили и так и не подписали.

Рисунок 4. Где рвётся цепочка. Сам видеозвонок редко становится нарушением. Нарушения возникают на периферии: в аналитике, уведомлениях, копиях записей и побочных каналах, которые никто не оформил.

Разрыв почти никогда не находится на основном видеопути, который проверяют все. Он на той же периферии, где случается большинство провалов в защите медданных в телемедицине.

Сколько стоит разрыв

Цену разрыва задают составы ст. 13.11 КоАП в редакции 420-ФЗ (с 30 мая 2025 года, суммы для юрлиц). Обработка с нарушением закона – 150–300 тыс. ₽ (ч. 1). Нарушение локализации – до 6 млн ₽, повторное – до 18 млн ₽ (ч. 8 и 9). Неуведомление Роскомнадзора об утечке – 1–3 млн ₽ (ч. 11). Утечка специальных категорий, включая данные о здоровье, – 10–15 млн ₽ (ч. 16), повторная – 1–3% выручки, но не менее 25 млн и не более 500 млн ₽ (ч. 18). Кроме того, действует уголовная ст. 272.1 УК РФ (с 11 декабря 2024 года).

Разберём один сценарий. Напоминания о приёмах для 200 пациентов в день уходят через SMS-шлюз без поручения, с текстом вроде «контрольный приём после биопсии». За 90 дней это 200 × 90 = 18 000 пациентов, чьи сведения о здоровье оказались у подрядчика без основания. Если у подрядчика случится утечка, для обычных персональных данных 18 000 субъектов попадают в диапазон ч. 13 (5–10 млн ₽). Но утекают сведения о здоровье, поэтому применяется ч. 16: 10–15 млн ₽ уже при первой утечке. Для сети клиник с выручкой 2 млрд ₽ штраф за повторную утечку по ч. 18 считается так: 2 000 000 000 × 1% = 20 млн ₽, это ниже минимума, значит, 25 млн ₽; 2 000 000 000 × 3% = 60 млн ₽ – верхняя граница. Перед пациентом отвечает оператор, обработчик отвечает перед оператором (ст. 6 ч. 5), и свои потери клиника по договору переложит на вас.

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

Поручение в 2026 году: от подписи к доказательствам

С 2022 года поручение – не разовая подпись, а постоянный обмен доказательствами. Обработчик обязан по запросу оператора в течение всего срока поручения, в том числе до начала обработки, предоставлять документы и иную информацию, подтверждающие принятие мер и соблюдение требований (ст. 6 ч. 3 в редакции 266-ФЗ). Для обработчика это значит, что папка доказательств (модель угроз, уровень защищённости, аттестаты инфраструктуры, результаты оценки эффективности мер, перечень субподрядчиков) должна существовать до первого запроса, а не собираться за ночь.

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

Ещё одно требование делает реестр подрядчиков публичным: порядок телемедицины (приказ Минздрава 193н, п. 37) обязывает раскрывать пациенту на сайте или в приложении в том числе оператора информационной системы и место хранения материалов консультаций. Если схему хранения нельзя описать пациенту одним ясным предложением, её не удастся внятно объяснить и проверяющему.

Проведите аудит на этой неделе

Всё сказанное сводится к упражнению из четырёх шагов, которое продуктовая команда проходит за вечер, на первом круге без юристов.

  1. Инвентаризация. Выпишите из карты медданных каждую систему и каждого подрядчика, включая неочевидные: трекеры ошибок, аналитические хранилища, сервисы уведомлений, места хранения бэкапов, внешнюю поддержку.
  2. Классификация. Для каждого определите: обработчик по поручению, самостоятельный оператор, сотрудник или «данных пациентов не касается». Используйте рисунок 2; всё, что хранит данные, по умолчанию считайте обработчиком. Отдельно отметьте страну, где физически обрабатываются данные.
  3. Проверка. Для каждого обработчика: договор с условиями ст. 6 ч. 3 подписан обеими сторонами и лежит в архиве; конкретный сервис и сегмент покрыты письменно; настройка соответствует вашей модели угроз; срок уведомления об инциденте в часах внесён в регламент реагирования; перечень субподрядчиков актуален и согласован с оператором.
  4. Исправление. Для каждого разрыва: подписать договор, перейти в покрытый договором сегмент, заменить подрядчика или перестроить поток так, чтобы данные пациентов до него не доходили.

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

Версия для печати: скачайте чек-лист проверки подрядчиков. На одной странице – классификация подрядчика, обязательные условия поручения, пять проверок договора и поля реестра. Расширенная версия для подготовки к проверке, с доказательствами по каждой мере, – в чек-листе готовности по 152-ФЗ и 323-ФЗ.

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

Фора Софт делает видеософт с 2005 года, среди 250+ выпущенных проектов есть телемедицинские платформы. Цепочку поручений мы считаем исходным условием архитектуры, а не приложением к ней. Когда мы оцениваем телемед-проект, карту подрядчиков и границу медданных рисуем одновременно: каждый компонент либо закрывается договором с условиями обработки в России, либо разворачивается в вашем контуре, либо по своему устройству не видит данных пациентов. На практике это выглядит так: конвейеры записи в аттестованном сегменте российского облака, распознавание речи в собственном контуре или у подрядчика по поручению, аналитика, которая получает только обезличенные события. Если продукту предстоит проверка по 152-ФЗ, дешевле всего закрыть разрывы до подписания договоров с подрядчиками.

Главное

  • Нет поручения – нет медданных: нарушением считается сама передача без основания, даже если утечки не было.
  • Обязательное содержание поручения задаёт ст. 6 ч. 3: данные, действия, цели, конфиденциальность, локализация, меры по ст. 18.1 и 19, уведомление об инцидентах, документы по запросу.
  • В цепочке не должно быть разрывов: субподрядчики работают на тех же условиях и с ведома оператора.
  • Перед пациентом отвечает оператор, обработчик – перед оператором; иностранный обработчик отвечает наравне с оператором, а для медданных его исключают ещё и локализация, и ст. 12.
  • Шифрование не заменяет договор; аттестат облака распространяется на его сегмент, а не на ваше приложение.
  • Срок уведомления от подрядчика – в часах: у оператора 24 часа на Роскомнадзор, у значимого объекта КИИ – 3 часа.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.