Ключевые группы рисков
| Группа | Содержание |
|---|---|
| Доступность систем | Отказы инфраструктуры, ошибки при обновлениях, недоступность облачных сервисов |
| Информационная безопасность | Атаки, утечки данных, компрометация учетных записей, вредоносное программное обеспечение |
| Данные | Потеря, повреждение, отсутствие проверенных копий, некорректная миграция |
| Поставщики и лицензии | Прекращение поддержки, изменение условий, невозможность продления, зависимость от одного вендора |
| Проекты внедрения | Срыв сроков, превышение бюджета, неполучение заявленного эффекта, сопротивление пользователей |
| Персонал | Уход ключевых специалистов, отсутствие документации, знание, существующее в одной голове |
| Технический долг | Накопленные упрощения, из-за которых стоимость изменений растет, а надежность падает |
| Соответствие требованиям | Обработка персональных данных, требования к используемым решениям |
Почему ИТ-риски плохо ложатся в обычную матрицу
Две особенности. Первая, многие ИТ-риски не имеют естественной частоты. Вопрос не в том, как часто происходит атака, а в том, насколько система устойчива и как быстро восстанавливается. Оценка вероятности здесь менее содержательна, чем оценка защищенности и готовности.
Вторая, технический долг это риск с накопительным характером. Он не срабатывает как событие, он постепенно увеличивает вероятность и тяжесть всех остальных рисков. Отражать его строкой реестра можно, но управлять им приходится иначе, через долю ресурса разработки, регулярно выделяемую на его сокращение.
Практический минимум для любой компании
Независимо от размера ИТ-подразделения.
- Перечень критичных систем с указанием допустимого времени простоя и допустимой потери данных
- Проверенные резервные копии, проверка означает восстановление, а не наличие файла
- Управление доступом, регулярный пересмотр прав, отзыв при увольнении
- Управление изменениями с планом отката для критичных систем
- План действий при основных сценариях, недоступность системы, потеря данных, компрометация
- Понимание зависимостей от внешних поставщиков и наличие плана на случай их выхода
- Документация критичных решений, снимающая зависимость от одного человека
О проектах внедрения
Проекты внедрения информационных систем срываются с устойчивой регулярностью, и причины повторяются. Требования зафиксированы недостаточно, поэтому объем работ растет в процессе. Не выделены ресурсы со стороны бизнеса, поэтому решения принимаются медленно. Миграция данных недооценена, обычно это самая трудоемкая часть. Не спланировано обучение и сопровождение после запуска.
Все четыре причины управляемы на старте и почти неуправляемы в середине. Поэтому по проектам внедрения имеет смысл проводить отдельную стартовую сессию по рискам, а не ограничиваться общим реестром проекта.
Отдельная сторона ИТ-рисков это непрерывность: что делает компания, пока система лежит. Разбор с реальными сроками восстановления на нашем сайте о непрерывности бизнеса: риски в ИТ и план восстановления.
Частые вопросы
Владельцем риска недоступности бизнес-системы является руководитель бизнес-функции, а не ИТ-директор. ИТ отвечает за меры, бизнес за приемлемый уровень.
Через стоимость изменений и частоту инцидентов, связанных с проблемными участками. Прямая денежная оценка обычно не удается, а косвенные показатели работают.
Отдельные шкалы для доступности и данных полезны, но общая методология должна оставаться единой, иначе агрегация невозможна.
Проверьте зрелость своей системы управления рисками
Тринадцать вопросов по пяти уровням ГОСТ Р 70350, результат сразу: уровень, три главных пробела и следующий шаг.
