Система управления рисками и страхованием в ЦОД

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

Практический проект для разработки, согласования и последующей адаптации под действующие внутренние методики организации.

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

Методическая основа: Basel Committee on Banking Supervision, Institute of Operational Risk / Institute of Risk Management и практики управления операционными рисками ЦОД.

Термины и сокращения

RACI — Responsible, Accountable, Consulted, Informed — матрица распределения ответственности.

RCSA — Risk and Control Self-Assessment — самооценка рисков и контролей.

KRI — Key Risk Indicator — ключевой индикатор риска.

KCI — Key Control Indicator — ключевой индикатор контроля.

SLA — Service Level Agreement — соглашение об уровне сервиса.

BI — Business Interruption — перерыв в деятельности.

BIA — Business Impact Analysis — анализ влияния на деятельность.

RTO — Recovery Time Objective — целевое время восстановления.

RPO — Recovery Point Objective — целевая точка восстановления.

ITSM — Information Technology Service Management — управление ИТ-услугами.

ORMF — Operational Risk Management Framework — система управления операционным риском.

CORF — Common Operational Resilience Framework — единая система операционной устойчивости.

BCP — Business Continuity Plan — план непрерывности деятельности.

DRP — Disaster Recovery Plan — план аварийного восстановления.

1. Архитектура системы управления рисками

Цель — не создать отдельный «Excel риск-менеджера», а встроить управление рисками и страхованием в ежедневную работу ЦОД: эксплуатацию, ИТ, ИБ, работу с подрядчиками, управление изменениями, аварийное реагирование и финансовое планирование.

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

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

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

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

2. Инвентаризация действующей нормативной базы

Сначала нужно провести инвентаризацию уже действующей нормативной базы. Новая документация должна дополнять, а не дублировать существующие правила.

Блок | Что запросить | Зачем
Корпоративное управление рисками | политика/положение по рискам; методика оценки; матрица; риск-аппетит; формы реестров; отчётность | сохранить обязательные термины, шкалы и уровни эскалации
Инциденты | классификатор; процедуры ServiceDesk / управления ИТ-услугами (ITSM); аварийные регламенты; порядок расследований | не создавать параллельную систему событий
Эксплуатация ЦОД | регламенты эксплуатации, ППР/ТО, переключения, допуски, аварийные инструкции | привязать риски к реальным процессам и контролям
ИТ и ИБ | процедуры изменений, резервного копирования, центра мониторинга информационной безопасности (SOC) / ИБ-инцидентов, управления доступом | определить границы между операционным риском и профильными функциями
Непрерывность | планы непрерывности и восстановления (BCP/DRP), анализ влияния на бизнес (BIA), целевое время и точка восстановления (RTO/RPO) | согласовать риск-менеджмент с операционной устойчивостью
Подрядчики | типовые договоры, соглашения об уровне сервиса (SLA), лимиты ответственности, требования к страхованию | встроить третьи стороны в СУОР
Страхование | действующие полисы, приложения, лимиты, франшизы, исключения, история убытков | провести анализ разрывов (gap-анализ) страховой программы
Финансы/учёт | реестр ОС, восстановительные стоимости, правила расчёта убытка | корректно определять страховые суммы и ущерб
Аудит/контроль | акты проверок, замечания, планы устранения | использовать уже выявленные слабости

Выход: таблица «действующий документ → что регулирует → владелец → что оставить → что дополнить». Только после этого утверждается перечень новых НД.

3. Пакет регламентирующей документации

Оптимально разделить нормативную систему на три уровня.

Документ | Назначение
Положение о системе управления операционными рисками | цели, область, роли, три линии, жизненный цикл риска, комитеты, отчётность, связь с инцидентами и страхованием
Методика выявления и оценки рисков / самооценки рисков и контролей (RCSA) | шкалы вероятности и последствий, присущий/остаточный риск, оценка контролей, правила переоценки
Регламент ведения реестра рисков | поля, идентификаторы, статусы, версии, владелец, периодичность актуализации
Регламент регистрации событий операционного риска | инциденты, события без последствий (событие без последствий), сроки регистрации, классификация, ущерб, первопричины, эскалация
Регламент мероприятий по рискам | кто формирует, согласует, исполняет, контролирует срок и проверяет эффективность
Методика ключевых индикаторов риска и контроля (KRI/KCI) | индикаторы, источники данных, владельцы, пороги, частота мониторинга, действия при нарушении
Заявление о риск-аппетите и толерантности | границы принятия риска, критические запреты, правила эскалации
Положение о страховой защите | объекты, принципы выбора покрытия, лимиты, франшизы, ежегодный пересмотр, роли
Регламент страхового случая | уведомление, доказательства, осмотр, пакет документов, урегулирование, возмещение
Стандарт требований к подрядчикам | соглашения об уровне сервиса (SLA), ответственность, страхование, участие в расследовании, доказательства
Регламент отчётности по рискам | ежемесячный/квартальный пакет, основные риски, инциденты, меры, страхование

Если аналогичный документ уже действует на уровне группы или компании, вместо нового положения создаётся локальное приложение/инструкция, которая связывает корпоративное требование с процессами конкретного ЦОД.

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

4. Основное Положение о СУОР: что в него включить

Цель: предотвращение и снижение операционных потерь, поддержание устойчивости ЦОД, прозрачное принятие остаточного риска и передача части риска через страхование.

Область: инженерные системы, ИТ, ИБ, персонал, процессы, подрядчики, физическая среда, внешние события, проекты и изменения.

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

Принцип владения: риск принадлежит руководителю процесса/системы, который может на него влиять.

Три линии: первая линия управляет риском; риск-функция задаёт методологию и критически оценивает; независимая функция проверяет систему.

Жизненный цикл: выявить → оценить → назначить владельца → определить контроли → остаточный риск → меры → мониторинг → переоценка.

Связь с инцидентами: крупный инцидент должен приводить к проверке реестра рисков и контролей.

Связь со страхованием: значимые остаточные риски проверяются на возможность передачи/страхования.

Управление изменениями: новая система, проект, подрядчик или существенное изменение проходит оценку риска до внедрения.

Эскалация: риски вне толерантности, критические инциденты, просроченные критические меры, крупные страховые убытки.

Риск-менеджер не должен становиться владельцем всех рисков.

Базельская практика подчёркивает: первая линия владеет операционными рисками и контролями; независимая риск-функция разрабатывает политики и методологию, проверяет последовательность применения инструментов и ведёт мониторинг профиля риска; третья линия даёт независимое подтверждение.

5. Ответственность работников ЦОД

Роль | За что отвечает
Директор / генеральный директор | утверждает политику, риск-аппетит/толерантность, критические решения, программу страхования и крупные отклонения
Комитет по рискам / действующий управленческий комитет | рассматривает существенные межфункциональные риски, нарушения лимитов, крупные инциденты, просроченные меры, страховые решения
Корпоративный риск-менеджер | методология, реестр, самооценка рисков и контролей (RCSA), контроль качества регистрации, мониторинг сроков, консолидация отчётности, координация страхования
Руководитель подразделения / процесса / системы | владелец риска: подтверждает риск и оценку, определяет достаточность контролей, обеспечивает меры и ресурсы, принимает остаточный риск в пределах полномочий
Владелец контроля | обеспечивает работу конкретного контроля, его тестирование и доказательства исполнения
Владелец мероприятия | выполняет конкретное действие к сроку и предоставляет доказательство результата
Смена / инженер / ИТ-специалист | фиксирует событие, выполняет аварийные действия по профильным регламентам, сохраняет первичные данные и доказательства
ИТ / ИБ / инженерная эксплуатация / ПБ / ОТ | профильная экспертиза, специальные контроли, участие в расследованиях и разработке мер
Юристы | ответственность, претензии, договорные исключения, спорные страховые вопросы
Закупки / договорная функция | включает соглашения об уровне сервиса (SLA) и страховые требования в договоры, проверяет документы подрядчика
Финансы / бухгалтерия | стоимости активов, прямые убытки, перерыв в деятельности (BI), учёт премий, франшиз и выплат
Кадровая функция (HR) | компетенции, обучение, кадровые риски и данные по человеческому фактору
Внутренний аудит / независимый контроль | проверяет конструкцию и работу СУОР; не владеет рисками и не закрывает меры за первую линию

Главная граница: риск-менеджер отвечает за качество системы управления рисками, но не за техническую исправность ДГУ, чиллера, ИБП, сети, договора или сервера.

6. Матрица распределения ответственности (RACI): кто разрабатывает меры, кто контролирует и кто исполняет

R = выполняет; A = несёт конечную ответственность/утверждает; C = консультируется; I = информируется; F = фасилитирует.

Процесс | Директор | Риск-менеджер | Владелец риска | Профильный эксперт | Исполнитель меры | Аудит
Утвердить методику | A | R | C | C | I | C
Выявить риск | I | C/F | A/R | R/C | I | I
Провести самооценку рисков и контролей (RCSA) | I | R/F | A | R/C | I | C
Разработать мероприятие | I | C | A | R/C | C | I
Утвердить ресурсы/срок | I/A при крупных | C | A | C | I | I
Исполнить мероприятие | I | C | A | C | R | I
Контролировать срок | I | A/R | C | I | R по факту | I
Проверить эффективность | I | C/R | A | R/C | C | I/C
Принять риск выше лимита | A | C | R/C | C | I | I
Зарегистрировать инцидент | I | C | A | R | I | I
Расследовать крупный инцидент | I/C | C/F | A | R | C | C
Определить потребность в страховании | A/C | R | C | C | I | I
Независимо проверить СУОР | I | C | C | C | I | A/R

Конкретные должности в RACI нужно заменить на фактическую организационную структуру. В нормативном документе недопустимо оставлять формулировку «ответственное подразделение» без назначения роли.

7. Процедура риска: от выявления до переоценки

Жизненный цикл риска.

Выявление. Владелец процесса/системы и профильные специалисты формулируют риск как событие, причины и последствия. Риск-менеджер помогает методически.

Присущий риск. Оценка без учёта конкретных контролей — по действующей корпоративной шкале организации.

Контроли. Фиксируются реальные технические, организационные, договорные, страховые и мониторинговые меры.

Эффективность контролей. У контроля должны быть владелец, периодичность, доказательство выполнения и способ теста.

Остаточный риск. Оценка после контролей сравнивается с риск-аппетитом/толерантностью.

Решение. Принять, снизить, избежать, передать часть риска, повысить готовность к восстановлению.

Мероприятия. Назначаются тем, кто реально может изменить систему, процесс, договор или контроль.

Проверка эффективности. После выполнения меры оценивается не только факт закрытия, но и изменение риска.

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

Самооценку рисков и контролей (RCSA) желательно проводить не одним человеком. Для ЦОД качественная оценка обычно требует участия владельца процесса, инженера/ИТ, профильной контрольной функции и риск-менеджера.

8. Регламент мероприятий по снижению риска

Мероприятие формируется совместно владельцем риска и профильными специалистами. Риск-менеджер проверяет, что мера связана с причиной/слабым контролем, имеет владельца, срок и измеримый результат.

Поле | Что требуется
Источник | ссылка на риск, инцидент, аудит или KRI
Причина/слабость | что именно устраняется
Действие | конкретный результат, а не «усилить контроль»
Исполнитель | один владелец действия
Руководитель/согласующий | тот, кто обеспечивает ресурс
Срок | конкретная дата
Ресурс/бюджет | при необходимости
Критерий завершения | акт, настройка, испытание, договор, обученный персонал, внедрённая система
Критерий эффективности | как проверяем, что риск реально снизился
Новая оценка | остаточный риск после проверки эффекта

Просроченное критическое мероприятие должно попадать в отчёт директору вместе с причиной, риском и предложением по новому сроку. Перенос даты — управленческое решение, а не техническое редактирование реестра.

9. Инциденты, события без последствий (событие без последствий) и операционные потери

Инцидент должен пройти полный цикл, а не закончиться на отметке «устранено».

База событий нужна не только для отчётности. Она калибрует вероятность, показывает слабые контроли и повторяемость, даёт данные для страхования и претензионной работы.

Карточка инцидента | Минимальное содержание
Идентификация | номер; дата/время возникновения, обнаружения и завершения; объект/система/процесс
Событие | что произошло без преждевременных выводов о виновности
Классификация | категория риска, тяжесть, затронутые сервисы/активы
Воздействие | простой, деградация, SLA, физический ущерб, клиенты, данные, безопасность
Причины | непосредственная, промежуточная, коренная; степень доказанности
Контроли | какие не сработали и какие ограничили последствия
Подрядчик | участие, договор, SLA, ответственность, страхование
Страхование | потенциальный страховой случай, уведомление, статус
Меры | временные и постоянные, владельцы, сроки
Закрытие | подтверждение причины, ущерба, решений, страхового статуса и проверки мер

Конкретные сроки регистрации/эскалации должны быть взяты из действующих процедур организации и аварийных регламентов. Их не следует придумывать отдельно, если уже существует ServiceDesk/ITSM-классификация.

10. Ключевые индикаторы риска (KRI) и контроль профиля риска

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

Область | Примеры индикаторов для согласования
Электроснабжение | отказы запуска/синхронизации; часы работы без требуемого резервирования; просроченные ТО
Охлаждение | часы без N+1; запас доступной мощности; нарушения температурных диапазонов
UPS/АКБ | непройденные тесты; модули с ухудшением параметров; просроченная термография
ИТ | доступность критических сервисов; повторные инциденты; просроченные критические изменения/патчи
Подрядчики | просрочки SLA; доля работ с неполной документацией; истёкшие страховые сертификаты
Риски/меры | риски вне толерантности; просроченные критические меры; повторяемость событий
Страхование | активы без актуальной страховой стоимости; истекающие полисы; незакрытые убытки

Пороги должны опираться на технические требования, SLA, статистику, риск-аппетит и реальную способность объекта сохранять устойчивость.

11. Положение о страховой защите ЦОД

Страховая защита — отдельный управляемый цикл внутри общей СУОР.

Страхование должно начинаться с карты экспозиций и остаточных рисков, а не с выбора страховщика.

Раздел | Что закрепить
Стратегия | какие потери компания готова удерживать, какие передавать
Реестр экспозиций | активы, восстановительная стоимость, критичность, собственник, местоположение
Имущество | здания, инженерные системы, ИТ-оборудование; лимиты и исключения
Поломка машин / электроника | если соответствующие покрытия применяются в действующей программе
BI / перерыв | финансовый показатель, период ожидания, максимальный период возмещения, связь с физическим ущербом
Ответственность | имущество клиентов, гражданская ответственность, границы со штрафами и SLA credits
Кибер | если предусмотрено корпоративной программой — связь с ИБ и киберинцидентами
Подрядчики | минимальные лимиты ответственности/страхования, виды работ, срок действия, территориальность
Франшизы | кто утверждает и сколько убытка компания готова удерживать
Лимиты | привязка к оценке потенциального крупного убытка и финансовой способности компании

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

Риск-менеджер ведёт карту «риск → контроль → остаточная экспозиция → страховое покрытие → лимит/франшиза/исключение → незастрахованный остаток». Она позволяет руководству видеть, какая часть финансовых последствий действительно передана страховщику.

12. Регламент страхового случая

Этап | Кто делает | Роль риск-менеджера
Первичная фиксация | смена/эксплуатация/ИТ по аварийному регламенту | определить страховую релевантность и сроки уведомления
Сохранение доказательств | технические подразделения, ИБ/служба безопасности | контроль логов, фото, деталей, актов, видео, журналов
Оценка ущерба | технические подразделения + финансы | свести структуру убытка и исключить двойной счёт
Осмотр страховщика | владелец объекта + риск-менеджер | координация доступа и документов
Претензия подрядчику | юристы + владелец договора | согласование с суброгацией/страховщиком
Расчёт перерыва в деятельности (BI) | финансы + бизнес | контроль соответствия условиям полиса
Закрытие | финансы/юристы/риск-менеджер | зафиксировать выплату, франшизу, отказ, возмещение и уроки

В карточке убытка полезно вести четыре суммы: валовый ущерб → потенциально покрываемый ущерб → фактическая страховая выплата → возмещение от подрядчика/третьего лица. Разница показывает фактический остаточный финансовый ущерб.

13. Подрядчики, соглашения об уровне сервиса (SLA) и ответственность

Для ЦОД подрядчики — один из ключевых источников операционного риска. Договорная работа должна быть частью СУОР.

Условие | Зачем
чёткие границы ответственности | исключить серые зоны между эксплуатацией и подрядчиком
соглашение об уровне сервиса (SLA) и точка старта таймера | объективно измерять нарушение
аварийные каналы уведомления | не спорить после инцидента, какой канал считался официальным
лимит ответственности | понимать реально доступное взыскание
обязательное страхование ответственности | иметь дополнительный источник возмещения
участие в расследовании и сохранение доказательств | обеспечить причинный анализ и страховое урегулирование
исполнительная документация | доказательство качества работ
право проверки/аудита | контроль критического подрядчика
субподрядчики | не допустить неконтролируемой передачи критических работ
план непрерывности деятельности (BCP) / аварийная готовность | понимать, способен ли подрядчик выполнить соглашение об уровне сервиса (SLA) при массовом событии

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

14. Управленческая отчётность и цикл принятия решений

Основной отчёт должен быть коротким и ориентированным на решения.

Блок | Что показывать
Профиль риска | топ-10 остаточных рисков и динамика
Нарушения толерантности | риски и ключевые индикаторы риска (KRI), требующие решения
Инциденты | существенные события, событие без последствий, повторяемость, причины, ущерб
Мероприятия | критические просрочки, переносы, блокеры, эффект закрытых мер
Контроли | существенные дефекты и непройденные тесты
Подрядчики | нарушения соглашений об уровне сервиса (SLA), претензии, проблемы страховых сертификатов
Страхование | статус программы, незакрытые убытки, выплаты/отказы, ближайшие продления
Решения | что руководству нужно утвердить, принять, профинансировать или эскалировать

Хороший отчёт по операционному риску — не архив реестра, а список текущих управленческих вопросов с фактами и вариантами решения.

15. Какие формы и реестры подготовить

Карточка риска и центральный реестр рисков.

Форма самооценки рисков и контролей (RCSA).

Карточка контроля и реестр ключевых контролей.

Реестр ключевых индикаторов риска и контроля (KRI/KCI) и порогов.

Карточка инцидента / события без последствий (событие без последствий).

Форма анализа первопричин.

План мероприятий.

Лист проверки эффективности мероприятия.

Реестр страховых полисов.

Реестр застрахованных активов и страховых стоимостей.

Карточка страхового случая.

Чек-лист уведомления страховщика.

Чек-лист страховых требований к подрядчику.

Квартальный управленческий отчёт.

Протокол риск-комитета / управленческого рассмотрения.

Все объекты должны связываться идентификаторами: например R-0042 риск, INC-0031 инцидент, ACT-0118 мероприятие, CLM-0007 страховой случай. Тогда можно строить цепочку «риск → инцидент → мера → страховой убыток».

16. Целевая модель управления

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