Найти в Дзене

Конфликт ИБ и ИТ: почему он системный, а не личный

Конфликт между информационной безопасностью (ИБ) и ИТ почти всегда выглядит как спор людей: «ИБ всё запрещает» vs «ИТ всё игнорирует». Но на деле это системная проблема, потому что он воспроизводится даже при смене сотрудников — причина в устройстве целей, ответственности и процессов.
Почему конфликт возникает снова и снова
1) Разные метрики успеха
ИТ оценивают по доступности и скорости изменений (чтобы “работало” и “быстро”).
ИБ — по снижению рисков и соответствию требованиям (чтобы “не случилось”).
Когда табло разное — решения неизбежно конфликтуют.
2) Разная ответственность за последствия
Остановка сервиса бьёт по ИТ сразу (SLA, пользователи).
Инцидент бьёт по ИБ громко и “официально” (расследования, аудит, регулятор).
Обе стороны защищают свою зону боли.
3) Нет понятного механизма “кто принимает риск”
Если не определён владелец риска, ИБ вынуждена быть “запрещающей”, а ИТ — “продавливающей”. Это превращает рабочий спор в войну.
4) ИБ подключают слишком поздно
ИБ зовут

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

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

1) Разные метрики успеха

ИТ оценивают по доступности и скорости изменений (чтобы “работало” и “быстро”).

ИБ — по снижению рисков и соответствию требованиям (чтобы “не случилось”).

Когда табло разное — решения неизбежно конфликтуют.

2) Разная ответственность за последствия

Остановка сервиса бьёт по ИТ сразу (SLA, пользователи).

Инцидент бьёт по ИБ громко и “официально” (расследования, аудит, регулятор).

Обе стороны защищают свою зону боли.

3) Нет понятного механизма “кто принимает риск”

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

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

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

5) Не хватает опоры в данных и стандартах

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

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

Единые правила принятия риска: кто подписывает исключение, на какой срок, с какими компенсационными мерами.

SLA на согласования + понятные критерии “типовой/нетиповой” запрос.

Безопасные стандарты “по умолчанию” (golden baseline), чтобы “делаешь по шаблону — не воюешь за каждую правку”.

Раннее участие ИБ в архитектуре и планировании изменений.

Вместо вывода:

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

1. Мы защищаем бизнес: доступность + управляемый риск.

2. Риск принимает владелец (руководитель/бизнес), не инженер.

3. Исключение = срок + компенсации + план закрытия.

4. “По стандарту” — быстро; “вне стандарта” — через понятный процесс.

5. Инциденты разбираем по причинам, а не по виноватым.

©Автор-эксперт: Владислав Халяпин