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

Введение в GRC

Governance, Risk management and Compliance (GRC) – это взгляд на управление чем-либо с трёх точек зрения: высшего руководства (Governance), управления рисками (Risk management) и соответствия требованиям (Compliance). Любую деятельность можно разложить по этим трём составляющим. Подробнее о том, чем Governnance отличается от менеджмента написал в отдельном посте по ссылке: Management vs Governance. В чем различие?

GRC система позволяет повысить эффективность решения, в том числе, следующих задач:

• Управление жизненным циклом корпоративных политик и внутренних организационно-распорядительных документов
• Обеспечение соответствия организации требованиям действующего законодательства, нормативной базы и стандартов
• Визуализация и коммуникация рисков на всех уровнях управления организацией
• Реагирование, расследование и ликвидация последствий инцидентов
• Управление непрерывностью бизнеса
• Управления внутренним аудитом на базе риск-ориентированного подхода

Сходство и различие между GRC и ERP

Прежде всего, разберемся в чем заключается отличие GRC-систем от сильно похожих на них ERP-систем. И те и другие предназначены для автоматизации внутренних процессов организации. И те и другие имеют схожую архитектуру, программную платформу, настраиваемые workflow, внутренние языки и безъязыковые средства разработки, наборы приложений для решения различных специфических задач из разных областей деятельности и т.п. Разница по сути заключается в видах и уровне автоматизируемых процессов.

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

Основные компоненты GRC системы

Платформа

Платформа служит основой для построения любых GRC решений. Она предоставляет базовые средства для проектирования, разработки, запуска, интеграции и управления приложениями, адаптированными к потребностям конкретного бизнеса. Платформа также предоставляет средства для интеграции этих приложений с внешними системами. Такие наборы приложений поставляются вместе с платформой. Пользователи имеют возможность их кастомизировать без использования программирования (или используя методы визуального программирования), объединить эти приложения в пакеты для решения конкретных задач в конкретной организации, включая, например, процессы проектного менеджмента, управления инцидентами, взаимодействия с поставщиками, клиентами и контрагентами и т.д.

Решение

Решения представляют собой пакеты приложений, объединённых для выполнения конкретной бизнес задачи, например, управления рисками, соответствием или внутренним аудитом. Так решение по управлению политиками может включать в себя следующие приложения: Политики, Базовые уровни защищенности (или соответствия), Стандарты, Источники. Функции, архитектуру и названия приложений придумывают сами разработчики, поэтому они могут быть какими угодно.

Вместе с приложениями в состав Решений входят также опросники, панели управления, рабочие столы, роли и группы пользователей, а также прочие ресурсы, необходимые для решения конкретных задач. Любое GRC-приложение работает с некоторым каталогом бизнес активов.

Решения также могут объединяться в пакеты, которые называются Сценариями использования. Например, типовой сценарий IT Security and Risk Management включает в себя решения по управлению ИТ инцидентами, уязвимостями, рисками, комплайенсом и т.п.

Сценарий использования

Каждое решение включает в себя определение сценария использования приложений в составе данного  решения. Например, решение по управлению аудитом содержит следующие сценарии: Управление проблемами, Обязательства и документация аудита, Планирование и контроль качества аудита.

Примеры сценариев использования включают в себя менеджмент (читай: управление жизненным циклом) следующий процессов: внутренний аудит, обеспечение непрерывности бизнеса, операционный риск-менеджмент, менеджмент ИТ/ИБ рисков, обеспечение соответствия, взаимоотношения с третьими сторонами и прочее.

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

Приложение

Приложение служит контейнером для определенных типов записей, таких как инциденты, контроли, политики, активы и т.п. Приложение определяет контент и поведение записей. Например, Контакты, Задачи, Оповещения, Назначения или ИТ-активы.

Опросник

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

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

Интерфейсы

Back Office и Front Office

Пользовательский веб интерфейс (Web UI) состоит из двух областей:  Back Office и Front Office. В Back Office администраторы создают экземпляры объектов для различных сущностей GRC-платформы. В Front Office конечные пользователи работают с различными представлениями этих объектов. Другими словами в Back Office мы имеем дело со списками приложений, полей, макетов, форм и т.п., а в Front Office – со списками рисков, бизнес подразделений, уязвимостей и т.п.

Web Services API

Web Services API представляет собой набор веб-сервисов для взаимодействия с внешними приложениями по протоколу HTTPS, а также для обмена данными между различными приложениями в рамках единой физически распределенной платформы.

RESTful

RESTful (Representational State Transfer) – это упрощенная альтернатива SOAP сервисам. Сервисы RESTful позволяют пользователю работать с данными GRC-платформы.RESTful с ервис представляет собой набор ресурсов, объединенных в функциональные сегменты, доступ к которым осуществляется через контроллеры. Действия над ресурсами можно производить как в индивидуальном порядке, идентифицируя ресурс по ключу и идентификатору, так и в пакетном режиме. RESTful API использует формат JavaScript Object Notation (JSON) по умолчанию для запросов и ответов, но также поддерживается и XML. После идентификации ресурса над ним могут быть выполнены операции Создание, Чтение, Удаление с использованием стандартных HTTP методов, таких как POST, GET, PUT, PATCH, и DELETE.

Platform API

Интерфейсы Platform API служат для работы с Back Office и используется администраторами для автоматизации различных операций с объектами GRC-платформы.

Content API

Интерфейсы Content API служат для работы с Front Office и выполняют трансляцию метаданных и контента, конвертируя их в логические сущности, с которыми можно работать в пользовательском интерфейсе. Данные различных записей разбросаны по базам данных Back Office, но при просмотре их через Front Office, пользователи видят все эти данные на одном экране в заданном формате.