Добрый день!

Меня зовут Максим Торнов и я продолжительное время занимаюсь областью управления рисками, присущими ИТ. Данный материал является продолжением статьи «Управление риском ИТ».

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

Гипотетическая история

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

• лояльность клиентов

• соответствие регуляторным требованиям

• надежность и достоверность финансовой отчетности

• эффективность и своевременность принятия управленческих решений

Компания динамично развивается, новое ПО, «фичи», отчеты и т.д. появляются, как бургеры в известном ресторане.

ИТ ландшафт компании представляет из себя среду, состоящую из более 70 работающих автоматизированных систем, совместно взаимодействующих в интегрированной и децентрализованной инфраструктуре.

Данные ИТ системы делятся на самостоятельно разработанные инструменты и автоматизированные сервисы, а также купленные готовые продукты (out-of-the-box/off-the-shelf), охватывающие все бизнес-процессы внутри компании.

Существующая проблема

Однако в компании весьма посредственно развит подход к управлению риском, присущим ИТ, и, как следствие, отсутствует эффективный контроль над ИТ, что в свою очередь часто приводит к различным ИТ проблемам и инцидентам, например:

• Ошибки в отчетах или работе систем

• Некорректный доступ пользователей

• Утечки персональных данных

• Недоступность систем

• Недостаточная производительность систем

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

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

Задача

Перед менеджментом стоят задачи:

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

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

3. Определить методику, инструменты и объекты для оценки эффективности контрольных процедур над ИТ.

4. И самое главное: наилучшим образом объяснить владельцам автоматизированных систем и сервисов важность внедрения процессов управления ИТ рисками, контроля над ИТ, и тем самым убедить их, а главное мотивировать использовать при развитии автоматизированных систем и сервисов методы управления рисками и контроля над ИТ.

---

1.   С чего можно было бы начать?

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

Учитывая разнообразный характер используемых технологий, на пути достижения целей компании и ИТ потенциально могут возникнуть различные риски, присущие информационным технологиям. Чтобы более эффективно спланировать развитие систем и сервисов, необходимо понимать эти риски.

Шаг 1: понять связь между бизнес-процессами и ИТ средой - используемыми в компании информационными технологиями.

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

Таким образом, зная, какие инструменты и системы использует бухгалтерия, финансы, какие данные куда, для чего и с помощью чего передаются, можно определить связь и зависимость бизнес-процессов и ИТ системы (например системы бухгалтерского учета).

Далее можно попытаться предположить, что может пойти не так, если данная ИТ система не будет функционировать, как ожидалось заинтересованными потребителями и поставщиками информации.

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

• сформированные отчеты не полные и/или не точные

• данные повреждены или недоступны

• расчеты ошибочны

• некоторые интерфейсы с другими системами теряют данные

• производительность системы низкая

• ошибки в разработанном ПО, либо задержки в его разработке

Таким образом, в результате, подобных событий, компания может быть подвержена различным рискам, которые могут помешать компании достичь своих целей. В данном случае, например цели «Достоверность финансовой отчетность» и «Соответствие регуляторным требованиями» могут быть не достигнуты/ достигнуты частично/ с финансовыми и/или репутационными издержками.

Понимая связь ИТ систем/автоматизированных сервисов и процессов бизнеса, можно сформировать перечень используемых технологий, оценить степень их критичности для бизнеса, подверженность таких технологий рискам ИТ и определить уровень необходимого контроля над данными технологиями.

Шаг 2. Понять критичность ИТ систем и присущие риски

Очевидно, что Шаг 1 может дать очень большой перечень систем, технологий, автоматизированных сервисов и т.д. Но все ли они важны и критичны для бизнеса компании? Если да, то какова степень критичности систем и их элементов?

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

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

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

ВАЖНО: необходимо принимать во внимание, что ИТ система или автоматизированный сервис — это комплекс, который может состоять из различных интегрированных подсистем, например:  приложение + ОС + СУБД + Сеть + Интерфейсы + промежуточное ПО и т.д.

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

Шаг 3. Определить набор контрольных процедур в области ИТ, применительно к типам/вариантам/категориям ИТ систем и автоматизированных сервисов.

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

Понимая специфику технологий, а также присущие данным технологиям риски, мы можем уйти на уровень ниже и уже разработать так называемые процедуры контроля, описанные в политиках и процедурах, базовых требованиях к ИТ системам. Данные документы формализуют непосредственно процедуры контроля над ИТ, т.е. могут описывать:

1. Кто делает?

2. Что делает?

3. Как часто делает?

4. Каков результат?

5. Зачем и какую цель достигает?

В данном случае, при разработке контрольных процедур, можно воспользоваться одной из лучших практик описания - «5W», исследуя «Кто», «Что», «Где», «Когда» и «Почему».

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

Описанные и внедряемые контрольные процедуры могут быть как общего характера (General IT Controls), так и более специфичными, характерными для отдельной системы или автоматизированного сервиса/процесса. Более подробно о контрольных процедурах мы поговорим ниже.

Внедрение контроля над ИТ должно применяться в первую очередь к наиболее важным ИТ системам, а затем к системам и сервисам с более низким приоритетом/критичностью.

Например, в зависимости от сложности и критичности ИТ системы потенциально меньшее количество контрольных процедур необходимо (сравните важность и критичность для бизнеса таких систем как SAP ERP и BMC Remedy (система ITSM)).

Также вновь обращу Ваше внимание: при разработке и внедрении контроля над ИТ необходимо учитывать все уровни ИТ, включая само приложение, ОС, СУБД, сеть и т.д.

Шаг 4. Определить «правила» для ИТ, в частности, политики, процедуры, базовые требования к системам и автоматизированным сервисам

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

В рамках ИТ процессов компания должна разработать и применять политики, процедуры, базовые требования и т. д., которые, другими словами, могли бы устанавливать правила выполнения процедур и контроля, направленные на снижение рисков, присущих ИТ системам и автоматизированным сервисам.

Вот пример, что может пойти не так и что можно сделать, чтобы избежать негативных последствий:

Шаг 5. Коммуникация с владельцами ИТ систем, автоматизированных сервисов и процессов

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

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

Однако, независимо от настроения владельцев ИТ систем и/или автоматизированных сервисов, я верю, что всегда возможен некоторый конструктивный компромисс и обоюдная заинтересованность.

Используя различные варианты коммуникации (проведение тренингов, meet-up сессии, т.д.), объясняя владельцам ИТ систем, автоматизированных сервисов и процессов, необходимость внесения изменений в процессы и процедуры, подчеркивая причины, важность и приоритеты в отношении управления рисками ИТ и внедрения контроля над ИТ, можно заручиться их лояльностью.

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

Забегая немного вперед, важно помнить, что процесс управление рисками ИТ является цикличным. Предположим, что контроль над ИТ внедрен - ура! Однако теперь крайне важно собрать отзывы владельцев систем и сервисов, в результате чего, возможно, потребуется внести коррективы в процессы и процедуры контроля, контрольную среду, когда это необходимо.

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

---

2. Какой контроль хотим внедрить?

Хорошо, мы определились с перечнем систем и их критичностью для бизнеса. Но как определить ключевой набор контрольных процедур, которые должны присутствовать применительно к каждой ИТ системе или автоматизированному сервису?

По моему личному убеждению, критичными и первичными к внедрению процедурами контроля над ИТ являются:

Административный доступ

Полномочия на внесение изменений в параметры безопасности ИТ систем, управление учетными записями, управление изменениями должны быть ограничены и предоставлены исключительно соответствующим сотрудникам, из ограниченного набора департаментов/отделов.

Управление изменениями

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

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

Управление доступом

Пользователи могут иметь доступ к ИТ системе только в соответствии с их должностными обязанностями, доступ при этом понятен владельцу системы и им же согласован в соответствии с принципом разграничения полномочий (SoD).

Проверка и прекращение доступа

Доступ уволенного или переведенного сотрудника в ИТ системе должен быть своевременно заблокирован или пересмотрен. При этом я бы рекомендовал, чтобы при смене функционала/должности сотрудника его/ее доступ был отозван полностью и пере-предоставлен. Опять же, обязательно требуется одобрение владельца ИТ системы.

Настройки безопасности

Параметры безопасности всех без исключения ИТ систем задаются в соответствии с действующей Политикой информационной безопасности компании.

И да, в случае ограничений системы должны быть рассмотрены другие, компенсирующие недостаток функционала системы контрольные процедуры. Например, в системе есть ограничения на длину пароля и его сложность. В данном случае можно рассмотреть для пользователей аутентификацию с помощью стороннего ПО, либо доработать систему, либо использовать вход с RSA SecurID ключом и т.д. Т.е. реализован некий фактор, который позволит снизить вероятность того, что кто-то иной, кроме правильного сотрудника, войдет в систему.

По моему мнению, перечисленные выше контрольные процедуры наиболее критичны и должны быть внедрены применительно ко всем критичным ИТ системам, автоматизированным сервисам и процессам в первую очередь.

Однако это далеко не исчерпывающий перечень. Другие контрольные процедуры могут быть не менее важными, а также более эффективными в каждом конкретном случае.

Также для Вашего удобства в части рекомендаций по внедрению контроля над ИТ я добавил полезную информацию, влияющую на эффективность каждой отдельной контрольной процедуры, которую настоятельно советую учитывать при разработке дизайна процедур. Смотрите дополнительную информацию в конце этой статьи, в Приложениях 1 и 2.

---

3.   Мониторинг ИТ-рисков. Оценка контроля

Вы все еще читаете? Поздравляю, мы практически на финишной прямой!

Предположим, мы внедрили контроль над ИТ средой компании и отдельные контрольные процедуры для различных систем, автоматизированных сервисов и процессов, но как определить подходы к проверке эффективности контрольных процедур над ИТ? Т.е. как вообще понять, эффективны ли контрольные процедуры, которые мы не без труда только что внедрили?

Тут хочу обратить Ваше внимание, что всегда должен соблюдаться принцип разграничения полномочий. Помните о 3х линиях защиты из статьи по Управлению риском ИТ?

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

Обычно внедрением занимается команда по управлению Внутренним контролем организации, проверкой эффективности – команда по внутреннему аудиту либо внешний независимый аудитор.

Суть в том, что, внедрив что-то, мы становимся заинтересованными в том, чтобы это было эффективно (мы же не хотим сказать, что мы внедрили что-то бесполезное или неэффективное, правильно?), тем самым проявляем заинтересованность.

Для примера можно вспомнить события недалекого прошлого с компаниями Enron Corp. (https://ru.wikipedia.org/wiki/Дело_Enron) и Arthur Andersen LLP (https://ru.wikipedia.org/wiki/Arthur_Andersen). В частности, события, связанные с этими зарубежными компаниями, фактически послужили первопричиной зарождения закона Sarbanes-Oxley (https://en.wikipedia.org/wiki/Sarbanes–Oxley_Act).

Так как же понять, эффективен ли процесс управления риском ИТ и контроль над ИТ?

В рамках управления ИТ-рисками компания с определенной периодичностью проводит оценку эффективности контроля над ИТ. Частью оценки является сбор свидетельств, которые могут подтвердить эффективность общего контроля над ИТ и отдельных контрольных процедур (может иногда называться «контрольным мероприятием»), исходя из их дизайна и цели (помните – Кто делает? Что делает? Как часто? Каков результат?) и результата внедрения, т.е. реализации.

Вот пример доказательств эффективности/не эффективности контрольной процедуры, которые могут быть собраны для анализа и оценки эффективности:

Административный доступ

Списки пользователей с административными или повышенными правами доступа. Внутренние политики/процедуры, которые регламентируют управление подобным уровнем доступа.

Управление изменениями

Список изменений отдельной системы или сервиса, «тикеты»/заявки, другие доказательства, подтверждающие, что цели контрольной процедуры достигнуты. Процедуры/политики, регламентирующие подход к управлению изменениями ИТ систем или автоматизированных сервисов компании. Список разработчиков и других пользователей с возможностью внесения изменений.

Управление доступом

Списки пользователей с их правами доступа и датами изменения доступа. Доказательства, которые могут подтвердить обоснованность уровня их доступа. Процедуры/политика управления доступом в компании.

Проверка и прекращение доступа

Списки уволенного или переведенного персонала с датами изменения доступа. Политики и процедуры управления доступом.

Настройки безопасности

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

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

---

4.   Почему важно управлять ИТ-рисками? Почему необходим контроль над ИТ? Как убедить в этом владельцев ИТ систем, автоматизированных сервисов и процессов?

Вот мы и подошли к наиболее важному, на мой взгляд, вопросу.

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

Помните концепцию 3х линий защиты? На всякий случай напомню, что стоит также поделиться этой концепцией с владельцами ИТ систем, автоматизированных сервисов и процессов! Идеально, если она уже реализована в компании на уровне политик и процедур, определяющих кто и за что отвечает в компании.

1-я линия - бизнес

Все, кто участвует в повседневной деятельности организации: владельцы сервисов или ИТ систем из различных направлений бизнеса и функций, включая продажи/закупки, бухгалтерию и финансы, управленческий менеджмент, отделы ИТ и безопасность и т.д.

2-я линия – специалисты по управлению рисками

Например, функция внутреннего контроля, функция управления рисками.

3-я линия – служба внутреннего аудита

Независимый орган компании, который проверяет, эффективно ли первая линия следует правилам, установленными второй линией защиты

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

Так почему же важно управлять ИТ-рисками? Почему важен контроль над ИТ? Зачем это владельцам?

Как я говорил ранее, в контексте управления рисками ИТ важен диалог. Диалог между 3мя линиями защиты. В нашем же случае – диалог между 1й и 2й линиями.

Каждая ИТ система, автоматизированный сервис имеет свои цели. Например: удовлетворенность клиента, надежность и доступность системы и/или сервиса, быстрота и качество сервиса и т.д.

Понимая и принимая во внимание эти цели, владельцы ИТ систем и сервисов могут использовать методы управления рисками и контроля над ИТ, тем самым повышая качество обслуживания клиентов (не только внешних, но и внутренних), улучшая надежность и эффективность ИТ систем или автоматизированных сервисов, тем самым параллельно повышая удовлетворенность и лояльность внешних клиентов компании!

Что касается внутренних клиентов, представьте, что вы забыли об отделе ИТ просто потому, что у Вас никогда ничего не сбоит и все работает ровно, как Вы того ожидаете. Поверьте, такие компании существуют, такое ИТ существует, я сам в такой работал. В таких компаниях вы вспоминаете об ИТ, только когда забыли пароль после хорошего отпуска.

Чтобы лучше понять, почему управление ИТ-рисками и эффективность контроля над ИТ важны для владельцев приложений/сервисов и вообще бизнесу компании в целом, в диалоге с владельцами можно рассмотреть следующие вопросы:

Но это еще не все! Какие преимущества могут быть у компании и руководства от управления ИТ-рисками и эффективности контроля над ИТ?

Помимо роста исполнимости KPI и стоимости акций (если владельцы ИТ систем/автоматизированных сервисов, например, владеют опционами), основные выгоды, которые компания получает от построения эффективной системы управления своими ИТ-рисками, на мой взгляд, такие положительные процессы как:

• Внутри компании формируется риск-ориентированная культура. Сотрудники опираются на ее принципы в своих действиях, и, как результат, снижается зависимость компании от отдельных (уникальных) сотрудников или подрядчиков

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

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

• Производительность систем, процессы управления инцидентами и непрерывностью бизнеса улучшаются, что приводит к возрастанию предсказуемости и надежности бизнес-процессов Компании, удовлетворенности пользователей

• Повышается качество контроля, мониторинга и отчетности, руководство получает доступ к более точным и своевременным данным и информации, что упрощает процесс принятия решений и, как следствие, повышает эффективность управления компанией, доверие акционеров и других заинтересованных сторон

Подводя итоги

Я успел поработать на всех линиях защиты. Для себя лично, когда я пишу эту статью, и находясь на 2й линии защиты, я считаю важным нахождение и поддержание открытого и эффективного диалога, как с 1й линией защиты, так и 3ей, 4й. По моему личному убеждению, при открытой и эффективной коммуникации выигрывают все.

Большое спасибо за то, что прочитали данный материал до конца. Я искренне надеюсь, что Вы узнали для себя, что-то новое и полученная информация будет для Вас полезна!

Также, если Вы еще не читали, предлагаю прочитать основополагающую статью по «Управлению риском ИТ»: https://habr.com/ru/post/599047

---

Приложение 1. IUC и IPE

Для разработки эффективного контроля над ИТ, эффективных контрольных процедур в области ИТ, при разработке дизайна контрольных процедур необходимо учесть, формализовать и добавить в дизайн контрольных процедур такую сущность как IUC (Information Used in the Control - информация, используемая в контрольной процедуре), также известнаую как IPE (называемая внешними аудиторами «информацией, предоставленной/произведенной организацией»).

Этот момент весьма важен, поскольку владелец контроля (лицо, осуществляющее контроль, исполняющее контрольную процедуру, мероприятие или действие), в зависимости от специфики контрольный процедуры (как правило, целью контрольной процедуры является выявление отклонения) должен проверить следующие факторы:

• Какой источник информации используется при выполнении контрольной процедуры? Например: действительно ли источник данных был предусмотрен дизайном контрольной процедуры?

• Какие параметры/фильтры применялись при формировании отчета/выгрузки данных? Например: соответствующие ли параметры были установлены при выполнении скрипта? Цель данного шага в том, чтобы убедиться, что отчет/выгрузка данных не были ограничены случайно или с целью что-то скрыть;

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

---

Приложение 2. Ключевые факторы дизайна контрольной процедуры

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

1. Соответствие цели контроля и его взаимосвязь с риском. Это означает, что контроль точно соответствует своей цели по снижению риска/рисков;

2. Целесообразность контрольной процедуры с учетом характера и значимости риска. Это означает, что контрольная процедура спроектирована таким образом, что эффективно снижает риск;

3. Компетентность и полномочия лица (лиц), осуществляющего контроль. Это означает, что исполнитель (в некоторых случаях владелец) контрольной процедуры имеет необходимые навыки и полномочия для осуществления контроля (человек знает «кто делает», «что делает», «как делает» и «зачем делает» и способен осуществлять контроль);

4. Частота и последовательность, с которой выполняется контрольная процедура. Это означает, что дизайн контрольной процедуры достаточно эффективен, чтобы идентифицировать отклонение, ошибку и др.

5. Уровень детализации анализа и предсказуемость выявления отклонения. Это означает, что дизайн контрольной процедуры позволяет идентифицировать отклонение с большой точностью и вероятностью. Например: контрольная процедура по анализу доступа исполняется «ежемесячно» вместо «ежегодно» и на уровне «уровня доступа к каждому объекту системы», назначенного пользователю вместо «агрегированной роли без детализации»;

6. Критерии последующего расследования и действий. Это означает, что исполнитель контрольной процедуры выполняет полный цикл последующих действий в случае обнаружения отклонения. Например: 1. выявлено отклонение, 2. создан своевременный запрос на исправление, 3. своевременно отклонение устранено, 4. запрос своевременно проверен и закрыт исполнителем контрольной процедуры;

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