Проверка кандидатов в Беларуси: правовые ограничения и практические альтернативы для IT-найма

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

Это и есть то самое различие между тем, что в США или ЕС ощущается как нормальная кадровая проверка, и тем, что белорусский закон в реальности разрешает делать, когда кандидат — белорусский разработчик. Различие шире, чем ожидают иностранные работодатели на старте. И он полностью преодолим — при условии, что вы перепроектируете рамку скрининга, а не пытаетесь подлатать её уже после того, как первый кандидат тихо ушёл.

Дальше: три закона, которые этим управляют; что они вам дают делать, а что нет; вопрос со справкой о несудимости, на котором спотыкается почти каждый иностранный клиент при первом созвоне; трансграничная передача данных, на которой ловятся EOR-конструкции; и альтернативы, которые дают более качественные решения о найме, чем когда-либо давал американский документо ориентированный скрининг. Два возможных кейса в конце статьи. Честная версия того, как это работает в 2026 году.

Три закона, которые надо знать до того, как составлять форму скрининга

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

Трудовой кодекс

Статья 26 ТК перечисляет документы, которые работодатель вправе требовать от кандидата при заключении трудового договора. Список конечный. Паспорт. Трудовая книжка. Документ об образовании. Военный билет, где применимо. Свидетельство социального страхования. Это, по сути, и есть весь набор обязательных документов. Что-либо сверху — включая справку о несудимости для обычной IT-роли — требует отдельного правового основания. Просто дописать пункт в форму, потому что так требует глобальная HR-политика, не получится.

Закон о защите персональных данных

Закон № 99-З от 7 мая 2021 года. По структуре опирается на GDPR. По существу — материально отличается там, где это важнее всего для найма. Главное отличие: «законный интерес» как самостоятельное основание обработки в белорусском законе не работает так, как в GDPR. Тот вариант, на который вы обычно опираетесь в ЕС, чтобы обосновать проверку, здесь просто не существует. Основную работу делает согласие — а это значит, что документ согласия весит больше, чем в практике ЕС, и слабая редакция отваливается раньше и громче.

Закон также дотягивается до белорусских и иностранных работодателей, обрабатывающих данные белорусских резидентов. Экстерриториальное действие, как и у GDPR. Ваша американская материнская, ваша офшорная HR-платформа, ваш польский провайдер расчёта зарплаты — все в рамке, хотели они того или нет.

Указ Президента № 422 от 28 октября 2021 года

Административная надстройка. Надзорный орган — Национальный центр защиты персональных данных. Практические обязанности вашего работодателя (оператора данных) включают ведение учёта обработки, документирование согласия, защиту трансграничных передач и способность подтвердить соответствие по запросу. Сам Указ и сопутствующие акты публикуются на Национальном правовом интернет-портале; Центр размещает свои разъяснения и надзорные материалы на cpd.by. Оба адреса стоит сохранить ещё до первого найма — материалы обновляются, рамка двигается.

Что вы реально можете проверять

Операционная карта. Что допустимо — при правильной рамке согласия — на IT-роль в Беларуси. Прочитайте медленно. Поле уже, чем ожидает американский плейбук, и шире, чем кажется при пессимистичном чтении.

Стандартная проверка по статье 26

• Идентификация по паспорту. Стандарт. Часть документного пакета, который смотрит любой белорусский работодатель.
• Документы об образовании и дипломы. Тоже статья 26. Подтверждается напрямую с вузом — большинство учреждений в Беларуси и за рубежом подтверждают факт обучения по простому запросу.
• Трудовая книжка, подтверждающая предыдущую работу в Беларуси. Белорусский документ. Кандидат показывает, вы смотрите. Дополнительный механизм не нужен.

Допустимо при наличии согласия

• Сбор отзывов от предыдущих работодателей. Письменное согласие кандидата. Готовность предыдущего работодателя ответить. На белорусском IT-рынке часто работает — сообщество небольшое, люди поддерживают связи, рекомендации идут через реальные отношения, а не через переписку HR — HR.
• Подтверждение профессиональных сертификаций. AWS. Microsoft. Google Cloud. ISTQB. CKAD. Кандидат указал — сертифицирующий орган подтвердил. Прямо, быстро, без минного поля приватности.
• Обзор публично доступных соцсетей. LinkedIn, публичный GitHub, публичный X. Даже публичный контент — это персональные данные, обработка которых попадает в рамку: нужно согласие и нужна соразмерность роли.
• Технические оценки. Кодинг-задачи. Сессии по системному дизайну. Тестовые проекты. Главный сигнал для IT-найма — и вне минного поля персональных данных полностью.

Требует отдельного правового основания — и для обычных IT-ролей недоступно

• Справка о несудимости. По закону предусмотрена для должностей в системе госбезопасности, правоохранительных органах, образовании, здравоохранении, финансовом секторе, таможне и ряде других регулируемых сфер. IT-разработчик, дизайнер, продакт-менеджер, QA-инженер, дата-инженер, DevOps — не из этого списка.
• Кредитная история. В общем случае для найма не запрашивается без специального регуляторного основания. Узкое исключение — старшие позиции в регулируемых финансовых организациях.
• Медицинский осмотр. Только если роль попадает под законодательно установленное требование о медицинской пригодности. Для общего IT-работодателя — недоступный инструмент.
• Полиграф или психологическое тестирование. Жёстко ограничено. Требует специального законодательного основания для роли. Количество IT-ролей с таким основанием — близко к нулю.

Вопрос со справкой о несудимости (где спотыкается каждый иностранный клиент)

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

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

Для большинства IT-ролей — нет. Причины ниже.

• В белорусском трудовом праве нет общей модели «мы проверяем всех на несудимость». Проверка законодательно привязана к конкретным категориям должностей. Разработчик ПО — не категория. И продакт-менеджер не категория, и дизайнер, и QA, и большинство стандартных IT-должностей. 
• В любом случае, требование предоставления персональных данных в качестве условия договора создает два уровня риска. Риск, связанный с Законом о защите персональных данных (PDP), в случае сбора персональных данных без законных оснований. Риск, связанный с Трудовым кодексом, в случае требования документов, не включенных в список статей 26, в качестве условия приема на работу. Ни один из этих рисков не является теоретическим. 
• Добровольное предоставление — это другой подход. Кандидат может добровольно получить и предоставить сертификат. Работодатель может добровольно его принять. Разные правила, разные риски. Но подлинное согласие должно быть действительно добровольным — не полученным под угрозой отзыва предложения. 
• К немногочисленным исключениям относятся: должности, связанные с государственной тайной, некоторые должности в сфере финансовых услуг, регулируемые Национальным банком, должности в сфере безопасности критической инфраструктуры, а также ИТ-специалисты, работающие в смежных с здравоохранением областях и обрабатывающие конфиденциальные медицинские данные. Каждая из них требует отдельного анализа. 

Этот вопрос поднимается практически в каждом первом разговоре с новым иностранным IT-клиентом. Интуиция исходит из практики найма в США, Великобритании или Германии, где проверка кандидатов перед приемом на работу является культурным нормой, и никто ее не оспаривает. В Беларуси же эта норма уже. Такая структура работоспособна, но «проверка на наличие судимости у всех» — это не путь к успеху, и попытки сделать это путем к успеху создают проблемы быстрее, чем решают их. 

Соцсети

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

• Публичный контент. LinkedIn, открытый X, открытый GitHub. В принципе можно смотреть — но просмотр обрабатывает персональные данные, а значит, согласие и соразмерность применяются. Пропустить ни одно из этих требований нельзя только потому, что контент был открытым.
• Закрытый контент. Facebook «только для друзей», закрытый Instagram, что угодно за подпиской или за запросом дружбы. Под запретом. Попытка доступа через обман или прикрытие — это явная экспозиция по Закону о персональных данных.
• Кеш, архивы, исторический контент. Те же правила, что и для актуального. Найденность не равна правомерности обработки. То, что Google выдаёт пост с форума 2014 года, не делает этот пост свободным к использованию против кандидата.
• Пропорциональность. Руководители высшего звена, работающие с общественностью, могут оправдать более тщательную проверку. Разработчики бэкенда — нет. Закон о защите персональных данных требует от контролера продемонстрировать правовое обоснование и пропорциональность обработки — и то, и другое, но не что-то одно. 
• Документация. Центр может запросить у оператора подтверждение соответствия. Заявление «Мы проверили их профиль в LinkedIn» должно соответствовать документированной структуре — цель, правовое основание, срок хранения. 

Трансграничная передача данных (ловушка для EOR-конструкций)

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

Данная система требует от юрисдикции назначения обеспечения «адекватного уровня защиты» прав субъектов данных. Белорусские критерии адекватности не идентичны критериям GDPR.  Практические группы:

• Страны-члены ЕС. В целом — адекватные. Членство в Конвенции 108 Совета Европы тут играет.
• Страны ЕАЭС — Россия, Казахстан, Армения, Кыргызстан. Прямо признаются адекватными рамкой.
• Соединенные Штаты. Ситуация более сложная. Зависит от конкретной организации, действующих договорных гарантий и типа потока данных. Не делайте предположений — проверяйте. 
• Другие направления, для которых недостаточны меры защиты — требуются конкретные договорные гарантии или явное информированное согласие субъекта данных на передачу. 

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

Что реально работает для IT-найма

В чем суть статьи? В реальных методах, работающих в рамках закона, и обеспечивающих лучшие результаты при найме, чем тот тип проверки документов, к которому по умолчанию прибегают иностранные IT-работодатели. 

Техническая оценка как главный сигнал

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

Сбор рекомендаций, который реально что-то значит

Прямые звонки предыдущим руководителям с письменным согласием кандидата. Готовность предыдущего работодателя говорить. Подтверждение дат работы, роли, объёма, причины ухода. Конкретные поведенческие вопросы вместо общих «нанял бы снова?» — на которые приходят расплывчатые позитивные ответы независимо от реальной картины. Сверка рассказа кандидата с несколькими независимыми точками. Допустимо. Работает. Не используется, потому что занимает время, а рекрутёр в спешке.

Идентификация и подтверждение квалификаций

Проверка документов по статье 26 закрывает идентификацию и предыдущую работу в Беларуси. По квалификациям — напрямую к сертифицирующему органу: Microsoft, AWS, Google Cloud, ISTQB, вендорские центры сертификации. Подтверждение образования через университет. Сверка LinkedIn по датам, ролям, объёму — только публичный контент. Стандартная история.

Испытательный срок — ваша настоящая страховка. 

Белорусское трудовое законодательство предусматривает испытательный срок до трех месяцев для большинства должностей. Опытные белорусские работодатели в сфере IT рассматривают испытательный срок как реальную проверку биографии — фактическую производительность на реальной работе, которая более предсказуема, чем любой документ. Работодатель может расторгнуть трудовой договор во время испытательного срока, уведомив об этом за три дня и предоставив минимальное количество документов. Если вы целенаправленно включите испытательный срок в свою систему найма, вы получите эквивалент должной осмотрительности без утечки персональных данных. Большинство иностранных клиентов недооценивают этот аспект. Те, кто правильно организует процесс, устанавливают контрольные точки производительности на 30, 60 и 90 дней и рассматривают решение на 90-й день как окончательное решение о найме. 

Работа с опытным локальным кадровым партнёром

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

Особенности для резидентов ПВТ

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

Резидентство в ПВТ упрощает многие HR-процессы и приносит реальные налоговые преимущества. Но рамку Закона о персональных данных оно не меняет. Резиденты ПВТ, обрабатывающие персональные данные, работают по тем же ограничениям, что и все остальные — те же требования к согласию, те же ограничения статьи 26 ТК, та же архитектура трансграничной передачи. Гибкость ПВТ по трудовым условиям (наём иностранных работников, типы договоров, удалённая работа) не распространяется на смягчение правил обработки персональных данных. Некоторые новые резиденты ПВТ считают, что льготы покрывают и это. Не покрывают — и узнавать об этом на собственном опыте удовольствия не доставляет.

Наша поддержка по входу в ПВТ закрывает заявку и процесс входа. HR-процессы внутри рамки ПВТ всё равно следуют стандартной архитектуре Закона о персональных данных.

Согласительный документ — место, где сосредоточена большая часть юридической работы. 

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

Работающее согласие на обработку персональных данных при IT-найме должно:

• Идентифицировать оператора данных — работодателя или кадровое агентство, если у агентства статус оператора.
• Перечислить категории обрабатываемых персональных данных. Идентификационные. Контактные. Профессиональные. Образовательные. Рекомендательные. Конкретные категории, а не общая корзина «всё что угодно».
• Укажите цели обработки данных. Оценка кандидатов. Трудовые отношения. Расчет заработной платы. Соблюдение нормативных требований. Каждая указанная цель должна быть обоснована сама по себе. 
• Указать правовое основание — согласие по Закону о персональных данных плюс законодательное основание для данных по статье 26 ТК, где это применимо.
• Перечислите третьих лиц, которые получат данные. Поставщик услуг EOR. Поставщик услуг по расчету заработной платы. Материнская компания. Кадровое агентство. Поставщик услуг по проверке биографических данных (если используется). Все указанные лица. 
• Указать направления трансграничной передачи и правовое основание каждой. Адекватность, договорные гарантии или явное согласие — на каждое направление.
• Четко определите срок хранения данных. Для кандидатов, не прошедших отбор, — только на тот период, который необходим для процесса найма и в целях защиты интересов — обычно это от шести до двенадцати месяцев. Для успешно принятых на работу сотрудников данные переносятся в рамки трудовых отношений. 
• Проинформируйте кандидата о его правах в соответствии с Законом о защите персональных данных. Доступ. Исправление. Удаление. Отзыв согласия. Каждое из этих действий должно быть подробно описано. 
• Предоставьте кандидату возможность отдельно давать согласие на конкретные виды обработки данных, если это необходимо. Например, проверка публикаций в социальных сетях может быть предоставлена ​​в качестве отдельного варианта согласия. 

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

Два возможных кейса 

Сценарий А. Американская финтех-компания, которая усвоила урок на собственном горьком опыте. 

Американская финтех-компания, раунд финансирования серии B, запускает глобальную программу найма. Стандартная внутренняя политика: проверка на наличие судимости обязательна для каждой должности, в каждой стране, без исключений. Американский рекрутер отправил форму согласия первому кандидату на должность старшего разработчика из Беларуси — кандидат с хорошими техническими навыками, прошедший шестинедельный опыт работы. Кандидат прочитал форму. Вежливо отказался. Отказался от участия в процессе. Рекрутер обратил на это внимание. В течение следующих десяти дней еще пять кандидатов из короткого списка выразили аналогичную обеспокоенность. Нас привлекли для переработки системы отбора для Беларуси. Мы сохранили глубину технической оценки — ту часть, которая действительно дает результат. Сохранили систему критериев. Отменили обязательную проверку на наличие судимости. Переработали документ о согласии в соответствии со стандартами Закона о защите персональных данных. Вакансия была заполнена через шесть недель. Теперь эта система применяется ко всем остальным вакансиям компании в Центральной и Восточной Европе. 

Сценарий B. Берлинский стартап с правильной настройкой EOR (Enterprise Operations Review) 

Берлинский стартап нанимает двенадцать белорусских разработчиков через белорусскую систему EOR. Немецкий подход к найму основывался на рекомендациях предыдущих работодателей как на основном сигнале. Мы помогли структурировать систему согласия в соответствии со стандартами Закона о защите персональных данных. Настроили архитектуру трансграничной передачи данных, чтобы немецкая головная компания могла получать доступ к данным отдела кадров через соответствующие каналы. Встроили трехмесячный испытательный срок в процесс найма в качестве практического фильтра производительности — контрольные точки на 30, 60 и 90 дней, а собеседование на 90-й день стало реальным решением о приеме на работу или отказе. 

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

Разные профили. Один и тот же основной урок. Белорусская система работает, если она правильно разработана с самого начала. Ошибка, которую допускают иностранные IT-работодатели, заключается не в несоблюдении белорусского законодательства, а в предположении, что их собственная стратегия работы будет применима без изменений. Это не так. Но перепроектирование не так уж и сложно, если им всё объяснить. 

Структура принятия решений — на что именно следует обращать внимание при отборе кандидатов 

Практический чек-лист. Распечатайте, отдайте рекрутёру.

Всегда (правовая чистота для любой IT-роли)

• Проверка документов по статье 26 ТК — паспорт, образование, трудовая книжка.
• Прямое подтверждение образования с вузом.
• Прямое подтверждение профессиональных сертификаций с сертифицирующим органом.
• Техническая оценка, соразмерная роли.
• Сбор рекомендаций с письменным согласием кандидата.
• Задокументированное согласие на обработку персональных данных по стандарту Закона о персональных данных.

Для руководящих или ответственных должностей (при наличии надлежащей системы согласования) 

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

Только для специально регулируемых ролей

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

Никогда (без специального законодательного основания)

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

Частые вопросы

Можно ли требовать белорусскую справку о несудимости на senior-разработчика?

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

Наша американская материнская проверяет всех. Почему мы не можем делать так же в Беларуси?

Различная правовая база. В США проверка биографических данных основана на Законе о справедливом кредитном отчёте и практически повсеместной культуре должной осмотрительности при приёме на работу. Белорусское трудовое законодательство ограничивает перечень требований работодателя определённым списком. Закон о защите персональных данных ещё больше ограничивает обработку данных. Американская, британская и немецкая практика не может быть адаптирована без переработки. Эта система работоспособна — просто не путём полного переноса американской версии. 

А если кандидат сам приносит справку?

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

Закон о персональных данных применяется, если мы используем американское рекрутинговое агентство?

Да. Если агентство обрабатывает персональные данные белорусских резидентов, закон до него дотягивается. Экстерриториальное действие, как у GDPR. Агентство должно быть настроено под соответствие, с правильно заключёнными договорами обработки между агентством, EOR (если есть) и материнской компанией. Все три стороны треугольника должны быть выровнены. Пропустить одну — сломать конструкцию.

Сколько можно хранить данные неуспешных кандидатов?

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

Что будет, если всё-таки нарушить?

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

Решающая структура, которая действительно работает 

Белорусское законодательство о проверке биографических данных более ограничительно, чем ожидают иностранные IT-работодатели. Такова честная трактовка. Решение заключается не в обходных путях или хитроумном документе, а в разработке системы проверки, основанной на том, что действительно работает в этой юрисдикции. Тщательная техническая оценка. Прямая проверка квалификации. Проверка рекомендаций, основанная на реальных беседах. Соглашение, соответствующее стандартам Закона о защите персональных данных. Испытательный срок, специально структурированный как реальная проверка производительности. 

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

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

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-консалтинг по организационной части комплаенс-настройки. 

Бонусы и структура компенсации в IT-компаниях Беларуси: что реально мотивирует разработчиков

Вот что мы клиентам говорим годами.

Две компании. Одинаковая работа. Обе платят senior backend разработчику примерно одно и то же — расхождение пять, может десять процентов на gross. Одна удерживает этого разработчика четыре года. Вторая теряет его через четырнадцать месяцев. Та же роль, те же деньги, совершенно разный исход.

Зарплата была не тем фактором. По отдельности она почти никогда не тот фактор.

После десяти с лишним лет закрывания разработчиков в белорусских IT-компаниях — и довольно часто наблюдая, как те же разработчики возвращаются к нам через полтора года — мы можем сказать, в чём дело обычно. Дело в том, как собрана структура бонусов и компенсации. Насколько предсказуемо ощущается разговор в конце года. Привязан ли performance-бонус к вещам, на которые инженер реально может повлиять. Реальная долгосрочная часть — или просто строка в оффер-леттере. Выдерживает ли вся конструкция, когда разработчик объясняет её жене за кухонным столом.

Базовые зарплаты в IT-Беларуси к 2026 году в целом сошлись по уровням. Большинство компаний в своём сегменте платят похожие цифры. Реальная работа сместилась выше базы — в слои поверх неё. Именно там сейчас решается, кто остаётся, а кто уходит. Эта статья — про то, как этот пирог реально собирается. И где он обычно разваливается.

Почему одной зарплаты больше не хватает

В 2023 и 2024 годах зарплатная картина в IT-Беларуси была нестабильной. Цифры двигались быстро в обе стороны. К 2026 году всё устаканилось. Большинство компаний, которые конкурируют за senior-кадры, плотно стоят вокруг одних и тех же базовых вилок, а сами вилки не сильно гуляют от квартала к кварталу.

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

Конкретно: в структуре годового бонуса. В том, существует ли долгосрочная мотивация и звучит ли она правдоподобно. В том, что прошёл был ли пересмотр зарплаты тогда, когда был обещан. И в том, насколько внятно вся конструкция компенсации была объяснена в момент найма, а потом ещё раз — через год.

Когда мы видим, что senior-разработчик уходит из компании в 2026 году, дело почти никогда не в базе. Почти всегда — в том, что структура выше базы ощущается непрозрачной, произвольной или просто заброшенной. И неудобный момент в том, что починить это в основном бесплатно по деньгам. Это стоит внимания.

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

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

• Уровень 1 — базовая зарплата. Фиксированная, предсказуемая. Платит счета. Не мотивирует, но её отсутствие демотивирует мгновенно.
• Уровень 2 — годовой денежный бонус. 13-я зарплата, performance-бонус или их комбинация. Та часть разговора в декабре, которую все запоминают.
• Уровень 3 — долгосрочная мотивация. Equity, phantom stock, retention-бонусы. Причина, по которой senior-разработчики остаются дольше трёх лет, а не проверяют рынок каждую весну.
• Уровень 4 — неденежные мотиваторы со структурным весом. Карьерный трек, бюджет на обучение, признание, качество команды. То, чего нет в расчётке, но что объясняет большую часть истории ретеншна.

Практически каждая компания, с которой мы работаем, практически всегда предоставляет  Уровень 1. Дальше переходит на Уровень 2 и дает что-то типовое — обычно 13-ю зарплату, скопированную с того, как делают остальные. Про Уровень 3 забывают, пока не приходит этап, на котором инвесторы про это спрашивают. А Уровень 4 тихо становится тем, до чего у HR-а дойдут руки в этом квартале.

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

Уровень 1: как реально выглядит базовая зарплата в 2026 году

Честные рыночные вилки заработных плат на середину 2026 года, gross в месяц в долларовом эквиваленте, без бенефитов и накопления бонуса. Цифры двигаются квартал к кварталу, но форма устойчивая.

• Senior backend (5+ лет): $3 500 – $5 500
• Middle frontend: $2 200 – $3 500
• Senior DevOps / SRE: $3 800 – $5 800
• Senior QA / SDET: $2 800 – $4 200
• Tech Lead: $5 500 – $8 000 и выше
• Staff Engineer или Principal: $7 000 – $10 000+

Это внутренние цифры, на основе вакансий, которые мы реально закрыли за Q1 2026. Если нужен корректный разрез по стекам, грейдам и типам компаний — это покрывает наше исследование зарплат в IT.

Два структурных момента по базе, которые значат больше, чем сама цифра.

Частота пересмотров. Дефолт в IT-Беларуси раньше был раз в год. У более серьёзных работодателей в 2026-м это раз в полгода, с квартальными разговорами для высоких перформеров. Но важна тут не столько частота, сколько последовательность. Запланированный пересмотр, который стабильно съезжает — «сделаем в четвёртом квартале», который становится вторым кварталом следующего года, который становится «давайте после закрытия раунда», — это один из самых надёжных способов столкнуть senior-разработчика в режим поиска. К моменту, когда пересмотр наконец случается, у них обычно уже было два разговора с нашими консультантами.

И отдельно — про ПВТ. Компании, работающие в режиме Парка высоких технологий, считают взносы в ФСЗН со средней по стране, а не с фактической зарплаты разработчика. На senior-уровне это экономит работодателю где-то $300–$500 в месяц по сравнению с не-ПВТ-компанией при той же gross. Компании, которые удерживают лучше всех, эти деньги перекладывают в верхние слои структуры компенсации. Те, что удерживают хуже, дают им тихо растворяться в общей марже. Механика подробно — на странице Министерства экономики по ПВТ.

Уровень 2: годовой бонус — три схемы и три разных подхода

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

Чистая 13-я зарплата

Один месячный оклад, выплата в декабре, без вариации по перформансу. Получают все, кто числится 31 декабря.

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

Обратная сторона — это не дифференцирует. Разработчик, который вытащил миграцию платформы, получает тот же декабрьский чек, что разработчик, который тихо коастил девять месяцев. Со временем 13-я зарплата перестаёт ощущаться как бонус и начинает ощущаться как отложенный кусок базы. Это не обязательно плохо — но нужно понимать, что вы это и спроектировали, потому что бонус теперь работает как гарантия, а не как награда.

Где работает хорошо: компании до сотни человек, где все друг друга знают; компании, где индивидуальный вклад честно трудно вычленить; компании, которые осознанно ценят cohesion выше дифференциации. Особенно хорошо это смотрится в сервисных компаниях со зрелыми, устойчивыми командами.

Чистый performance-бонус

Переменный, считается от индивидуальных или командных KPI. В плохой год может быть ноль, в хороший — 200% от цели. Считается по прописанной формуле или score card, в идеале — в оффер-леттере.

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

Когда не работает — наносит реальный вред. В тот момент, когда разработчики приходят к выводу, что KPI награждают вещи, на которые они повлиять не могут, — выручка отдела продаж, к которому они не прикасались; метрики, зависящие от стратегического слоя и не зависящие от инженерного — бонус превращается из мотивации в раздражитель. Хуже того: когда KPI начинают подкручивать те, кто ближе к руководству, остальная команда это замечает быстро, и доверие проседает так, что восстановить тяжело. Мы своими глазами видели, как performance-бонусные системы убивают мораль в командах ровно в тех компаниях, которые думали, что инвестируют в performance-культуру.

Где работает хорошо: компании от 150 человек, где индивидуальный вклад измерим; sales-смежные инженерные функции; инженерные организации с реально зрелой OKR- или scorecard-практикой. Если у вас этой зрелости пока нет, схема скорее навредит, чем поможет.

Гибрид — половина гарантирована, половина за перформанс

Схема, которую мы чаще всего видим в зрелых ПВТ-компаниях в 2026 году. Годовой бонусный пул делится — обычно пополам, иногда 60/40 — между гарантированной 13-й зарплатой и оплатой за показатели.

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

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

Где работает хорошо: большинство растущих белорусских IT-компаний, особенно продуктовые компании и резиденты ПВТ с международными клиентами.

Уровень 3: долгосрочная часть, которая удерживает сотрудника после трёх лет

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

Equity-гранты

RSU и опционы в Беларуси администрируются — особенно у резидентов ПВТ, чей режим прямо предусматривает такие инструменты. Механика не такая чистая, как в Берлине или Лондоне, но при правильной настройке рабочая.

Что важно — это сделать структурную работу до того, как грант ушёл в оффер. Расписать вестинг. Прояснить, как считается dilution. Понять налоговый режим для конкретного инструмента. Версия «детали разберём потом» — это та версия, которая ломается. Обычно на шестом месяце, когда разработчик просит документацию, которой не существует, и доверие ко всему оффер-леттеру проседает.

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

Phantom stock

Отслеживает стоимость доли, но без реальных прав акционера. Выплачивается деньгами в обозначенные моменты — продажа, IPO, плановые vesting-этапы.

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

Retention-бонусы

В белорусской HR-практике их иногда называют loyalty bonus. Фиксированная сумма, которая открывается на разных этапах — обычно на 12, 24 и 36 месяцах. Всё чаще используются на senior+ как прямой ответ на внешнее рекрутинговое давление.

Хорошо работают тогда, когда они публичные и структурные, а не тихо торгуются с отдельными разработчиками. Retention-бонус, про который в команде становится известно как про что-то, что досталось паре любимчиков, наносит больше вреда, чем сам бонус приносит пользы. Если используете retention-бонусы — кладите их в опубликованную компенсационную рамку, чтобы их было видно.

Уровень 4: неденежное, на котором решается большая часть ретеншна

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

Видимый карьерный трек

Описанная дорога от senior к staff и к principal — с критериями, со сроками, которые совпадают с тем, что реально происходит. Большинство белорусских IT-компаний говорит, что у них это есть. У большинства этого нет в форме, по которой разработчик может ориентироваться. Те, у кого есть — опубликованные грейды, реальные критерии, повышения, которые случаются по графику, — удерживают лучше тех, у кого нет. С большим отрывом.

Бюджет на обучение, который реально можно потратить

Дело не только в сумме. Дело в других условиях. Согласованный бюджет в $1 500 всегда лучше бюджета в $2 500, где за каждый билет на конференцию приходится воевать с финотделом. Разработчик через полгода помнит все это.

Признание не разовое, а структурное

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

Конкретные условия работы, а не размытые

Чёткая удалёнка или чёткий гибрид. Качественная техника на senior-уровне. Реальная автономия по времени. Компании, которые на этом играют — «мы в основном удалённо», без конкретики, что это значит на практике, — тихо теряют кандидатов в пользу тех, кто конкретен.

Команда, в которую вас зовут

Самая часто называемая причина, по которой senior-разработчик принимает оффер — это с кем он будет работать. Сильные инженеры хотят сильных инженерных коллег. Компании с репутацией инженерного качества рекрутируют на этой репутации; компании без неё платят скрытую премию, которой не видят в цифрах. Поэтому осознанное team-building важно не меньше, чем чистый рост штата.

Ошибки, которые тихо влияют на текучку кадров

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

Непрозрачный расчёт бонуса

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

Ретроактивные изменения правил

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

KPI, на которые разработчик повлиять не может

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

Equity без документации

«У тебя есть опционы» в оффере без vesting schedule, без strike price, без описания dilution. Через полгода разработчик просит документацию и выясняет, что её нет. Этот разговор делает долгосрочный урон доверию ко всему остальному, что говорит компания, — включая следующий разговор про бонус.

Циклы пересмотра зарплаты, которые съезжают

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

Бонусы, которые задерживают или урезают

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

FAQ

Стоит ли платить 13-ю зарплату, если у нас маленькая компания?

Если у вас меньше 30 человек и кеш узкий, гибрид с меньшей гарантированной частью и performance-надбавкой обычно работает лучше, чем полная 13-я. Возможно, стоит платить. Полное отсутствие любой годовой денежной компоненты читается белорусскими разработчиками как «компания неопытная» или «у компании проблемы», и ни то, ни другое не помогает в найме.

Как сделать performance-бонусы такими, чтобы они не ощущались произвольными?

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

Можно ли вообще администрировать опционы или phantom stock для белорусских разработчиков?

Да, при правильной структуре. Режим ПВТ прямо предусматривает equity-инструменты, что упрощает жизнь резидентам. Механику нужно настроить до того, как грант ушёл, а не патчить потом. Для разработчиков вне ПВТ phantom stock или кеш-ориентированные долгосрочные программы обычно проще административно. Получите консультацию по конкретной структуре до того, как что-то обещаете в письменной форме — «equity заглушкой» — одна из самых частых ошибок в оффер-леттерах, которые мы видим.

Как часто нужно делать пересмотр зарплаты?

Годовой — это базовая планка. Более серьёзные работодатели в 2026 году делают полугодовые пересмотры для всех и квартальные разговоры для высоких перформеров. Но важна не столько частота, сколько последовательность. Съехавший пересмотр бьёт по доверию сильнее, чем меньшая прибавка. 

Какой адекватный уровень заработной платы у senior-разработчика в 2026 году?

База в коридоре $3 500–$5 500 в месяц, плюс годовой бонус примерно один–полтора месячных оклада в эквиваленте, плюс L&D и бенефиты $200–$400 в месячном эквиваленте, плюс долгосрочная компонента в верхней части senior. Обшая сумма где-то $4 500–$7 500 в месячном эквиваленте у крепкого senior-разработчика, с заметным разбросом по стеку, типу компании и уровню. Конкретные цифры зависят от сотрудника.

Главное

Паритет в выплатах зарплат достаточно хороший. Компании, которые подбирают адекватно разные способы выплаты зарплат и бонусов, удерживают разработчиков и после трёх лет. Компании, которые этого не делают, в итоге платят рыночные зарплаты выше уровня по рынку и теряют быстро сотрудников.

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

Как построить бренд работодателя в LinkedIn, на который реально отвечают сеньорные IT-специалисты из Беларуси

A foreign CTO got on a call with us last month and asked why his InMails to senior Belarusian engineers were getting a 4% response rate when LinkedIn’s global benchmark for tech roles sits closer to 18–25%. The honest answer: because his message read like every other InMail those engineers had received that week. The seniors he was reaching out to — the ones with 7–12 years on the bench, fluent English, and EPAM or Wargaming or Apalon on their CV — get five to fifteen cold messages a month. Most of them are template trash. The good engineers stopped responding to anything that doesn’t show specific knowledge of who they are.

Generic LinkedIn employer-branding advice doesn’t fix this. «Post employee stories» and «showcase your culture» are fine for entry-level pipelines and not even close to enough for the Belarusian senior market. So below is the playbook we actually run for foreign clients hiring senior Belarusian engineers — eight tactics, in order of how much they move the needle, plus a 30-day starter plan if you’d rather act than read.

Why generic LinkedIn advice doesn’t translate to senior Belarusian engineers

Three reasons before the playbook starts.

The market is small and the seniors know each other

Roughly 100,000 IT professionals in Belarus, of whom perhaps 8,000–12,000 are genuine seniors with 7+ years of experience. They’re in the same Telegram groups. They’ve worked at the same companies. They share notes about employers — including which one is spamming generic InMails this month. Whatever you send today, somebody else is reading by Thursday. Pick a tone you’d want spread.

English is good, but not native

Senior Belarusian engineers operate at B2–C1 — most of the leading software companies mandate English for client communications and many provide internal training. That’s strong, but it’s not the same as native fluency. Generic American marketing copy lands strangely. «We’re a fast-paced team building the future of [generic vertical]» reads as exactly the kind of vapor that pushes them away.

Trust currency is different

What senior Belarusian engineers value, in this order: technical credibility, salary transparency, and predictability. They’re skeptical of performative culture content — ping-pong tables and «we’re like a family» close doors here, not open them. A LinkedIn brand built on the three things above outperforms one built on aesthetics. This is also where the geopolitical context lives, which we’ll come back to in tactic #5.

The 8-tactic playbook

Tactic #1 — Build a Company Page that signals technical seriousness, not corporate polish

Senior engineers don’t read your Company Page like a brochure. They scan it for signals. Who’s the CTO? What stack are you running? When did anyone post anything last? Do your job posts list real salary ranges or hide behind «competitive compensation»? LinkedIn’s own data shows pages with complete, regularly-updated profiles get 2x more applicants per posting — but for senior talent, that 2x is mostly noise unless the page also carries technical credibility.

What to actually do. Pin a post about something you’ve engineered that’s interesting. Link to your engineering blog (or build one). Make sure your CTO’s profile is connected and active. Use real photos of the team rather than stock imagery. Show recent product or technical wins.

What to avoid. Vague mission statements, listicle-style «five reasons we’re a great place to work» posts, anything that reads like it was written by a marketing team that has never spoken to your engineers. Senior readers can spot the difference in three lines and they’ll click away. Our work on targeted IT recruitment depends on this kind of credibility being already in place.

Tactic #2 — Have your engineers post, not your recruiter

Content from individual employees outperforms branded content by roughly 8x in engagement, and most professionals trust content from individuals more than from brands. For senior Belarusian engineers — many of whom are on LinkedIn primarily to follow other engineers, not companies — that gap is even wider.

What to do. Identify three or four of your existing engineers who already post (or would, with light encouragement). Help them write about real technical decisions: «why we picked Postgres over MongoDB for this thing,» «how we cut our API latency in half,» «what went wrong when we migrated to Kubernetes.» Don’t script them. Don’t make them post on a schedule. Let it be real.

What to avoid. Forcing employee advocacy through a content tool, ghostwriting engineer posts in marketing voice, asking engineers to repost corporate announcements verbatim. Ghostwritten content is detected within two lines, and once it’s been spotted, the engineer who posted it loses credibility with their network. That’s a worse outcome than no post at all.

Tactic #3 — Show salary ranges in EUR or USD, with a specific number

This is the single highest-leverage thing most foreign companies still don’t do. Senior Belarusian engineers receive InMails daily. The ones that name a salary range get answered first. The ones that say «competitive compensation» don’t get answered at all.

What to do. In your job posts and your InMail templates, include a number. «EUR 5,500–7,500 gross/month for senior backend, depending on experience» beats anything else you can write. If you’re hiring through HTP-resident outstaffing, be transparent about the model: «EUR 5,500–7,500 gross/month, paid through HTP-resident outstaffing structure, no relocation needed.» That sentence converts because it answers the three questions every senior is asking before they decide whether to reply.

What to avoid. «Competitive,» «market rate,» «DOE,» «based on experience» — every one of these reads as «we don’t want to commit, so neither will I.» Salary anchoring isn’t tacky in this market; it’s table stakes. The contract structure also matters — see our overview of IT outstaffing arrangements for the variations clients ask about most.

Tactic #4 — Optimize for InMail response rate, not volume

Most foreign companies treating LinkedIn as a sourcing channel make the same fundamental error. They send hundreds of generic InMails and watch their response rate collapse. Senior Belarusian engineers are over-sourced. The math has flipped — sending five carefully personalized InMails outperforms sending a hundred templated ones, by a wide margin.

What to do. Read the engineer’s profile. Find one specific thing — a project they shipped, a stack choice, a talk they gave, a GitHub repo, the company they’re at — and reference it in the first line. Mention the salary range in the second line. State your role-specific task in the third. Done. Most senior engineers won’t read past three sentences and will reply faster to short, specific messages than to long, polished ones.

What to avoid. Subject lines like «Exciting opportunity at [Company]»; opening lines that praise generic skills they didn’t put on their profile; multi-paragraph InMails that try to sell the company before establishing relevance. Companies with strong talent brands on LinkedIn see 31% higher InMail acceptance rates on average — but that’s an average across all roles. For Belarusian seniors, the gap between strong-brand and weak-brand InMails is wider than that.

Tactic #5 — Acknowledge the geopolitical and sanctions context, briefly

This is the tactic most global recruitment guides skip and most Belarus-aware foreign companies handle badly. Since 2022, senior Belarusian engineers have heard a lot of vague language from Western recruiters about «the situation.» The good ones have learned to read avoidance as either ignorance or bad faith — and either is disqualifying.

What to do. In your employer-brand content, be specific about how you handle the practical questions. Payment in EUR or USD. Working through HTP-resident structures or Belarusian EOR providers. Tax and contract structure. Sanctions exposure on either side. Don’t moralize. Senior Belarusian engineers don’t need your political opinion; they need to know whether the contract works in 2026 and whether they’ll get paid on time. The recruiting.by piece on hiring blockchain developers in Belarus is a useful template for how to address structural questions without melodrama.

What to avoid. Statements like «we believe in our Belarusian colleagues during this difficult time.» That language reads as condescending and makes senior readers click away. The cleanest tone is matter-of-fact: here’s the structure, here’s the payment, here’s what we expect.

Tactic #6 — Use video, but only with engineers as the talent

Video content is an increasingly strong differentiator on LinkedIn — but the wrong kind of video destroys trust faster than no video at all. A polished marketing-team-produced «life at our company» video performs worse than no video, because it triggers the bullshit filter every senior engineer has running by default.

What to do. Five-to-ten-minute LinkedIn Lives where your CTO walks through a technical decision the team made. Short videos where an engineer talks through an actual project — unscripted, with the rough edges left in. Conference talks recorded by your team. Internal lightning talks made public. Production quality matters less than authenticity; phone-camera footage of a real engineer beats a polished promo every time.

What to avoid. Any video that feels like a recruitment commercial. Anything with a corporate music bed under it. Anything where someone is reading from a teleprompter. The whole appeal of video for this audience is that it’s harder to fake than text — leaning into production removes the only advantage video has over a written post.

Tactic #7 — Build a Careers page that pre-answers the questions seniors actually ask

Your LinkedIn Careers Page and your careers site should pre-answer the five questions every senior Belarusian engineer asks before responding to outreach: (1) what’s the salary range, (2) what’s the contract structure — entity, EOR, HTP outstaffing, (3) is the role remote, hybrid, or on-site, (4) what’s the actual tech stack, and (5) who else is on the engineering team. If those five answers aren’t on the page they reach, the senior doesn’t reply.

What to do. Build a one-page careers site that answers all five clearly and link it in every InMail. Update the engineering team listing every quarter. If you don’t have a careers site, make sure your LinkedIn Careers Page covers the same five with the same specificity.

What to avoid. Marketing-led careers content that’s heavy on culture and light on substance. Senior engineers don’t apply to vibe; they apply to specifics. A careers page full of «join our journey» content with no salary band, no stack, and no team listing is worse than no careers page — it actively signals that you’re hiding something.

Tactic #8 — Partner with someone in Belarus who already has the network

The honest one. The senior Belarusian engineering market is heavily relationship-driven. Recruiting.by’s overview of Belarusian IT job-search platforms confirms what every recruiter in the country already knows: «senior specialists and team leads often find opportunities through networking, LinkedIn, and professional communities rather than through mass job applications.» A foreign company building a LinkedIn employer brand from scratch is starting cold. A Belarus-based recruiter is starting from a network of relationships built over years.

What to do. Use a local recruiter — us, or someone like us — to amplify your LinkedIn brand into the Belarusian senior engineering network. A good local partner does three things you can’t easily do yourself: warm intros to passive candidates, pre-vetting on technical and cultural fit, and translation of your value proposition into something that lands locally. We do this through our IT recruitment service; there are other firms doing it well too.

What to avoid. Assuming a globally-branded recruitment agency knows the Belarus market because they have a Belarus page on their website. They almost certainly don’t. Local market knowledge is built over years and shows up in details — which company is actually a good place to work, who’s been laying off quietly, which compensation expectations are realistic right now.

A 30-day starter plan

If you’re going to act on any of this, the order matters. Below is the rollout we suggest for clients who want to do this themselves.

Most clients who run this 30-day program see InMail response rates move from low single digits to the 12–18% range by the end of week four. Past that, returns flatten — the next gain comes from getting to the engineers who don’t accept InMails at all, which is where the local-network advantage in tactic #8 kicks in.

If your InMail response rate isn’t where it should be

Everything above is what we run for clients hiring senior Belarusian engineers through LinkedIn. The 30-day plan works if you have time and bandwidth to execute it; if you don’t, that’s most of what we do. Tell us the role — stack, seniority, salary band, contract structure — and we’ll tell you what’s realistic and how fast. Get in touch, or browse the rest of our news section while you’re deciding.

IT-аутсорсинг vs IT-аутстаффинг в Беларуси: как иностранной компании выбрать модель и не промахнуться

Примерно половина иностранных компаний, которые пишут нам с запросом «аутсорсинг в Беларуси», на самом деле нуждаются в аутстаффинге. И небольшая, но дорогостоящая в обслуживании группа просит «аутстаффинг», когда хочет получить проектную разработку под фикс. Снаружи модели выглядят почти одинаково — белорусские разработчики пишут вам код, зарплата идёт в BYN, счёт прилетает в EUR или USD. Внутри это разные продукты. Они расходятся в том, кто управляет работой, у кого ответственность за ИС, кто гасит текучку и что произойдёт в то утро, когда разработчик решит, что ему всё это надоело.

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

Две модели — по абзацу на каждую

IT-аутсорсинг

Вы передаёте белорусскому подрядчику кусок работы — проект, фичу, конкретный результат. Подрядчик собирает свою команду, управляет ею и приносит вам готовое. Разработчиков вы не выбираете (или выбираете один раз на старте и потом теряете контроль). Платите за результат, обычно по фиксу или time-and-materials, между вами и командой сидит проект-менеджер. Команда и процесс принадлежат подрядчику. Ваши отношения — с компанией, а не с конкретными людьми, которые пишут код.

IT-аутстаффинг

Вы выбираете конкретных разработчиков — собеседуете, утверждаете — и они работают исключительно на вас, встроены в вашу команду, получают задачи напрямую от вас. Юридически они трудоустроены в белорусском агентстве (в нашем случае — в нашей собственной компании-резиденте ПВТ), поэтому ни расчётом зарплаты, ни налогами, ни договорами, ни инспекцией труда вы не занимаетесь. Работу ведёте вы; трудоустройство — мы. Самая близкая ментальная модель: «они в вашей команде, но в чужом штате».

Откуда берётся путаница — не загадка. И то и другое выглядит как «IT-услуги из Беларуси», в обоих случаях вы не нанимаете разработчиков напрямую, а маркетинг глобальных вендоров целенаправленно стирает грань — потому что аутсорсинг продаётся с большей маржой. Хорошая разборка той же темы есть в этом гайде Recruiting.by, если хочется второй взгляд.

Бок о бок: где модели расходятся

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

Когда аутсорсинг действительно лучший выбор

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

1. Реально фиксированный скоуп

Перевести базу. Сделать промо-сайт по дизайну. Выпустить v1 мобильного приложения по ТЗ и отдать исходники. Если у работы есть финишная черта и она не предполагает постоянного развития — оплатить готовый результат лучше, чем строить команду, которую через три месяца придётся распускать. В Беларуси сильная скамейка подрядчиков под такую работу.

2. Узкоспециальная задача вне вашей экспертизы

Нужны три недели аудита безопасности. Нужна команда Solidity, чтобы выпустить один смарт-контрактный продукт. Брать в аутстаффинг сеньора на трёхнедельную задачу — неправильная форма. Купить результат — правильная. Платите за результаты, а не за найм.

3. У вас нет управленческого ресурса

Если у вас в принципе некому управлять разработчиками — нет тимлида, нет менеджера, нет product owner’а, который проводит стэндапы — аутстаффинг не сработает. Модель предполагает, что управление вы приносите с собой. Аутсорсинг этот слой берёт на себя. Лучше скажем заранее, чем будем смотреть, как через два месяца модель развалится.

Когда аутстаффинг — правильный ответ (а это чаще, чем кажется)

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

1. Продуктовая разработка вдолгую

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

2. Вы хотите контролировать найм и культуру

Вы лично собеседуете каждого разработчика. Решаете, кто будет в команде. Не делегируете это решение чужому проекту. Это самая частая причина, по которой зрелые инженерные команды выбирают аутстаффинг — контроль. Найм — стратегическое решение, и большинству CTO некомфортно его отдавать.

3. Скоуп будет меняться

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

4. Льготы ПВТ должны быть видны в вашем счёте

Это белорусская специфика, и в большинстве глобальных сравнений её пропускают. Когда агентство-аутстаффер — резидент ПВТ, база для социальных взносов считается от средней зарплаты по стране, а не от фактического оклада разработчика. Для сеньора с зарплатой 4 000 долларов это ощутимый кусок стоимости, и он попадает в ваш месячный счёт. У нас это идёт через нашу собственную компанию-резидента ПВТ по плоскому сервисному сбору €350/мес. на разработчика поверх ФОТ. Аутсорсинг ту же экономику прячет в маржу подрядчика; аутстаффинг её показывает. Для контекста: аутстаффинг входит в утверждённый перечень видов деятельности ПВТ — собственно, это и делает структуру рабочей.

Каркас принятия решения: шесть вопросов

Идите по списку сверху вниз. Каждый вопрос сужает ответ. К последнему станет ясно, какая модель ваша.

1. Скоуп работы конечный и зафиксированный — или непрерывный? Конечный → аутсорсинг в игре. Непрерывный → аутстаффинг.
2. Хотите ли вы собеседовать конкретных разработчиков и отбирать их сами? Да → аутстаффинг. Нет, без разницы → аутсорсинг подходит.
3. Есть у вас тимлид или менеджер, который тащит команду день за днём? Есть → аутстаффинг работает. Нет → или аутсорсинг, или нанимать тимлида до того, как двигаться дальше.
4. Насколько чувствительная у вас ИС? Высокая → аутстаффинг через ПВТ-резидента даёт чистую цепочку прав и стабильную команду. Аутсорсинг тоже работает, но только при идеально написанном договоре.
5. Сколько раз сменится скоуп в ближайшие полгода? Часто → аутстаффинг впитает это бесплатно. Почти не будет → аутсорсинг норм.
6. Какой вам нужен горизонт по бюджету? «Фикс на проект» → аутсорсинг. «Предсказуемая месячная стоимость на разработчика» → аутстаффинг.

Если четыре из шести ответов смотрят в одну сторону — это и есть ваш ответ. Если расклад три-три, это сигнал: работа на самом деле состоит из двух разных работ. Делите.

Почему в Беларуси этот выбор весомее, чем в других юрисдикциях

Здесь как раз заходит белорусская специфика. Три пункта, которые в других странах СНГ не работают (или работают слабее).

ПВТ меняет математику аутстаффинга

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

Трудовой кодекс защищает работника, не работодателя

Уволить можно только по основаниям из статьи 42. Выходное пособие при увольнении без виновных оснований — обычно три оклада. Защищённые категории — беременные, в декрете, в отпуске по уходу — в большинстве случаев уволить нельзя вообще. Обе модели снимают этот риск с вас, но аутстаффинг делает его прозрачным (агентство — юридический работодатель; стоимость видна в месячном счёте). Аутсорсинг прячет тот же риск в фикс, который вы не можете аудировать.

С английским в IT всё сильно, но управление никто не отменял

Обе модели работают на английском — большинство сеньоров уверенно живут на B2 и выше. Но аутстаффинг от этого выигрывает больше: вы управляете разработчиком напрямую, без переводчика-PM. Текущая рыночная картина: средние зарплаты в IT в Беларуси держатся в районе 1 600–1 900 долларов на мидловом уровне, сеньоры — заметно выше. Беларусь по-прежнему в топ-30 мировых направлений IT-аутсорсинга — глубокая скамейка, особенно по бэкенду, мобильной разработке и геймдеву. Контекст по рынку: по данным обзора TechBehemoths по Беларуси IT-сектор стабильно держится около 6,1% ВВП.

Числовой пример

Абстрактный каркас встречается с конкретными числами. Кейс ниже — собирательный, на основе того типа запросов, которые мы получаем еженедельно. Цифры реалистичны для мая 2026.

SaaS-компания из Берлина хочет добавить трёх инженеров — сеньор-бэкенд, мидл-фронтенд и QA — для развития продукта. Команда нужна как минимум на 18 месяцев, и дорожная карта по продукту будет несколько раз перетряхиваться по пути.

Вариант 1. Аутсорсинг через белорусский дев-шоп. Примерно €8 000–12 000 в месяц на инженера с учётом наценки за PM и маржи подрядчика, плюс 2–3 недели на скоуп и договор на старте, плюс PM, сидящий между вами и разработчиками, плюс допсоглашение каждый раз, когда дорожная карта дрогнула. Допсоглашения не бесплатные — обычно 5–10% юридических и переторговочных накладных на каждое изменение.

Вариант 2. Аутстаффинг через ПВТ-резидента. Зарплаты разработчиков по рынку — сеньор-бэкенд гросс ~3 500–5 000 долларов, мидл-фронтенд ~2 500–3 500, QA ~2 000–2 800 — плюс плоский сервисный сбор €350/мес. на инженера. Онбординг — 1–2 недели от первого собеседования до первого рабочего дня. Управление прямое. PM-наценки нет. Маржи поверх — нет.

На горизонте 18 месяцев в продуктовой разработке математика не близкая, и разрыв растёт по мере того, как скоуп двигается. Оговорка: реальные ставки зависят от стека, грейда и тайминга, цифры выше — иллюстративные, а не оффер. Но форма ответа держится в подавляющем большинстве запросов, которые мы видим.

Если всё ещё не уверены, какая модель ваша

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