Бумажный безопасник. Зачем информационной безопасности человек, который пишет приказы.

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

Один специалист сидит перед несколькими мониторами, разбирает сетевой трафик, ищет аномалии в SIEM, анализирует вредоносные файлы и расследует инциденты.

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

Название неофициальное. При этом сама работа никуда не исчезает. Более того, в крупных компаниях она превращается в самостоятельное направление: compliance, GRC, управление требованиями и контроль соответствия.

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

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

1. Что такое compliance в информационной безопасности​

Compliance в широком смысле означает соответствие деятельности организации установленным требованиям.

Источниками этих требований могут быть:

• федеральные законы;
• постановления Правительства РФ;
• нормативные документы регуляторов;
• отраслевые требования;
• государственные стандарты;
• договорные обязательства;
• внутренние политики компании;
• требования материнской организации или заказчика.

В российской практике информационной безопасности набор требований зависит от того, чем занимается организация и какие данные она обрабатывает.

Например, при работе с персональными данными применяется Федеральный закон № 152-ФЗ «О персональных данных». Он требует от оператора не только технически защищать информацию, но и организовывать соответствующие процессы: назначать ответственного, принимать локальные нормативные акты, проводить внутренний контроль и аудит, оценивать вред, обучать работников и принимать правовые, организационные и технические меры безопасности.

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

Для коммерческой тайны действует отдельный режим. Федеральный закон № 98-ФЗ предусматривает, среди прочего, определение перечня информации, ограничение доступа, установление порядка обращения с такой информацией и учет лиц, получивших к ней доступ.

Государственная тайна представляет собой еще более специализированный режим. Закон РФ № 5485-1 определяет сведения, которые могут относиться к государственной тайне, а организация доступа к таким сведениям возлагается на соответствующих руководителей и подразделения по защите государственной тайны.
Получается важный момент: compliance в ИБ не является одним конкретным законом или набором шаблонов документов. Это система управления множеством требований.

2. Где здесь появляется «бумажный безопасник»​

Представим обычную ситуацию.

Компания обрабатывает персональные данные сотрудников и клиентов.

На техническом уровне у нее есть:

• антивирус;
• межсетевой экран;
• резервное копирование;
• разграничение доступа;
• учетные записи;
• журналы событий;
• средства защиты конечных точек.

С технической точки зрения все выглядит неплохо.

Но возникает вопрос:

Почему эти меры вообще применяются?

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

Именно здесь техническая безопасность встречается с compliance.

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

Поэтому хороший специалист по compliance работает не только с документами.

Он постоянно задает неприятные вопросы:

Что именно мы защищаем?

Нажмите, чтобы раскрыть...

На основании какого требования?

Нажмите, чтобы раскрыть...

Кто за это отвечает?

Нажмите, чтобы раскрыть...

Как это реализовано?

Нажмите, чтобы раскрыть...

Как мы можем доказать, что это действительно работает?

Нажмите, чтобы раскрыть...

Последний вопрос особенно важен.

3. Документ не является доказательством безопасности​

Одна из главных ошибок начинающего «бумажного безопасника» выглядит следующим образом:

Есть приказ → значит, требование выполнено.

Нет.

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

На бумаге все отлично.

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

Кто согласовал ему доступ? Когда? На основании какой заявки? Какие права были предоставлены первоначально? Проверялись ли они после изменения должности? Был ли доступ закрыт после увольнения?

Если ответов нет, приказ существует только как текстовый файл.

С точки зрения управления безопасностью возникает разрыв:

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

Именно этот разрыв compliance-специалист и должен обнаруживать.

4. Четыре уровня «бумажной» безопасности​

Удобно представить работу специалиста как четыре последовательных уровня.

4.1. Требование​

Сначала необходимо понять, что от организации вообще требуется.

Например:

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

Нажмите, чтобы раскрыть...

Это требование законодательства.

Но оно само по себе еще не говорит администратору:

«Выдавай пользователю доступ к системе ровно таким образом».

Нажмите, чтобы раскрыть...

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

4.2. Внутренний документ​

Организация определяет собственные правила.

Например:

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

Это уже зона непосредственной работы compliance.

Но и здесь легко попасть в ловушку.

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

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

4.3. Исполнение​

Следующий вопрос:

А сотрудники действительно делают то, что написано?

Если политика требует ежегодного обучения работников, должны существовать не только пункты в политике, но и:

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

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

4.4. Доказательство​

Последний уровень часто забывают.

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

Именно поэтому в compliance так важны записи, журналы, акты, заявки, протоколы, результаты проверок и отчеты.

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

5. Матрица соответствия: главный инструмент бумажного безопасника​

Один из наиболее полезных инструментов в работе compliance-специалиста - матрица соответствия.

Принцип простой.

Берется нормативное требование и раскладывается на конкретные действия организации.

Например:


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

Например, нормативное требование есть.

Документ есть.

Ответственный назначен.

А подтверждения фактического исполнения нет.

Это уже конкретное несоответствие, которое можно передать ответственному подразделению.

6. Что делает compliance-специалист в течение года​

Работа «бумажного безопасника» редко ограничивается подготовкой комплекта документов перед проверкой.

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

Мониторинг требований → анализ изменений → оценка влияния → актуализация документов → доведение требований до сотрудников → контроль исполнения → внутренний аудит → устранение несоответствий.

Например, изменилось законодательство о персональных данных.

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

Необходимо выяснить:

1. Какие требования изменились.
2. Относится ли изменение к организации.
3. Какие процессы затронуты.
4. Какие внутренние документы необходимо изменить.
5. Нужно ли изменить технические меры.
6. Кто должен выполнить изменения.
7. В какой срок.
8. Каким документом подтвердить выполнение.

Так законодательное изменение превращается в конкретную задачу.

7. Почему compliance должен разговаривать с техническими специалистами​

Плохой вариант взаимодействия выглядит так:

Compliance:

«В соответствии с требованиями необходимо обеспечить регистрацию действий пользователей».

Нажмите, чтобы раскрыть...

Администратор:

«Сделано».

Нажмите, чтобы раскрыть...

На этом разговор заканчивается.

Хороший специалист продолжит задавать вопросы.

Что именно регистрируется? Где хранятся журналы? Какой срок хранения? Кто имеет к ним доступ? Можно ли изменить записи? Кто анализирует события? Что происходит при обнаружении подозрительной активности? Есть ли подтверждение выполнения?

И вот здесь «бумажная» ИБ внезапно начинает соприкасаться с настоящей технической безопасностью.

Законодательство о защите информации само по себе рассматривает защиту как совокупность правовых, организационных и технических мер. Это прямо закреплено, например, в статье 16 Федерального закона № 149-ФЗ.

Поэтому compliance и техническая ИБ не конкурируют.

Они отвечают на разные вопросы.

Технический специалист:

«Как это защитить?»

Compliance:

«Почему это необходимо, какое требование мы выполняем, кто отвечает и как доказать выполнение?»

Руководитель:

«Какой риск остается и сколько стоит его снизить?»

В зрелой системе эти три вопроса должны соединяться.

8. А если речь идет о коммерческой тайне?​

Здесь особенно хорошо видно, почему одного приказа недостаточно.

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

Следовательно, надпись:

«Документ содержит коммерческую тайну»

Нажмите, чтобы раскрыть...

сама по себе не создает полноценный режим коммерческой тайны.

Необходимо построить сам режим.

Что именно относится к коммерческой тайне? Кто имеет доступ? Как сотрудник узнает о таком статусе информации? Как предоставляется доступ? Как он прекращается? Как информация передается подрядчику? Как фиксируется факт передачи? Как организация контролирует соблюдение режима?

Здесь опять возникает цепочка:

информация → режим → правила → доступ → контроль → доказательства.

9. Бумажный безопасник и аудит​

Аудит - один из моментов, когда становится понятно, насколько зрелым является compliance.

Аудитор редко ограничивается вопросом:

«Есть ли у вас политика информационной безопасности?»

Нажмите, чтобы раскрыть...

Гораздо интереснее другой вопрос:

«Покажите, как вы выполняете то, что написано в этой политике».

Нажмите, чтобы раскрыть...

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

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

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

Если проводится внутренний контроль, должны существовать результаты контроля.

В 152-ФЗ внутренний контроль и аудит соответствия прямо названы среди мер, направленных на обеспечение выполнения обязанностей оператора.

Поэтому хороший compliance-специалист готовится не к проверке документов.

Он заранее строит систему, в которой документы и фактические процессы не противоречат друг другу.

10. Самая опасная ситуация: «бумажная безопасность»​

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

Допустим, в организации существует 70 внутренних документов по ИБ.

Никто не знает, какие из них актуальны.

В трех документах по-разному описана процедура предоставления доступа.

В одном приказе ответственным является начальник отдела ИБ, в другом - системный администратор.

Регламент требует ежемесячной проверки, а фактически ее проводят раз в квартал.

Часть сотрудников подписала старую редакцию документа.

Формально система выглядит серьезной.

Фактически она плохо управляется.

Поэтому один из главных принципов compliance можно сформулировать так:

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

Нажмите, чтобы раскрыть...

Количество страниц не является показателем зрелости информационной безопасности.

11. Как должен работать хороший «бумажный безопасник»​

Хороший специалист по compliance не пытается превратить организацию в архив приказов.

Он должен уметь:

11.1. Читать нормативные документы​

Не просто искать знакомые слова, а понимать:

• кому адресовано требование;
• при каких условиях оно применяется;
• что является обязанностью;
• что является правом;
• какие есть исключения;
• кто осуществляет контроль;
• какие документы и подтверждения могут потребоваться.

11.2. Понимать техническую ИБ​

Не обязательно быть инженером SOC или системным администратором.
Но необходимо понимать хотя бы базовые принципы:

• IAM;
• MFA;
• сетевой периметр;
• резервное копирование;
• журналирование;
• EDR;
• SIEM;
• сегментация;
• управление уязвимостями;
• криптографическая защита;
• реагирование на инциденты.

Иначе невозможно проверить, соответствует ли внутренний документ реальной инфраструктуре.

11.3. Уметь задавать правильные вопросы​

Иногда один вопрос полезнее двадцати страниц регламента.

Например:

«Что произойдет с учетной записью сотрудника через пять минут после его увольнения?»

Нажмите, чтобы раскрыть...

Или:

«Кто сегодня утром проверил журнал событий этого сервера?»

Нажмите, чтобы раскрыть...

Или:

«Как мы узнаем, что подрядчик больше не имеет доступа к нашей системе?»

Нажмите, чтобы раскрыть...

Если на эти вопросы нет понятного ответа, проблема уже найдена.

11.4. Уметь работать с доказательствами​

Compliance постоянно работает с подтверждениями:

• приказами;
• заявками;
• журналами;
• протоколами;
• актами;
• отчетами;
• скриншотами;
• выгрузками;
• результатами проверок;
• записями обучения.

Но важно понимать разницу между доказательством и формальностью.

Скриншот настроек системы показывает состояние системы в определенный момент.

Заявка показывает факт согласования.

Журнал показывает события.

Акт проверки показывает результат контрольной процедуры.

Каждое доказательство отвечает на свой вопрос.

12. Где заканчивается compliance и начинается GRC​

Термины часто смешивают.

Compliance отвечает прежде всего за соответствие установленным требованиям.

Risk management работает с рисками: что может произойти, с какой вероятностью и каким будет ущерб.

Governance определяет, как организована система управления и кто принимает решения.

Отсюда появляется понятие GRC: Governance, Risk, Compliance.

В зрелой организации эти направления связаны.

Например:

Законодательство требует защитить определенный тип информации.

Нажмите, чтобы раскрыть...

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

Нажмите, чтобы раскрыть...

Оценивает возможные риски.

Нажмите, чтобы раскрыть...

Выбирает организационные и технические меры.

Нажмите, чтобы раскрыть...

Закрепляет ответственность.

Нажмите, чтобы раскрыть...

Создает внутренние документы.

Нажмите, чтобы раскрыть...

Реализует меры.

Нажмите, чтобы раскрыть...

Проверяет их выполнение.

Нажмите, чтобы раскрыть...

Фиксирует результаты.

Нажмите, чтобы раскрыть...

При необходимости корректирует систему.

Нажмите, чтобы раскрыть...

Именно поэтому современный compliance нельзя сводить к работе с Word и Excel.

Word и Excel - всего лишь инструменты.

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

13. Международный взгляд: compliance как система управления​

Подход хорошо иллюстрирует международный стандарт ISO 37301:2021 «Compliance management systems - Requirements with guidance for use».

ISO рассматривает compliance management system как систему, предназначенную для создания, развития, внедрения, оценки, поддержания и постоянного совершенствования compliance в организации. Стандарт применим к организациям различного размера и типа. В 2026 году ISO подтвердил актуальность ISO 37301:2021.

Это важная мысль.

Compliance - не разовая подготовка к проверке.

Это управленческий цикл.

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

14. Что должен уметь начинающий специалист​

Если человек хочет развиваться именно в направлении compliance/GRC в информационной безопасности, ему не обязательно начинать с изучения нескольких сотен нормативных документов.
Гораздо полезнее выстроить фундамент.

14.1. Первый уровень: нормативная база​

Нужно понимать структуру российского регулирования ИБ и уметь самостоятельно находить актуальные редакции документов.
Для начала полезно разобраться с:

• 149-ФЗ «Об информации, информационных технологиях и о защите информации»;
• 152-ФЗ «О персональных данных»;
• 98-ФЗ «О коммерческой тайне»;
• 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;
• законодательством и подзаконными актами, относящимися к конкретной отрасли;
• нормативными документами ФСТЭК России, ФСБ России и других регуляторов в пределах применимости к конкретной организации.

Важно не заучивать номера статей.

Гораздо полезнее научиться отвечать на вопрос:

«Как это требование превращается в конкретный процесс внутри компании?»

Нажмите, чтобы раскрыть...

14.2. Второй уровень: техническая база​

Нужно понимать хотя бы на концептуальном уровне:

AD → учетная запись → группа → права → ресурс → журналирование
или:
уязвимость → оценка риска → устранение → контроль → подтверждение
или:
инцидент → обнаружение → регистрация → классификация → реагирование → расследование → устранение → отчетность.

Когда специалист понимает эти цепочки, нормативные требования перестают выглядеть абстрактными.

14.3. Третий уровень: практика​

Самое полезное упражнение - взять условную компанию и построить для нее compliance с нуля.

Например:

Компания: интернет-магазин.

Информация:

• данные сотрудников;
• данные клиентов;
• учетные данные;
• договоры;
• финансовая информация.

Далее необходимо определить:

1. Какие требования применяются.
2. Какие процессы обработки существуют.
3. Какие системы участвуют.
4. Какие риски возникают.
5. Какие меры необходимы.
6. Какие документы нужны.
7. Кто отвечает за процессы.
8. Какие доказательства выполнения должны сохраняться.
9. Как будет проводиться внутренний контроль.

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

15. Главный навык «бумажного безопасника»​

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

Сложнее другое.

Получив нормативное требование, специалист должен пройти весь путь:

требование → риск → процесс → ответственность → документ → техническая реализация → контроль → доказательство.

Если на любом этапе появляется разрыв, compliance становится формальностью.

Поэтому хороший «бумажный безопасник» не является противоположностью техническому специалисту.

Он работает на другом уровне той же системы.

Технический специалист защищает инфраструктуру.

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

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

Она становится частью системы информационной безопасности.