Заявка на предоставление доступа — это внутренний документ, которым сотрудник или его руководитель запрашивает права на работу с информационной системой, базой данных, папкой, сервисом или помещением. Это первый и главный документ в управлении доступом: именно он фиксирует, кто, к чему, на каком уровне и на какой срок получил права — и кто это согласовал. Единой государственной формы для коммерческих компаний нет, но к содержанию заявки есть требования, вытекающие из закона (ФЗ-152, ФЗ-98) и практики информационной безопасности. Ниже — готовый образец, обязательные поля, маршрут согласования, юридическая база, ответственность и самый недооценённый этап — отзыв доступа при увольнении.
Что вы найдёте в статье
- разницу между заявкой на доступ и служебной запиской;
- готовый образец заявки на предоставление доступа;
- таблицу обязательных полей: что писать и зачем;
- принципы ИБ, по которым согласуют доступ (минимальные привилегии, RBAC);
- маршрут согласования с владельцем ресурса и службой ИБ;
- когда заявка обязательна по закону и какая ответственность за нарушения;
- как отозвать доступ при увольнении и не оставить «забытых» учёток.
Заявка на доступ или служебная записка: что оформлять
На практике один и тот же запрос называют по-разному, и это путает. Разберём, когда что применять — формально это внутренние документы с одинаковой юридической силой, разница в степени формализации.
| Документ | Когда применяют | Особенность |
|---|---|---|
| Служебная записка на доступ | разовый запрос, малая компания | свободная форма, адресована конкретному подразделению |
| Заявка на предоставление доступа | поставленный процесс, много систем | унифицированные поля, маршрут согласования, удобна для аудита |
| Приказ о допуске | доступ к ПДн или коммерческой тайне | поимённый список лиц, основание — заявка |
Если запросов на доступ единицы в месяц — хватит служебной записки. Когда систем десятки, а сотрудники регулярно приходят, переводятся и увольняются, нужна именно заявка с фиксированными полями: только так можно ответить на вопрос аудита «у кого какой доступ и на каком основании». Допуск к персональным данным и коммерческой тайне дополнительно оформляется приказом о допуске, а заявка становится его основанием.
Образец заявки на предоставление доступа
Ниже — пример типовой заявки на доступ к информационной системе. Это самый частый сценарий: новому сотруднику нужен доступ к рабочим системам в объёме его задач.
Образец заявки на предоставление доступа
Наименование подразделения: Отдел продаж
Вид документа: ЗАЯВКА НА ПРЕДОСТАВЛЕНИЕ ДОСТУПА
Дата и номер: 06.04.2026, № 112-д
Сотрудник: Иванов Иван Иванович, менеджер по продажам, таб. № 4231
Учётная запись (логин): i.ivanov
Ресурс / система: CRM (модуль «Сделки»), сетевая папка \\server\sales
Уровень прав: чтение и запись (без администрирования)
Роль: Менеджер продаж (по ролевой модели)
Обоснование: приём на работу с 13.04.2026, приказ № 18-к; ведение сделок и клиентской базы
Срок доступа: постоянный (на период работы)
Согласовано: руководитель отдела → владелец CRM → служба ИБ
Отметка о предоставлении: доступ выдан 09.04.2026, администратор Сидоров С. С.
Заявку на временный доступ (на проект, на подмену, на разовую задачу) оформляют так же, но в поле «Срок» указывают конкретную дату окончания — после неё доступ автоматически снимается. Это снижает число «вечных» прав, которые никто потом не пересматривает.
Обязательные поля заявки на доступ
Состав полей не случаен: каждое поле закрывает конкретное требование безопасности или аудита. Вот минимальный набор и зачем нужен каждый элемент.
| Поле | Что писать | Зачем нужно |
|---|---|---|
| Сотрудник | ФИО, должность, подразделение, табельный номер | идентификация субъекта доступа |
| Учётная запись | логин в системе | привязка прав к уникальному идентификатору |
| Ресурс / система | конкретная система, БД, папка, помещение | объект доступа — без «доступ ко всему» |
| Уровень прав | чтение / запись / изменение / администрирование | минимально необходимый объём |
| Роль | роль по ролевой модели (RBAC) | права назначаются роли, а не вручную |
| Обоснование | служебная необходимость | принцип «need to know» |
| Срок | постоянный или дата окончания | временный доступ вместо «навсегда» |
| Согласующие | руководитель, владелец ресурса, ИБ | маршрут и ответственность |
| Отметка о выдаче | кто и когда предоставил | учёт лиц, получивших доступ |
Самые важные и чаще всего пропускаемые поля — «уровень прав», «срок» и «обоснование». Без них заявка превращается в формальность «дать доступ», и сотрудник получает прав больше, чем нужно, и навсегда. Именно из таких заявок потом вырастает неконтролируемая картина доступа, которую невозможно пройти на аудите.
Принципы, по которым согласуют доступ
Чтобы согласующие принимали решение единообразно, а не «на глаз», управление доступом строят на нескольких базовых принципах информационной безопасности. Они же объясняют, почему в заявке именно такие поля.
Принципы предоставления доступа
- Минимальные привилегии (least privilege): ровно столько прав, сколько нужно для работы, и ни одним больше;
- Ролевая модель (RBAC): права назначаются ролям, а сотрудник получает роль — это ускоряет онбординг и упрощает аудит;
- Need to know: доступ только к тем данным, которые объективно нужны для задачи (фиксируется в обосновании);
- Временный доступ: под проект или разовую задачу права выдаются на срок и автоматически снимаются;
- Разделение полномочий: тот, кто запрашивает доступ, не должен сам же его себе согласовывать и выдавать.
Эти принципы — не теория: их соблюдение прямо требуется для информационных систем персональных данных. Приказ ФСТЭК России от 18.02.2013 № 21 относит к обязательным мерам идентификацию и аутентификацию субъектов доступа (группа ИАФ) и управление доступом к объектам (группа УПД) — то есть разграничение прав на основе формальных правил и контроль за их соблюдением.
Маршрут согласования заявки на доступ
Заявка проходит цепочку согласования, где у каждого участника своя зона ответственности. Пропуск любого этапа — это либо избыточные права, либо доступ без обоснования.
| Этап | Кто | Что проверяет / делает |
|---|---|---|
| 1. Инициация | сотрудник или его руководитель | формулирует, к чему и зачем нужен доступ |
| 2. Служебная необходимость | непосредственный руководитель | подтверждает, что доступ нужен для работы |
| 3. Допустимость прав | владелец ресурса (data owner) | какие роли и уровень прав допустимы для его системы |
| 4. Контроль ИБ | служба информационной безопасности | соответствие политике, отсутствие избыточных прав |
| 5. Выдача | администратор системы | технически предоставляет права |
| 6. Учёт | ИБ / администратор | вносит в журнал предоставления доступа |
В компаниях без выделенной службы ИБ этапы 3–5 нередко совмещает один IT-специалист. Это допустимо, но опасно совмещением этапа 2 (обоснование) с этапами выдачи: тогда исчезает контроль, и любой запрос автоматически удовлетворяется. Минимальное требование — чтобы обоснование подтверждал кто-то, кроме того, кто выдаёт доступ. Как встроить такой маршрут в общий документооборот компании, разобрано в гайде «Как организовать документооборот в компании».
Когда заявка на доступ обязательна по закону
Сама по себе заявка — внутренний документ свободной формы. Но в двух случаях закон обязывает разграничивать и документировать доступ, и заявка становится подтверждающим документом.
| Ситуация | Норма | Что требуется |
|---|---|---|
| Доступ к персональным данным в ИСПДн | ст. 18.1, 19 ФЗ-152; приказ ФСТЭК № 21 | правила доступа, список допущенных лиц, регистрация действий |
| Уровень защищённости ИСПДн | Постановление Правительства РФ № 1119 | чем выше уровень (УЗ-1…УЗ-4), тем строже доступ |
| Доступ к коммерческой тайне | ст. 10, 11 ФЗ-98 | учёт лиц, получивших доступ; ознакомление под подпись |
| Банки и финансовые организации | ГОСТ Р 57580.1-2017 | обязательные процессы управления доступом |
По ст. 19 ФЗ-152 оператор обязан защищать персональные данные от неправомерного доступа, устанавливать правила доступа в ИСПДн и регистрировать все действия с данными. По ст. 10 ФЗ-98 режим коммерческой тайны считается установленным только после того, как введён учёт лиц, получивших доступ, — то есть без журнала доступа и заявок режим коммерческой тайны юридически не действует, и привлечь нарушителя к ответственности будет нельзя. Доступ к коммерческой тайне оформляется на основании трудового договора, а работника знакомят с режимом под подпись (ст. 11 ФЗ-98) — здесь же логично сослаться на соглашение о неразглашении (NDA).
Ответственность за нарушение доступа
С 30 мая 2025 года ответственность за нарушения в сфере персональных данных кардинально ужесточена (Федеральный закон от 30.11.2024 № 420-ФЗ): введены крупные и оборотные штрафы, дифференцированные по масштабу утечки. Это превратило «забытые» доступы и утечки из формальности в прямой финансовый риск.
| Нарушение | Норма | Санкция (2026) |
|---|---|---|
| Обработка ПДн без согласия (юрлицо) | ст. 13.11 КоАП (ред. ФЗ-420) | 300 000 – 700 000 ₽ |
| Утечка данных 1 000 – 10 000 субъектов | ст. 13.11 КоАП | 3 – 5 млн ₽ |
| Утечка данных 10 000 – 100 000 субъектов | ст. 13.11 КоАП | 5 – 10 млн ₽ |
| Утечка данных свыше 100 000 субъектов | ст. 13.11 КоАП | 10 – 15 млн ₽ |
| Повторная крупная утечка (оборотный штраф) | ст. 13.11 КоАП | 1 – 3 % годовой выручки (до 500 млн ₽) |
| Разглашение коммерческой тайны работником | пп. «в» п. 6 ч. 1 ст. 81 ТК; ст. 183 УК | увольнение; до 7 лет лишения свободы |
| Доступ к частной жизни со служебным положением | ч. 2 ст. 137 УК | до 4 лет лишения свободы |
Ключевой вывод: большинство утечек происходит не из-за хакеров, а из-за избыточных и неотозванных прав — сотрудник имел доступ, который ему был не нужен, или сохранил его после увольнения. Корректно оформленная и согласованная заявка с принципом минимальных привилегий и своевременный отзыв доступа — это и есть та «организационная мера», отсутствие которой по ст. 19 ФЗ-152 само по себе является нарушением.
Отзыв доступа при увольнении — самый забываемый этап
Жизненный цикл доступа не заканчивается выдачей. Права нужно отзывать при увольнении, переводе на другую должность, окончании проекта или истечении срока временного доступа. На практике именно этот этап проваливается чаще всего.
Что сделать при увольнении сотрудника
- оформить заявку (служебную записку) на отзыв доступа или внести пункт в обходной лист;
- заблокировать учётные записи в последний рабочий день — во всех системах, а не только в домене;
- проверить доступы в облаках, мессенджерах, таск-трекерах и порталах, не связанных с Active Directory;
- отозвать выданные доверенности и забрать материальные носители с коммерческой тайной (ст. 11 ФЗ-98);
- внести отметку об отзыве в журнал предоставления доступа;
- при доступе к ПДн — исключить сотрудника из списка лиц, допущенных к обработке.
Главная угроза — «осиротевшие» учётные записи (orphaned accounts): IT блокирует доменную учётку и считает задачу закрытой, а доступы в десятках облачных сервисов остаются активными. Уволенный сотрудник продолжает видеть данные, а по документам у него «доступа нет». Поэтому зрелые компании проводят регулярную ресертификацию — периодический пересмотр всех прав, а не только разовую блокировку. Отзыв доступа и контроль доверенностей сотрудника логично закрывать одним процессом увольнения — здесь смежная тема машиночитаемых доверенностей (МЧД), которые тоже нужно вовремя отзывать.
Электронная заявка на доступ в СЭД
Заявку на доступ удобно вести электронно: маршрут согласования проходит автоматически, а факт выдачи фиксируется без ручного журнала. С точки зрения закона это полностью легитимно.
По ст. 6 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи» документ, подписанный простой электронной подписью (ПЭП), равнозначен бумажному с собственноручной подписью при наличии внутреннего регламента. Заявка на доступ — внутренний документ, поэтому усиленная квалифицированная подпись не нужна: достаточно ПЭП — действия в корпоративной системе.
Что нужно для юридически значимой электронной заявки
- положение об электронном документообороте с правилами использования ПЭП;
- регламент управления доступом, описывающий форму заявки и маршрут согласования;
- ознакомление сотрудников с регламентом под подпись (или ПЭП);
- система СЭД с фиксацией факта подписи и историей согласования.
Регламент управления доступом — это локальный нормативный акт, который образует единый контур вместе с Положением о коммерческой тайне (ст. 10–11 ФЗ-98) и Политикой обработки персональных данных (ст. 18.1 ФЗ-152). Эти три документа должны быть непротиворечивы. Подробнее о переходе на электронные внутренние документы — в гайде по электронному документообороту.
Сколько хранить заявки на доступ
Точечной статьи именно для «заявки на доступ к информационной системе» в Перечне типовых документов (Приказ Росархива от 20.12.2019 № 236) нет, поэтому срок определяют по аналогии. Журналы регистрации и учёта документов по административно-хозяйственной деятельности хранятся 5 лет, документы о соблюдении дисциплины труда — 3 года.
Практическая рекомендация: заявку на доступ и отметку об отзыве целесообразно хранить не менее 5 лет или в течение всего срока трудовых отношений плюс 5 лет. Это покрывает сроки давности по трудовым и административным спорам и позволяет на аудите доказать, на каком основании сотрудник получил и потерял права. Полная матрица сроков для всех типов документов компании — в гайде «Сроки хранения документов в организации».
Типичные ошибки в заявках на доступ
Что чаще всего обнаруживается на аудите доступа
- доступ выдан «на всякий случай» шире, чем нужно для работы — нарушение принципа минимальных привилегий;
- не указан срок — временный доступ под проект остался навсегда;
- нет обоснования — невозможно понять, зачем сотруднику эти права;
- заявку согласовал и выдал один человек — нет разделения полномочий;
- доступ не отозван после увольнения — «осиротевшие» учётки в облаках;
- журнал предоставления доступа не ведётся — режим коммерческой тайны юридически не действует (ст. 10 ФЗ-98).
Самая дорогая из этих ошибок проявляется не сразу: избыточный или неотозванный доступ всплывает во время утечки или проверки Роскомнадзора — когда штраф по ст. 13.11 КоАП уже считается миллионами, а доказать «организационные меры» по ст. 19 ФЗ-152 нечем.
Когда переводить заявки на доступ в систему
Заявки на бумаге и в почте работают, пока сотрудников немного. Сигнал «пора в систему» возникает, когда совпадают три ситуации: число систем и сервисов перевалило за десяток; сотрудники регулярно приходят, переводятся и увольняются; служба ИБ или аудит запросили картину «у кого какой доступ» — и собрать её из почты и Excel не удалось.
Посчитайте, во что обходятся неконтролируемые доступы
ROI-калькулятор Cloudwork оценит риски утечек, штрафов и потерь времени на ручное управление доступом.
Открыть калькулятор →В Cloudwork заявка на доступ живёт в карточке документа: с полями по регламенту, маршрутом согласования (руководитель → владелец ресурса → ИБ → выдача), сроком доступа и автоматической связкой с приказом о допуске. История согласования и факт выдачи фиксируются автоматически — это закрывает и требование учёта по ст. 10 ФЗ-98, и операционный риск «забытых» доступов при увольнении.
Неотозванный доступ = открытая дверь после увольнения
Большинство утечек и штрафов по ПДн — это не взлом, а избыточные и забытые права. Cloudwork ведёт заявки на доступ с маршрутом согласования, сроком и журналом выдачи — и напоминает отозвать права при увольнении, чтобы ни одна учётка не осталась «осиротевшей».
Навести порядок в доступах →Материал носит информационный характер и не заменяет юридическую консультацию или консультацию специалиста по информационной безопасности. Ссылки на ФЗ-152 «О персональных данных» (ст. 18.1, 19), ФЗ-98 «О коммерческой тайне» (ст. 10, 11), ФЗ-63 «Об электронной подписи» (ст. 6), приказ ФСТЭК России от 18.02.2013 № 21, Постановление Правительства РФ от 01.11.2012 № 1119, ст. 81, 243 ТК РФ, ст. 137, 183 УК РФ, ст. 13.11 КоАП РФ (в редакции ФЗ от 30.11.2024 № 420-ФЗ, действует с 30.05.2025), ГОСТ Р 57580.1-2017 и Приказ Росархива от 20.12.2019 № 236 актуальны на 9 июня 2026 года; размеры штрафов и нумерация частей ст. 13.11 КоАП могут уточняться — перед применением сверяйтесь с действующей редакцией.
