Политика работы с подрядчиками: что в ней должно быть с точки зрения ИБ

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

Подрядчики перестали быть вспомогательным звеном. Они хранят данные в облаке, разрабатывают софт, обслуживают серверы и часто имеют доступ к системам на уровне штатных сотрудников. Вместе с этим доступом, приходят риски. Самые громкие кибератаки последних лет объединяет одно: взлом шел не напрямую, а через поставщика.

В условиях существующих угроз, политика должна решать следующие конкретные задачи:

1. Превращать требования безопасности в обязательства, которые можно предъявить
Когда подрядчик подписывает договор с конкретными пунктами про шифрование данных и сроки уведомления об утечках, это уже не пожелание. Это условие, за невыполнение которого он отвечает. ISO/IEC 27001 требует согласовывать такие требования с каждым поставщиком в контроле A.5.20.

2. Задавать единый подход внутри компании
Политика устанавливает общий стандарт и минимальные требования, которые должны соблюдаться, обеспечивая единую основу для работы с подрядчиками.

3. Помогать исполнять требования закона
Контроль поставщиков важен для выполнения требований сразу нескольких уровней.

• Федеральный закон № 152-ФЗ «О персональных данных» требует оформлять поручение обработки персональных данных третьему лицу договором или иным правовым актом. При этом ответственность оператора перед субъектом данных сохраняется. В зависимости от отрасли и типа систем применяются дополнительные требования.
• Для государственных информационных систем действует Приказ ФСТЭК России № 117, для значимых объектов КИИ – Приказ № 239 и Федеральный закон № 187-ФЗ.
• В финансовом секторе обязательны требования Банка России (ГОСТ Р 57580.1).

Поэтому, закрепление требований к поставщикам в договорах, контроль их доступа и проверка выполнения мер ИБ, это одновременно элемент риск-менеджмента и соблюдение обязательных регуляторных требований.

4. Сокращать ущерб при инцидентах
Когда сроки уведомления, порядок совместного расследования и обязательства по возмещению прописаны заранее, команды сразу переходят к устранению последствий.

5. Обеспечивать прозрачность цепочки поставок
Поставщик вправе привлекать к исполнению обязательств других лиц, а без договорных ограничений заказчик узнаёт об этом уже постфактум. ISO/IEC 27001 в разделе A.5.21 требует управлять информационными рисками всей цепочки поставок.

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

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

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

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

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

Однократная оценка контрагента на этапе заключения договора не обеспечивает достаточного уровня контроля. В течение срока действия договора у подрядчика могут произойти изменения, существенные с точки зрения информационной безопасности. Например, привлечение новых субподрядчиков, смена технологий или программного обеспечения, истечение срока действия сертификатов. Стандарт ISO/IEC 27001 в разделе A.5.22 устанавливает необходимость о непрерывном мониторинге контрагентов на протяжении сотрудничества. Политика должна предусматривать регулярный контроль и периодический аудит контрагентов, а также основания для проведения внеплановых проверок.

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

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

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

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

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

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

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

1. С чего начать внедрение политики, если её ещё нет?
Первым делом необходимо собрать список текущих поставщиков и зафиксировать, у кого и к каким системам есть доступ. Далее необходимо закрепить ответственного за работу с контрагентами и добавить базовые требования по безопасности в новые договоры. Полноценный документ можно дорабатывать постепенно.

2. Чем отличается политика работы с подрядчиками от NDA?
NDA закрывает только один аспект, это неразглашение информации. Политика работы с поставщиками охватывает весь цикл: отбор подрядчика, условия договора, управление доступом, реагирование на инциденты и завершение сотрудничества. NDA обычно становится одним из документов в рамках такой политики.

3. Как часто пересматривать политику?
Как правило, раз в год. Если рассматривать внеплановый пересмотр, то при изменениях в законодательстве, крупных инцидентах или существенных изменениях в ИТ-инфраструктуре компании.