Защита персональных данных: организационные меры и регламенты

Что такое организационные меры защиты данных?

3 из 5 компаний в РФ в 2025-2026 всё ещё думают, что защита персональных данных — это антивирус и пароль посложнее. На деле всё наоборот: сначала организационные меры, уже потом техника и автоматизация.

Организационные меры защиты данных — это набор ролей, правил и документов, по которым в компании обращаются с персональными данными, чтобы выполнять 152-ФЗ и не допускать утечек. Если убрать пафос, это очень приземлённая история: кто за что отвечает, какие данные где лежат, кто к ним может подойти и что делать, если что-то пошло не так. Без этого любые шифрования висят в воздухе — формально вроде всё красиво, а Роскомнадзор в акте пишет, что процессов-то нет.

Согласно 152-ФЗ и разъяснениям Роскомнадзора (официальный ресурс ведомства), оператор обязан обеспечить конфиденциальность информации, описать процессы обработки и назначить ответственных. То есть закон прямо толкает нас в сторону организационных мер, а не магических галочек в CRM. Я для себя давно сформулировала это так: техника защищает данные, но приказы и регламенты защищают вас на проверке и в суде.

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

Чем организационные меры отличаются от технических

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

Если представить, что защита данных — это офис с сейфом, то техническая часть — это прочность сейфа и сигнализация, а организационная — кто имеет ключ, где он хранится, как фиксируются заходы в комнату, что происходит, если ключ потеряли. По данным Gartner за 2024 год, до 80 % инцидентов связаны с человеческим фактором и процессами, а не с провалом техники (отчёты по киберустойчивости). Это означает, что без адекватных организационных мер даже лучший DevSecOps не спасёт.

Как понять, что у вас с этим всё плохо

Очень приземлённый чек: если я спрашиваю компанию, кто отвечает за защиту персональных данных, и в ответ слышу «ну у нас безопасник есть, он за всё», это почти всегда тревожный флажок. Когда прошу показать регламент обработки ПДн, а мне присылают только политику на сайте — второй флажок. Третий — когда никто не может быстро объяснить, куда писать и звонить, если нашли утечку или подозрительную активность.

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

Как работают приказы по защите ПДн?

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

С точки зрения практики, приказы — это скелет организационной защиты. Они оформляются от имени руководителя, привязываются к 152-ФЗ и смежным актам, а потом уже «обрастают» регламентами, инструкциями и настройками в системах. По данным Роскомнадзора из публичных проверок 2023-2024 годов, отсутствие базовых приказов — один из частых поводов для предписаний и штрафов (открытые акты проверок).

Чтобы было не теоретически, покажу, какие приказы по защите ПДн я считаю минимальным набором для компании, которая хотя бы собирает заявки на сайте и ведет базу клиентов в CRM. Да, даже если вы «просто стартап на no-code без юрлица» — закон вас всё равно видит.

• Приказ о назначении ответственного за обработку и защиту ПДн.
• Приказ об утверждении политики обработки персональных данных и её публикации.
• Приказ о порядке доступа к ПДн и разграничении прав.
• Приказ о мерах при инцидентах и уведомлении Роскомнадзора.
• Приказ об обучении и ознакомлении сотрудников с требованиями.

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

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

В малом бизнесе это редко отдельная должность, и закон этого не требует. Ответственным по защите персональных данных может быть руководитель, юрист, руководитель IT или службы безопасности, иногда — HR. Критично только одно: назначить его приказом, прописать полномочия и не забыть дать реальные инструменты влияния, а не просто должностную «галочку».

Текст приказа обычно включает ссылку на 152-ФЗ, круг задач (организация обработки, взаимодействие с Роскомнадзором, контроль регламентов) и подчинённость. В проектах PROMAREN я вижу, как меняется отношение к теме, когда такой приказ подкреплён регулярными отчётами по инцидентам и чек-листами по обновлению регламентов, а не лежит мёртвым грузом в папке «кадры». Тут же удобно зашить обязанность инициировать обновление документов при изменении процессов.

Как связать приказы с реальной работой систем

Стоп, вернусь на шаг назад — сам по себе приказ не делает защиту данных работающей. Если в приказе написали одно, а в n8n-сценариях и CRM живёт совсем другое, проверяющий это увидит за 10 минут. Поэтому я всегда делаю связку: приказ — реестр процессов — настройки в системах.

Например, в приказе о доступе к ПДн мы фиксируем, что менеджеры видят только «свои» сделки, а полные выгрузки может делать только администратор. После этого в той же CRM или в Make-сценариях настраиваем роли, а в регламенте описываем, как и кто выдаёт/отзывает доступ. Именно эта связка часто спасает на проверках: можно показать, что не просто написали красивые слова, а построили рабочий механизм. И неудивительно, что следующий логичный вопрос — а где всё это детально описано.

Какие обязательные регламенты для защиты персональных данных?

Если приказы отвечают на вопрос «кто и в общих чертах что делает», то регламенты — «как именно мы защищаем данные в деталях». Без них защита персональных данных превращается в набор благих намерений.

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

По методике white-data PROMAREN я всегда начинаю архитектуру с такого реестра, даже если клиент очень хочет сразу «подключить ИИ-агента к базе заявок». Сначала описываем, какие у нас вообще персональные данные, а уже потом даём к ним умный доступ. Иначе агент бодро начнёт читать поля, которые по регламенту вообще не должны были оказаться в этой системе.

Обязательные типы регламентов: что должно быть на бумаге

Минимальный набор регламентов по защите персональных данных в 2026, который я вижу у тех, кто уверенно проходит проверки, примерно такой. Формулировки могут гулять, но суть одна и та же, независимо от сферы — онлайн-образование, маркетплейсы, офлайн-услуги.

1. Регламент (реестр) обработки ПДн по всем процессам.
2. Регламент управления доступом и учётных записей.
3. Регламент уведомления и реагирования при утечках.
4. Регламент трансграничной передачи данных (если есть внешние сервисы).
5. Регламент сбора и хранения согласий субъектов.

Внутри PROMAREN мы ещё добавляем отдельный короткий регламент по автоматизации: какие сценарии n8n/Make могут трогать персональные данные, как логируются операции, где хранятся токены. Формально закон об этом не говорит, но это сильно упрощает жизнь аудиторам и собственникам, когда через пару лет никто не помнит, кто собрал тот или иной сценарий.

Как регламенты помогают на проверках и в жизни

Здесь работает немного парадоксальная вещь: Роскомнадзор всё чаще смотрит не только на сами документы, но и на то, живут ли они в практике. Когда в 2023-2024 годах массово начали требовать уведомления об обработке и подробные описания процессов, сразу стало видно, кто регламенты писал «под проверку», а кто реально по ним живет.

Был кейс: у онлайн-сервиса обучения регламент обработки ПДн на 25 страниц выглядел безупречно. Но когда мы начали сопоставлять его с архитектурой заявок и платёжных сценариев, оказалось, что в автоматизации через n8n данные студентов отправляются в ещё две внешние системы, про которые в регламенте вообще ни слова. Мы за два дня переписали описание процессов, добавили трансграничную передачу и сроки хранения, а потом клиент безболезненно ответил на запрос Роскомнадзора. Живой регламент — это не про красоту текста, а про совпадение «как написано» и «как работает».

Где регламент заканчивается и начинается автоматизация

Ладно, к делу. Частый вопрос в 2025-2026 — где провести границу между «бумажным» регламентом и настройками в системах, особенно когда половина процессов живёт в no-code. Я делю так: в регламенте описываем принципы и ограничения (какие данные, какие роли, какие сроки, какие внешние сервисы), а в технической документации и в сценариях — конкретные реализации.

Например, в регламенте фиксируем, что заявки с сайта с ПДн попадают только в CRM и 1С, хранятся не больше трёх лет и доступны менеджеру, супервайзеру и бухгалтеру. А в n8n-сценарии уже конкретные узлы, куда дальше улетает вебхук, и как именно происходит очистка старых записей. На сайте PROMAREN в разделе кейсы автоматизации я периодически показываю такие связки «регламент — сценарий», потому что без этого бизнесу сложно почувствовать, что документ вообще на что-то влияет.

Почему важна защита персональных данных?

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

Причин, почему защита персональных данных выходит на первый план в 2025-2026, сразу несколько. Законодатели подтягивают требования, Роскомнадзор активнее ходит по рынку, пользователи стали внимательнее к тому, куда попадает их номер и паспорт. И плюс ко всему бизнес за последние два года массово уехал в онлайн, в облака, в интеграции — а значит, поверхность атаки и просто ошибок удвоилась.

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

Финансовые и юридические последствия игнора

Если смотреть сухо по закону, 152-ФЗ и КоАП дают довольно широкий разброс штрафов — от нескольких тысяч до миллионов рублей, в зависимости от состава нарушения. Штрафы за отсутствие политики, неподачу уведомлений, нарушение порядка обработки, утечки — всё это реальность, а не страшилки юристов. С 2022 года Роскомнадзор чаще пользуется правом приходить не только к гигантам, но и к вполне среднему бизнесу, включая онлайновые школы и сервисы.

Но штрафы — даже не самое болезненное. Куда неприятнее предписания «устранить нарушения», которые тянут за собой аврал: за 30 дней написать регламенты, перестроить интеграции, научить сотрудников, привести в порядок формы. Я видела кейс, где компания заплатила относительно небольшой штраф, но потом полгода жила в режиме «ничего нового не запускаем, пока не разгрeбём требования по ПДн». С точки зрения продукта это сильно больнее.

Репутация, клиенты и немного человеческого фактора

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

В канале PROMAREN я иногда разбираю кейсы утечек без названий компаний, и каждый раз одно и то же: у руководства до инцидента была уверенность, что «у нас всё нормально, потому что IT говорит, что безопасно», а после — паника и ночные чаты. Организационная защита персональных данных нужна не только для Роскомнадзора, а чтобы люди внутри компании спали спокойнее. Когда есть понятные приказы и регламенты, намного проще объяснить клиенту и самому себе, что именно было сделано и что будет сделано дальше.

Можно ли обойтись без регламентов по защите данных?

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

Компания без регламентов по защите данных живёт на устных договорённостях. Сегодня менеджеру «можно взять базу домой поработать», завтра он уволился, послезавтра база всплыла где-то в объявлениях. Кажется утрированным примером, но Роскомнадзор в своих отчётах регулярно описывает похожие случаи, там только фамилии и ИНН другие. В 2025-2026 это уже не воспринимают как невинную ошибку — скорей как признак системной халатности.

Я раньше думала, что для маленьких команд можно ограничиться одной политикой на сайте и парой приказов, а всё остальное «додумаем по ходу» (нет, лучше скажу иначе) — надеялась, что так можно. После нескольких проверок и одного неприятного спора с контрагентом стало очевидно: без чётких регламентов по ПДн бизнес становится уязвимым не только к госорганам, но и к партнёрам и самим клиентам.

Что ломается первым, когда регламентов нет

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

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

Как сделать регламенты живыми, а не формальными

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

Поэтому в проектах PROMAREN мы делаем так: сначала описываем процессы в регламентах, потом сразу смотрим, как их отразить в сценариях n8n/Make и в CRM, и одновременно готовим короткие инструкции или микро-курсы для команды. Где-то это отдельный урок в корпоративной Академии, где-то — просто страница в Notion с примерами «можно/нельзя». Да, это занимает не пару часов, а иногда пару недель ха-ха полтора месяца, но результат того стоит: регламенты перестают быть мёртвым грузом, а защита данных становится частью нормальной операционки, а не разовой акции «перед проверкой».

Когда защита данных перестаёт быть страшилкой

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

Получается простой, но не всегда очевидный вывод: организационные меры — это не про «бумажки ради закона», а про честную архитектуру работы с данными. Чем раньше компания к этому приходит, тем меньше у неё авралов, бессонных ночей и внезапных «а покажите регламент» посреди сделки с партнёром. Если эта статья помогла тебе взглянуть на приказы и регламенты спокойнее, считай, уже неплохо 🙂

Обо мне. Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead. С 2024 года помогаю в РФ строить автоматизацию на n8n, Make.com, Cursor, внедряю AI-агентов и выстраиваю защиту данных. Пишу в блоге и канале.

Если хочется разложить именно ваши процессы по защите данных и автоматизации, загляни на сайт PROMAREN или забери разборы и примеры в демо-боте. Там много практики про n8n, Make и аккуратную работу с ПДн без лишнего хайпа.

Что ещё важно знать про защиту персональных данных

Можно ли использовать облака Yandex и Google и не нарушать 152-ФЗ?

Можно, но только если правильно оформить трансграничную передачу данных и не складывать в зарубежные облака больше, чем нужно. Для Yandex в большинстве случаев речь идёт о локальной инфраструктуре в РФ, а вот с Google и другими иностранными сервисами почти всегда включается режим трансграничной передачи. Здесь критично: описать эти сервисы в регламенте, уведомить Роскомнадзор при необходимости и ограничить состав передаваемых персональных данных только тем, что реально нужно для оказания услуги.

А если я собираю только email для рассылки, это тоже персональные данные?

Да, email почти всегда относится к персональным данным, потому что через него можно идентифицировать человека или связаться с ним напрямую. Даже если у вас маленькая форма подписки на новости, формально вы становитесь оператором ПДн со всеми вытекающими обязанностями. Минимальный набор: политика обработки на сайте, понятный текст согласия под формой, приказ о назначении ответственного и хотя бы базовый регламент обработки. Это небольшой объём работы, но он сильно снижает риски при жалобах пользователей.

Что делать, когда Роскомнадзор прислал запрос о предоставлении документов?

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

Можно ли использовать типовые шаблоны регламентов из интернета?

Можно, но без адаптации к вашим реальным процессам это почти бесполезно и местами даже опасно. Типовой шаблон не знает, какие у вас системы, интеграции, какие именно данные вы обрабатываете и кто к ним имеет доступ. В итоге на проверке Роскомнадзор видит красивый, но оторванный от жизни документ, и это вызывает больше вопросов, чем честный, но короткий регламент. Логика такая: взять шаблон как основу, выкинуть лишнее, дописать под себя и сверить с тем, как реально настроены сервисы и автоматизация.

Как часто нужно пересматривать приказы и регламенты по ПДн?

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