GDPR-комплаенс для белорусских IT-вендоров, работающих с EU-клиентами

Картинка, которую мы наблюдаем последние пару лет.

Белорусская IT-компания выигрывает технический разговор с европейским клиентом. Сильное портфолио, рабочие референсы, химия на звонках есть, цена конкурентная. Все на колле думают, что сделка вот-вот закроется. Дальше разговор уходит в юридическую часть и комплаенс — и где-то между предложением и подписанным контрактом сделка замолкает. Иногда EU-клиент вежливо отвечает «мы решили взять кого-то поближе». Чаще — просто перестаёт писать.

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

Эта статья разбирает, что происходит на той стороне комплаенс-ревью. Что EU-клиенты реально спрашивают. И как в 2026 году выглядит практическая конструкция — та, которая проходит прокьюремент, а не остаётся в нём навсегда.

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

Стартовый факт, который многие понимают неправильно

Беларусь не входит в список стран с адекватной защитой данных по версии Еврокомиссии. Этот один факт объясняет большую часть того, что дальше в статье — и регулярно удивляет белорусские IT-компании, когда они с этим сталкиваются впервые.

По GDPR, персональные данные жителей ЕС свободно ходят внутри Европейской экономической зоны, плюс в небольшой список стран, которые Еврокомиссия признала «адекватными» — Великобритания, Швейцария, Япония, Южная Корея, Израиль, ещё несколько. Беларуси в этом списке нет. Поэтому любая передача персональных данных от EU-клиента к белорусскому процессору — это передача в третью страну, и включается Глава V GDPR. Нужно дополнительное правовое основание. Почти всегда это Стандартные договорные условия Еврокомиссии — и со времён решения Schrems II в 2020 году, плюс Transfer Impact Assessment поверх.

Тут белорусские IT-компании иногда возражают: «У нас же есть соответствие белорусскому закону о защите персональных данных. Закон № 99-З от 2021 года. Этого недостаточно?»

Достаточно для того, что белорусское право требует от вас на территории Беларуси. Не заменяет механику со стороны ЕС. Белорусский закон в целом построен на принципах GDPR, но Еврокомиссия его адекватным не признала, и EU-клиенты продолжают трактовать Беларусь как третью страну. Локальный комплаенс необходим — он просто не самодостаточен. Документация по передаче должна быть у EU-клиента независимо от того, что вы там настроили локально.

Это не уникальная для Беларуси ситуация. Большинство стран за пределами ЕЭЗ в той же позиции. Просто стоит понимать, что «у нас есть Privacy Policy с упоминанием GDPR» в европейском прокьюремент-разговоре весит сильно меньше, чем некоторым белорусским вендорам кажется.

Что EU-клиенты реально спрашивают — и о чём на самом деле беспокоятся

По разговорам с клиентами с обеих сторон наших сделок, вопросы, которые мы слышим в прокьюременте чаще всего:

«Где находятся данные?» — хотят понять, уходят ли персональные данные физически за пределы ЕС.
«Где находятся ваши инженеры?» — потому что доступ белорусского инженера к данным, лежащим в EU-датацентре, по GDPR сам по себе является передачей, даже если сами данные никуда не двигаются.
«У вас подписаны Стандартные договорные условия?» — в 2026 году это уже table stakes, а не преимущество.
«Вы делали Transfer Impact Assessment по Беларуси?» — в 2025–2026 годах спрашивают всё чаще; ещё пару лет назад спрашивали редко.
«Что белорусское законодательство говорит про доступ государства к персональным данным?» — это Schrems II-вопрос, применённый напрямую к вашей юрисдикции.
«Вы GDPR-compliant?» — вопрос, который значит не совсем то, как звучит. Имеется в виду: можете ли вы подписать наш DPA, пройти наш security review и не создать проблему нашему комплаенс-отделу.
«У вас есть Data Protection Officer?» — иногда требуется по закону, чаще ожидается и там, где закон не требует.

Под этими вопросами беспокойство обычно не про формальный закон. Оно про репутационный риск. Про аудиторский след. Про возможность того, что субъект данных подаст жалобу, регулятор откроет проверку, и документация белорусского вендора станет проблемой EU-клиента — а не вендора. EU-клиент — это data controller. Ответственность по GDPR несёт он. Ваша задача в прокьюременте — убедить его, что работа с вами не увеличивает его поверхность риска так, как он потом не сможет защитить.

Проблема Schrems II — на обычном языке

В июле 2020 года Суд ЕС вынес решение по делу Schrems II, которое изменило практический разговор про передачу данных в третьи страны. Громкая часть решения — Privacy Shield между ЕС и США признан недействительным. Более широкая часть, важная для всех остальных — одних SCC недостаточно.

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

Через год Европейский совет по защите данных (EDPB) выпустил рекомендации по этим дополнительным мерам, и эти рекомендации сейчас лежат в центре любого серьёзного прокьюремент-ревью с участием вендора из третьей страны. Для вендора из Беларуси честный TIA включает белорусский закон о защите персональных данных как локальную рамку, операционную реальность государственного доступа к данным белорусских компаний, и конкретные дополнительные меры, которые вендор применяет для митигации рисков.

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

Тут отделяется полезный TIA от бесполезного. TIA, который пишет «по Беларуси никаких рисков, дополнительные меры не нужны» — это документ, который провалит ревью у любого серьёзного комплаенс-офицера на EU-стороне. TIA, который пишет «вот реальные риски в части государственного доступа, вот конкретные меры, которые мы применяем, вот почему именно эти данные можно передавать именно с этими ограждениями» — это документ, который EU-комплаенс реально примет. Честность в оценке — то, что её утверждает.

Контрактный слой — SCC, DPA и чего ждёт иностранный юрист

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

Стандартные договорные условия (2021)

Обновлённая редакция SCC от Еврокомиссии принята в июне 2021 года и с тех пор работает как практический инструмент передачи. Сделаны модульно — controller-to-controller, controller-to-processor, processor-to-processor — и белорусский вендор подписывает тот модуль, который соответствует его роли. Чаще всего это processor или sub-processor. Официальный текст и руководство — на странице SCC у Еврокомиссии.

Data Processing Agreement (статья 28 GDPR)

EU-клиент как controller хочет DPA, который описывает scope обработки, цели, категории данных, меры безопасности, правила по sub-процессорам, механику уведомлений об инцидентах и аудиторские права. Иногда DPA — отдельный документ; иногда оформляется как приложение к основному соглашению об услугах. Задача белорусского вендора — внимательно прочитать его до подписания, а не после.

Документация по цепочке sub-процессоров

Если вы используете облачных провайдеров, сторонние инструменты, downstream-подрядчиков, которые соприкасаются с персональными данными, — у вас есть sub-процессоры. DPA потребует их перечислить, получить одобрение клиента и уведомлять об изменениях. Белорусские вендоры, у которых это нигде не задокументировано, ловят неловкие разговоры через несколько месяцев, когда клиентский аудит вскрывает нераскрытого sub-процессора.

Одна ошибка, которую мы регулярно видим. EU-прокьюремент кладёт перед белорусским вендором свой стандартный DPA, и вендор подписывает его, не вчитываясь в операционные обязательства. Через год что-то происходит — небольшой инцидент с данными, смена sub-процессора, запрос на аудит — и в фокус попадают обязательства, которые вендор по факту не может выполнить. Сроки уведомления, привязанные к нереалистичным цифрам. Аудиторские права, требующие раскрытия того, что по локальному законодательству раскрыть нельзя. Договаривайтесь на стадии подписания. Не бойтесь править DPA. EU-клиенты уважают вендора, который читает то, что подписывает, сильнее, чем того, кто просто подписывает.

Технический и организационный стек, который реально работает

Помимо бумаг есть операционный стек, который захочет увидеть security-команда EU-клиента. Практические дефолты для белорусского IT-вендора, работающего с EU-заказчиками в 2026 году:

EU-хостинг по умолчанию. AWS Frankfurt, Azure West Europe, Google Cloud Belgium. Одно это решение снимает существенную часть разговора про передачу — данные физически остаются в ЕС, а трансграничной становится только сторона доступа.
Контроль доступа и логирование аудита. Кто к каким данным обращался, когда, с какой целью. Хранится столько, сколько требует контракт и ваша юрисдикция. Доступно EU-клиенту по запросу во время аудита.
Шифрование в передаче (TLS) и в покое, с ключами в ЕС там, где сценарий позволяет. Шифрование — одна из ключевых дополнительных мер, на которые ссылается EDPB.
Псевдонимизация и минимизация данных. Инженеры, работающие с реальными клиентскими данными, должны иметь доступ к минимально необходимому срезу, по возможности псевдонимизированному. «Продакшн-данные на ноутбуке разработчика» — один из самых быстрых способов провалить security review.
Назначенный DPO, где требуется по статье 37 GDPR — крупномасштабный систематический мониторинг, крупномасштабная обработка специальных категорий данных. Даже там, где формально не требуется, наличие назначенного DPO с контактами сигналит серьёзность.
Документированная процедура уведомления об инциденте с часами в 72 часа. Процедура должна быть написана, протестирована и известна команде. Не придумываться в момент, когда что-то реально произошло.
Поддерживаемый список sub-процессоров, раскрытый клиенту, с согласованной механикой уведомления об изменениях.

У компаний-резидентов Парка высоких технологий большая часть этого уже встроена в стандартную энтерпрайз-практику. Режим ПВТ поддерживает безбумажное создание контрактов, англоязычные коммерческие отношения и элементы английского коммерческого права — всё это делает EU-контрактный разговор глаже. У не-ПВТ-компаний разрыв обычно шире, и именно там обычно концентрируется setup-работа, прежде чем серьёзные EU-контракты подписываются.

То, о чём не принято говорить открыто: санкционная надстройка

Вот раздел, который отделяет честную статью от маркетингового материала. У части EU-клиентов есть внутренние прокьюремент-политики, которые идут шире, чем требует GDPR. Они не работают с вендорами из стран в определённых санкционных списках — независимо от того, насколько чисто настроена GDPR-сторона. Это не вопрос по GDPR. Это вопрос корпоративной политики. И это всё чаще становится реальной причиной, по которой белорусские IT-вендоры теряют европейские сделки.

Формальный GDPR-разговор можно пройти. Внутренний политический фильтр пройти сложнее, потому что это не правовой тест — это тест на risk appetite, который ставит руководство комплаенс-функции у EU-клиента. Иногда планка из Беларуси недосягаема, независимо от того, насколько хорошая у вендора документация. Иногда это управляемо, но требует от вендора думать о структуре, а не только о комплаенсе.

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

Только Беларусь, с сильной документацией

Вендор заключает контракты напрямую из Беларуси, с SCC, DPA, TIA и полным операционным стеком. Работает с небольшими EU-клиентами без ограничивающих прокьюремент-политик; работает и там, где отношения сложились до того, как политика затянулась. Дёшево по setup. Не пройдёт у энтерпрайзов с жёсткими политиками по третьим странам.

Беларусь плюс EU-юрлицо

Вендор открывает дочернюю компанию или филиал в одной из EU-юрисдикций — Польша, Литва, Кипр — встречаются чаще всего. Это юрлицо заключает контракт с EU-клиентами напрямую. Белорусская компания становится внутриенним со-процессором под основным контрактом EU-дочки. Заметно проще проходит прокьюремент. Дороже в открытии и поддержании. Не убирает базовую GDPR-механику — внутригрупповая передача всё равно требует SCC и TIA — но меняет коммерческий фасад на тот, который EU-прокьюременту принять проще.

Белорусский вендор как субподрядчик под EU-генподрядчиком

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

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

Типичные ошибки белорусских IT-вендоров

Закономерности, которые мы видим стабильно.

Принимать комплаенс за Privacy Policy на сайте

«У нас на сайте есть GDPR-compliant Privacy Policy». Это нужно, но это не то, что спрашивает прокьюремент-ревью у EU-клиента. Они спрашивают про операционную систему — задокументированную, проверяемую, защитную под нагрузкой. Privacy Policy — это обложка. Содержание — это операционный стек за ней.

Подписать DPA EU-клиента, не вчитываясь в операционные обязательства

В DPA от EU-прокьюремента иногда лежат обязательства, которые белорусский вендор по факту не может исполнить как написано. Сроки уведомления, привязанные к конкретным локальным нормам. Аудиторские права, конфликтующие с белорусскими нормами о конфиденциальности. Требования прямого уведомления субъектов данных, не подходящие под операционную реальность. Подпись без чтения создаёт проблемы, которые всплывают через год во время аудита. Прочитать. Поправить. Подписать — в таком порядке.

Нет задокументированного Transfer Impact Assessment

В 2026 году отсутствие TIA всё чаще становится тем, что валит прокьюремент-проверку. EU-клиенты больше не относятся к TIA как к необязательной документации — они трактуют его как обязательный артефакт в файле. Белорусский вендор без TIA проигрывает с конкретно и легко исправимым минусом.

Инженеры работают с реальными данными клиента без контролей

Продакшн-данные на личных ноутбуках. Дампы баз, отправленные через мессенджеры. Реальные записи EU-клиентов, использованные в dev-окружениях, потому что генерировать seed data — морока. Какая-то версия этого всплывает на каждом аудите. Лечится технически и организационно — контролируемые окружения, псевдонимизированные dev-данные, реальное логирование доступа.

Нераскрытые sub-процессоры

Облачный провайдер, почтовый сервис, мониторинг, аналитика. Каждый из них может обрабатывать персональные данные ЕС от вашего имени, и каждый должен быть в задокументированном списке sub-процессоров, раскрытом EU-клиенту. Нераскрытый sub-процессор — один из самых быстрых способов провалить аудит.

Считать локальный комплаенс заменой механике GDPR

Уже говорили выше, повторим, потому что это фундамент. Соответствие белорусскому закону о защите персональных данных нужно для ваших локальных обязательств. Не заменяет SCC, TIA и Article 28 DPA на EU-стороне. Два режима живут параллельно.

Короткий setup-чеклист

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

Стандартные договорные условия (модульная версия 2021) подготовлены и подписаны с EU-клиентами.
Шаблон DPA вычитан юристом, с обозначением жёстко закрытых для торга пунктов.
Задокументированный Transfer Impact Assessment по Беларуси, доступный по запросу, обновляется ежегодно.
EU-хостинг как дефолт там, где сценарий позволяет.
Контроль доступа и логирование аудита, со сроками хранения, согласованными с контрактом.
Шифрование расписано — алгоритмы, управление ключами, охват.
Псевдонимизация и минимизация данных в dev- и test-окружениях.
DPO назначен там, где требует статья 37, с открытыми контактами.
Процедура уведомления об инциденте задокументирована, протестирована и известна команде.
Список sub-процессоров поддерживается, раскрыт клиентам, с механикой уведомления об изменениях.
Вся клиентская документация — на английском, структурирована под прокьюремент-ревью, а не под внутреннее использование.

FAQ

Нам обязательно открывать EU-юрлицо, чтобы работать с EU-клиентами?

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

Белорусский закон о защите персональных данных эквивалентен GDPR?

Он построен на принципах GDPR в общих чертах, но Еврокомиссия его адекватным не признала. EU-клиенты трактуют Беларусь как третью страну для целей передачи. Локальное соответствие нужно для ваших локальных обязательств — оно не заменяет механику со стороны ЕС. Две рамки работают параллельно.

Как выглядит Transfer Impact Assessment по Беларуси на практике?

Документ — обычно 8–15 страниц у типового вендора — который описывает, какие персональные данные передаются, оценивает риски по белорусскому законодательству и практике (включая вопросы государственного доступа) и документирует дополнительные меры, которые применяются для митигации этих рисков. Шифрование, псевдонимизация, контроли доступа, контрактные ограждения. Честный TIA признаёт риски — он не делает вид, что их нет. EU-комплаенс-команды больше доверяют честным оценкам, чем успокаивающим.

Можно ли просто подписать DPA EU-клиента без правок?

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

Нужен ли нам DPO?

Статья 37 GDPR описывает, когда DPO обязателен. Грубо: государственные органы; компании, чья основная деятельность включает крупномасштабный систематический мониторинг субъектов данных; компании, чья основная деятельность включает крупномасштабную обработку специальных категорий данных. Для большинства белорусских IT-сервисных вендоров формальное назначение по закону не требуется. Но многие EU-клиенты его ждут, и наличие назначенного DPO с подготовкой и опубликованными контактами сигналит серьёзность независимо от строгой правовой позиции.

А EU AI Act — к нам применяется?

AI Act, в силе с 2024 года с поэтапным применением до 2027-го, применяется к провайдерам и пользователям AI-систем, чей результат используется в ЕС, независимо от того, где находится провайдер. Если вы делаете AI-фичи, которые используют EU-клиенты, вы скорее всего попадаете под часть обязательств. Эта работа отдельна от GDPR, но всё чаще всплывает в том же прокьюремент-разговоре. С юристом стоит обсуждать как отдельный поток.

Меняет ли резидентство ПВТ наш GDPR-разговор?

Само по себе резидентство ПВТ позицию по GDPR не меняет — Беларусь всё равно остаётся третьей страной. Но режим ПВТ поддерживает англоязычные контракты, элементы английского коммерческого права в коммерческих отношениях и безбумажный контрактинг — всё это делает EU-контрактный разговор глаже. Большинство белорусских IT-компаний, которые успешно работают с EU-клиентами, — резиденты ПВТ. Это не совпадение.

Мы теряем EU-сделки из-за GDPR или из-за санкций?

Честно — часто из-за и того, и другого, и эти две темы запутываются в одном прокьюремент-разговоре. Формальный GDPR-ревью можно пройти с правильной документацией. Внутренний политический фильтр — у части EU-клиентов есть прописанные политики, исключающие вендоров из Беларуси независимо от GDPR-документации — пройти труднее. Если пайплайн стабильно подвисает на комплаенс-шаге, структурные ответы (EU-дочка, отношения через EU-генподрядчика) иногда полезнее, чем дополнительная документация. Диагностируйте, что именно у вас, до того как тратиться на лечение.

Главное

EU-клиенты задают GDPR-вопросы не чтобы создать вам трудности. Они их задают потому, что они — data controller, ответственность по EU-праву на них, и их комплаенс-команда хочет документацию, которая позволит ей подписать без принятия риска, который потом нельзя защитить. Большинство белорусских IT-вендоров, теряющих EU-сделки на комплаенс-шаге, теряют их потому, что документации нет, операционный стек не структурирован под внешний ревью или корпоративная структура усложняет работу комплаенс-команде EU-клиента сильнее, чем нужно.

Большая часть этого решаема. SCC и шаблон DPA собираются за квартал. Честно написанный TIA — за пару недель. Операционный стек — EU-хостинг, контроли доступа, шифрование, псевдонимизированные dev-данные — стандартная энтерпрайз-работа, хорошо понимаемая инженерными командами в ПВТ. Структурная часть более масштабная и дорогая, но именно там часто и расчищаются самые упрямые блокировки пайплайна.

В Recruitment.by мы работаем с белорусскими IT-компаниями на стороне команд — собираем команды под EU-контракты, поддерживаем работу в режиме ПВТ для вендоров, строящих правильную структуру, помогаем войти в ПВТ тем, кто ещё снаружи, и закрываем HR-консалтинг по организационной части комплаенс-настройки.