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