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

Автор: Мария Богданова, руководитель проектов ALP ITSM

Мы часто сталкиваемся с ситуациями, когда самыми защищенными организациями становятся те, где ИТ-департамент воспринимается как партнер, а не как карательный орган. В одном проекте по аудиту ИТ‑процессов мы проводили серию интервью с руководителями подразделений. Практически все говорили одно и то же: «В ИТ лучше не обращаться без крайней необходимости, потому что потом начнут разбираться, кто виноват». Одновременно на встречах с руководством звучала обратная позиция: «Все проблемы из‑за ИТ, они вечно тормозят и все ломают».

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

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

Инфраструктура — это только половина дела

На нашей практике было много компаний, которые закупали дорогие серверы, внедряли DLP-системы (системы предотвращения утечек данных) и писали толстые регламенты — но продолжали страдать от инцидентов и простоев. В одном из проектов, куда нас пригласили помочь, проблема тоже сначала воспринималась как техническая. Снижение скорости разработки, уменьшение количества релизов. Внутри команды обсуждали компетенции отдельных сотрудников, качество планирования и постановки задач, нагрузку. Но аудит показал, что ключевая причина не в коде и не в инструментах. Узкое место находилось в структуре принятия решений. Критические согласования проходили через определенных людей, а приоритеты менялись реактивно. В результате команда работала, но система не давала предсказуемого результата.

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

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

Почему наказание опасная практика

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

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

В одном из отделов, где мы проводили аудит, сотрудница случайно нарушила корректность выгрузки в 1С (система автоматизации учета 1С), заметила это, но не сообщила — испугалась, что получит выговор. Команда привыкла, что за каждую ошибку «спрашивают», поэтому вокруг ИТ‑сбоев сформировалась культура замалчивания. В итоге данные не сошлись, сдача отчета была сорвана, конфликт всплыл спустя несколько дней. Уже на разборе стало очевидно: если бы об ошибке сказали сразу, ее можно было бы исправить за считанные минуты.

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

Похожий запрос звучал и в другом проекте, но уже на уровне управленческой команды. На старте обсуждений собственник прямо спросил: проблема в конкретных людях или в системе? Под подозрение попадали CTO, продуктовые владельцы, аналитики. Мы структурировали ситуацию через аудит: разделили персональные зоны ответственности и системные провалы, показали, где сама модель взаимодействия создает перегруз, задержки и конфликты. В результате управленческие решения начали опираться на факты, а не на субъективные оценки и эмоции. Это сильно снижает риск ошибочных кадровых решений, когда «наказывают не того», а корневые причины так и остаются нетронутыми.

Уровни зрелости компании

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

Уровень 0. Нет оформленных документов. Процессы работают на основании опыта сотрудников, которые их ведут и передают информацию о них из уст в уста.

В одной компании мы увидели состояние между «нулевым» и «первым» уровнем зрелости: регламенты частично были, но не применялись на практике. Заявки обрабатывались в мессенджерах, учет прав доступа не велся централизованно. Благодаря аудиту мы выстроили структуру процессов, дали рекомендации по запуску базового Service Desk (служба поддержки пользователей), внедрению SLA (соглашение об уровне сервиса) и фиксации ролей. Это позволило перейти к следующему уровню зрелости — с контролем, метриками и измеримыми улучшениями.

Уровень 1. «Бумажная» безопасность и ИТ. На этой стадии есть папки с должностными инструкциями, политиками ИБ и регламентами, которые сотрудники подписывают при приеме на работу. Формально все выглядит правильно, но по факту правила живут в документах, а не в ежедневной работе.

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

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

Уровень 2. Базовые процессы и контроль. Здесь появляются работающий Service Desk для заявок, регулярные бэкапы, обучение пользователей основам цифровой гигиены. Руководство отслеживает метрики по времени реакции на заявки, проценту доступности сервисов, результатам учебных фишинговых атак.

Есть правила, и их стараются соблюдать. Но коммуникация часто односторонняя: ИТ-отдел «спускает» требования сверху, а пользователи воспринимают их как помеху работе.

В одном проекте формально существовали процессы: канбан-доска, роли, распределение функций. Но при падении скорости разработки никто не мог точно объяснить, где возникает задержка — на этапе постановки задач, согласования архитектуры или в реализации. Процессы были, но не давали управляемости. Аудит выявил разрывы в потоке фичи: позднее подключение разработки к обсуждению, переработки спецификаций, концентрация ключевых решений в одной роли. Это типичная ситуация переходного уровня зрелости — когда структура уже есть, но прозрачности еще нет.

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

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

Уровень 3. Сервисная культура. Здесь ИТ и безопасность встроены в ДНК компании. Сотрудники не боятся сообщать о подозрительных активностях или своих ошибках. ИТ-директор говорит с бизнесом на языке денег и рисков, а не «железок». Регламенты пишутся не для галочки, а как реальные инструкции, упрощающие жизнь.

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

ИТ-аудит — первый шаг к разработке стратегии развития

В одном проекте заказчик честно признался: «Мы не видим общей картины — где теряем ресурсы и в чем слабые места ИТ». Мы провели диагностику процессов — от регистрации инцидентов до управления изменениями — и выявили слабые зоны: единоличную ответственность, отсутствие SLA, хаотичную фиксацию задач. Вместе с клиентом мы сформировали дорожную карту развития: не только по устранению рисков, но и по превращению ИТ в предсказуемую и партнерскую функцию для бизнеса. Аудит стал точкой опоры для дальнейшей трансформации.

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

Что это значит на практике:

1. Диагностика процессов. Мы смотрим, как реально проходят заявки в Service Desk, как быстро блокируются доступы уволенных, как реагируют на сбои вне рабочего времени. В одном кейсе, когда мы начали разбираться с обработкой заявок, выяснилось, что часть обращений приходит по почте, часть — в личку, часть — на словах. Истории обращений нет, статистики тоже. Один из респондентов прямо сказал: «Я написал, но понятия не имею, кто это делает и когда ответят». Для пользователей работа ИТ выглядела как лотерея.
2. Поиск «узких мест». Часто выясняется, что проблема не в плохом сервере, а в том, что системный администратор перегружен рутиной и просто не успевает следить за бэкапами. В одной компании не было ИТ-директора: один человек вел сервера, обслуживал почту и параллельно принимал звонки от пользователей. Бэкапы проверялись «по настроению». Когда вышел из строя один из серверов, оказалось, что последние резервные копии были битые — просто некому было регулярно контролировать их состояние.
3. Разработка стратегии. По итогам аудита мы формируем ИТ-стратегию, которая опирается на общую бизнес-стратегию компании: какие сервисы должны работать без простоев, какие риски недопустимы. Для собственника это ответ на вопрос «во что и зачем мы инвестируем в ИТ», для ИТ‑директора — понятная дорожная карта изменений с приоритетами, сроками и ресурсами. Уже внутри этой рамки появляются конкретные шаги: сначала настраиваем управление доступами и ответственность, затем обучаем людей, и только потом вкладываемся в сложные технические решения.

Принципы ИТ-культуры

Работая над развитием ИТ-инфраструктуры клиентов, я выделил два принципа, которые отличают зрелую ИТ-культуру от «метода кнута и пряника».

1. Сегментированное обучение вместо «курса для всех»

Типичная ошибка — прогнать всех сотрудников через один и тот же скучный инструктаж по ИБ или работе в 1С. Топ-менеджеру, бухгалтеру и курьеру рассказывают одно и то же. Результат — скука и игнорирование.

В одном проекте мы рекомендовали провести обучение по ИТ‑безопасности с учетом специфики отделов. Маркетингу — про фишинговые ссылки и рекламные интеграции, бухгалтерии — про поддельные письма и доступ к 1С, логистике — про мобильные устройства и работу «в поле». До этого все получали один и тот же PDF — длинный, формальный и фактически нечитабельный.

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

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

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

2. Двусторонняя коммуникация

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

Как работает позитивная мотивация

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

В другом проекте мы использовали похожий подход, но без привязки к премиям. Для сотрудников запустили простой рейтинг прохождения обучения с видимым прогрессом команд и еженедельным упоминанием лидеров на общем собрании. Никаких штрафов — только признание и здоровая конкуренция между отделами. Вовлеченность выросла в разы, а уровень прохождения приблизился к 100%.

Эффект был мгновенным. Обучение перестало быть «обязаловкой» и превратилось в командный спорт. Люди в чатах сами подгоняли коллег: «Проходи быстрее, мы отстаем!».

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

Первый шаг для руководителя

Если вы хотите, чтобы ИТ в вашей компании было надежным тылом, а не источником проблем, начните с управленческих шагов:

1. Пересмотрите реакцию на инциденты. Замените вопрос «Кто виноват?» на «Почему процесс позволил этому случиться?». Дайте сигнал: за честное сообщение об ошибке не наказывают.
2. Проведите честный ИТ-аудит. Не формальную инвентаризацию «железа», а проверку процессов. Как на самом деле у вас работают права доступа? Знают ли люди, что делать при атаке шифровальщика? Работают ли бэкапы не на бумаге, а в реальности?
3. Именно такой шаг сделал руководитель в одном из наших проектов. Запрос звучал просто: «Нужно понять, что на самом деле происходит с командой разработки». Не внедрять «модные» методологии и не менять инструменты, а получить объективную картину: где система создает перегруз, где ответственность размыта, а где проблема действительно в исполнении. Результатом стала структурированная модель текущего состояния и понятные управленческие решения, основанные на фактах, а не на ощущениях.
4. Вовлекайте ИТ в бизнес. ИТ-руководитель или ваш внешний партнер, такой как vCIO (внешний директор по информационным технологиям) должен участвовать в планировании бизнеса, чтобы заранее видеть риски.

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

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

С чего начать

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

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