Разбор: чем SOC 2 отличается от HIPAA и почему отчета недостаточно

Если ваш продукт работает с данными пациентов по поручению медицинской организации, вы — business associate по HIPAA. Этот статус возникает не из-за подписанной бумаги, а из-за того, что ваше ПО делает с данными. И он несет прямую ответственность.

Многие думают: «У нас есть SOC 2 Type II, значит, с комплаенсом всё в порядке». На деле SOC 2 и HIPAA отвечают на разные вопросы. Разрыв между ними — то место, где компании попадают в неприятности во время проверок безопасности у клиента.

Что такое SOC 2 и HIPAA

SOC 2 — это аттестация. Аудитор оценивает ваши контролы против критериев Trust Services, которые вы вместе с ним скоупите. Вы сами выбираете, какие критерии применять. В отчете описывается, работали ли выбранные контролы в течение периода.

HIPAA Security Rule — это регулирование. Требования заданы в 45 CFR §164.308, §164.310, §164.312, и вы их не скоупите. Часть спецификаций — обязательные, часть — addressable. Addressable не значит «опционально». Это значит, вы должны оценить, разумна ли спецификация для вашей среды; если разумна — внедрить, если нет — задокументировать обоснование.

Вот что отличает их:

Где SOC 2 оставляет вас незащищенным

Четыре пробела, которые всплывают постоянно.

Анализ рисков. §164.308(a)(1)(ii)(A) требует точную и тщательную оценку рисков для ePHI, которую вы создаете, получаете, храните или передаете. В SOC 2 тоже есть оценка рисков, но в рамках выбранных Trust Services Criteria. Это не один и тот же документ, и один не закрывает другой.

Субподрядчики. Каждый вендор, который касается данных по вашему поручению, должен иметь Business Associate Agreement (BAA) с вами. И эта обязанность передается по цепочке вниз. Облачный провайдер, система логирования, трекер ошибок, поддержка, аналитика. Если обработчик исключений отправит stack trace с идентификатором пациента в сторонний сервис без соглашения — это раскрытие.

Уведомление о нарушении. Breach Notification Rule, 45 CFR §164.410, устанавливает, что вы должны сообщить покрытой организации и в какие сроки. В SOC 2 есть критерий реагирования на инциденты. Но он не определяет регуляторные часы уведомления и его содержание.

Обучение персонала и санкции. Обязательные административные меры. В инженерно-ориентированных компаниях они часто тонкие: безопасность воспринимается как инфраструктурная задача, а не как человеческая.

Практика: пять шагов перед сделкой

Прежде чем заключать крупный контракт с медицинской системой, пройдитесь по этому списку.

1. Запишите все места, где оказываются данные пациентов: логи, очереди, кэши, бэкапы, аналитика, тикеты поддержки, всё, к чему разработчик может получить доступ при отладке.
2. Составьте список всех третьих сторон на этом пути и проверьте, есть ли с каждой BAA.
3. Проведите анализ рисков в рамках HIPAA, а не под ваши SOC 2 критерии. Сохраните документацию.
4. Документируйте решения по addressable-спецификациям с обоснованием, а не просто результат.
5. Проверьте путь уведомления о нарушении: кто принимает решение и как быстро.

Пункт 2 — самый опасный. Обычно в данных пути оказываются сервисы, которые появились до того, как кто-то вообще думал о HIPAA.

Про обновление 2026 года

Сейчас обсуждается предложенное обновление HIPAA Security Rule. Это пока только предложение, не финализировано, и ни один пункт из него не является действующим требованием. Прочитать стоит: несколько изменений указывают именно на описанные выше зоны. Но если вендор говорит вам, что новые правила уже вступили в силу, — относитесь скептически.

Вывод

Не позволяйте отчету SOC 2 подменять анализ рисков. Они отвечают на разные вопросы, и только один из них — вопрос регулятора.