Конфликт между информационной безопасностью (ИБ) и ИТ почти всегда выглядит как спор людей: «ИБ всё запрещает» vs «ИТ всё игнорирует».

Но на деле это системная проблема, потому что он воспроизводится даже при смене сотрудников — причина в устройстве целей, ответственности и процессов.

1. Почему конфликт возникает снова и снова

1.1. Разные метрики успеха

  • ИТ оценивают по доступности и скорости изменений (чтобы «работало» и «быстро»).
  • ИБ — по снижению рисков и соответствию требованиям (чтобы «не случилось»).
⚡ Когда табло разное — решения неизбежно конфликтуют.

1.2. Разная ответственность за последствия

  • Остановка сервиса бьёт по ИТ сразу (SLA, пользователи).
  • Инцидент бьёт по ИБ громко и «официально» (расследования, аудит, регулятор).
⚡ Обе стороны защищают свою зону боли.

1.3. Нет понятного механизма «кто принимает риск»

Если не определён владелец риска, ИБ вынуждена быть «запрещающей», а ИТ — «продавливающей». Это превращает рабочий спор в войну.

1.4. ИБ подключают слишком поздно

⚠️ ИБ зовут в конце, когда всё уже выбрано и почти внедрено. Тогда замечания ИБ выглядят как саботаж, хотя это просто поздняя точка контроля.

1.5. Не хватает опоры в данных и стандартах

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

2. Что реально снижает конфликт

  • Единые правила принятия риска: кто подписывает исключение, на какой срок, с какими компенсационными мерами.
  • SLA на согласования + понятные критерии «типовой/нетиповой» запрос.
  • Безопасные стандарты «по умолчанию» (golden baseline), чтобы «делаешь по шаблону — не воюешь за каждую правку».
  • Раннее участие ИБ в архитектуре и планировании изменений.

3. Вместо вывода: договор между ИТ и ИБ

🤝 Договор между ИТ и ИБ

  1. Мы защищаем бизнес: доступность + управляемый риск.
  2. Риск принимает владелец (руководитель/бизнес), не инженер.
  3. Исключение = срок + компенсации + план закрытия.
  4. «По стандарту» — быстро; «вне стандарта» — через понятный процесс.
  5. Инциденты разбираем по причинам, а не по виноватым.

Настоящий диалог ИБ и ИТ начинается не с требований, а с общего понимания:
мы защищаем бизнес, а не свои зоны ответственности.

4. Чек-лист для самопроверки

Пройдите по каждому пункту и отмечайте кликом, что уже сделано. Вы можете сохранить отмеченный чек-лист в формате Word или сбросить все отметки.

Выполнено: 0 из 12
  • Определены владельцы рисков (бизнес, а не ИБ или ИТ)
  • Единые правила принятия рисков и оформления исключений
  • SLA на согласования со стороны ИБ
  • Golden baseline — безопасные конфигурации «по умолчанию»
  • ИБ участвует в проектах с этапа архитектуры
  • Есть общая инвентаризация систем и их критичности
  • Конфликты разбираются на уровне процессов, а не личностей
  • Инциденты анализируются по причинам, а не по виноватым
  • Есть регламент взаимодействия ИБ и ИТ
  • Проводятся совместные встречи ИБ и ИТ для планирования
  • Метрики ИБ и ИТ синхронизированы с бизнес-целями
  • Есть культура совместного решения проблем, а не перекладывания ответственности

При сохранении в Word отметки (✓) и прогресс будут включены в документ.

5. Как компания МАСО ИТ помогает

Как МАСО ИТ освещает эту тему в программах и курсах

Мы учим ИБ и ИТ говорить на одном языке, выстраивать процессы совместной работы и принимать решения на основе рисков, а не эмоций. Наши курсы включают модули по управлению конфликтами, построению комплаенс-систем и интеграции ИБ в ИТ-процессы.

Подход в обучении

  • Кейсы из реальной практики: разбор конфликтов ИБ и ИТ и их решений.
  • Ролевые игры: отработка переговоров и совместного принятия решений.
  • Практические инструменты: как выстраивать единые правила и процессы.
  • Обучение руководителей: как управлять взаимодействием ИБ и ИТ.

Связанные материалы (статьи в блоге МАСО ИТ)

6. FAQ

Почему конфликт ИБ и ИТ возникает даже при хороших сотрудниках?
Потому что причина не в людях, а в системных противоречиях: разные метрики, разная ответственность и отсутствие единых правил принятия рисков.
Кто должен принимать риск в конфликте ИБ и ИТ?
Риск должен принимать владелец риска — как правило, это руководитель бизнес-направления или топ-менеджмент, а не ИБ или ИТ-инженер.
Как перестать спорить о каждой правке?
Внедрите golden baseline — безопасные стандарты «по умолчанию». Всё, что в рамках стандарта, согласовывается быстро, всё, что выходит за рамки — по чёткому процессу.
Что делать, если ИБ подключают слишком поздно?
Внедрите правило: ни один проект не утверждается без участия ИБ на этапе архитектуры. Это должно быть закреплено в регламенте.
Как разбирать инциденты, чтобы не искать виноватых?
Используйте подход blameless post-mortem: разбирайте причины, а не людей. Фокусируйтесь на том, что сломалось в процессах, а не кто ошибся.
Может ли ИБ и ИТ работать без конфликтов?
Полностью избежать конфликтов невозможно, но их можно перевести в конструктивное русло — через единые правила, раннее вовлечение и общую цель: защиту бизнеса.

7. Об авторе

Халяпин Владислав — эксперт в области информационной безопасности и преподаватель МАСО ИТ. Имеет практический опыт внедрения систем защиты информации на объектах КИИ и в коммерческих организациях. Специализируется на вопросах управления рисками, разработке технических заданий и обучении персонала.

Страница автора: https://maso-it.ru/author

Хотите наладить диалог между ИБ и ИТ в вашей компании?

Запишитесь на консультацию по курсам →