Background Checks in Belarus: Legal Limits and Practical Alternatives for IT Hiring

Hiring a senior developer in Minsk. The standard playbook from back home kicks in. Identity verification. Prior employment confirmation. Criminal record check. Social media review. Maybe a credit check for a senior position. You’ve done this a hundred times. Then the recruiter sends back a polite note. Most of that isn’t allowed under Belarusian law for an IT role. The criminal record check is reserved for specific regulated positions — software developer isn’t one of them. The consent form needs statutory language you don’t have. And the “legitimate interest” basis you’d lean on under GDPR doesn’t exist as a legal basis under Belarusian data protection law at all.

Welcome to the gap between what feels like normal hiring due diligence and what Belarusian law actually permits. It’s wider than most foreign IT employers realise. It’s also entirely workable, once the framework is designed around it rather than retrofitted after the first candidate quietly declines and walks away.

Below: the legal framework that actually applies, what Belarusian law permits and what it doesn’t, the criminal record check question that catches almost every foreign client at kickoff, the cross-border data transfer issue that catches EOR setups, and the practical alternatives that produce better hiring decisions than US-style document screening ever did. Plus two possible cases from practice — including one where the playbook had to be torn up after six weeks of wasted recruitment effort.

The three laws that actually govern this

Three pieces of Belarusian legislation control what an employer can and can’t do when screening candidates. Foreign IT employers typically know about none of them at the kickoff call. Worth getting straight before the first job offer goes out.

The Labor Code

Article 26 lists the documents an employer can require from a candidate. The list is finite. Passport (or other ID). Employment record book. Education certificate. Military registration documents where applicable. Social insurance certificate. That’s essentially it. Anything outside this list — including criminal record certificates for a general IT role — needs a specific legal basis. You can’t add documents to the list as a contractual condition just because your global HR policy says so.

The Personal Data Protection Law (PDP Law)

Law No. 99-Z of 7 May 2021. GDPR-structured, but materially different in critical respects. The biggest difference for employment screening: legitimate interest isn’t a legal basis for processing personal data under Belarusian law, the way it is under GDPR. Consent is the practical foundation for almost everything an employer does beyond what Article 26 directly requires. The law reaches Belarusian and foreign employers handling Belarusian residents’ personal data — extraterritorial in the same way as GDPR is, with the same implications for offshore EORs and parent companies.

Edict No. 422 of 28 October 2021

The administrative framework. Supervisory authority is the National Personal Data Protection Center. Practical responsibilities for the data controller — your employer entity — include maintaining processing records, documenting consent, securing data transfers, and being able to demonstrate compliance on request. The Edict and its implementing acts are tracked on

The Belarusian national legal portal; the Center publishes its own guidance and supervisory materials at cpd.by.

What you can actually screen for

The operational core. What’s permitted — with the right consent framework — for an IT role in Belarus. Read this carefully. The shape is narrower than you think going in, and broader than you’d guess once you see it laid out.

Standard verification under Article 26

• Identity through passport. Part of the standard document set. No additional legal hook needed.
• Education certificates and diplomas. Also Article 26. Verifiable directly with the issuing university — most universities in Belarus and abroad will confirm a degree on request.
• Employment record book confirming prior Belarusian employment. The Belarus-specific document the candidate has. You look at it. Standard.

Permitted with proper consent

• Reference checks with prior employers. Written consent, prior employer willing to engage. Works well when the prior employer is responsive — which in the Belarusian IT market they often are, because the market is small and people stay in touch.
• Verification of professional certifications. AWS. Microsoft. Google Cloud. ISTQB. CKAD. The candidate cited them; the certifying body confirms them. Standard practice.
• Review of publicly accessible social media. LinkedIn, public GitHub, public X. Even publicly accessible content is still personal data being processed — needs consent and needs to be proportionate to the role.
• Technical assessments. Coding challenges, system design sessions, take-home projects. The primary signal for IT hiring, and entirely outside the personal data minefield.

Requires specific statutory basis (not available for general IT roles)

• Criminal record certificate. Only for positions in state security, law enforcement, education, healthcare, finance, customs, and a few other specifically regulated sectors. IT developer, designer, project manager, product manager, QA engineer, data engineer — not on the list.
• Credit history. Generally not permitted for employment without a specific regulatory basis. Senior finance roles within regulated financial institutions are the narrow exception.
• Medical examinations. Only where the role triggers a statutory medical-fitness requirement. Not a generally available employer tool.
• Polygraph or psychological testing. Heavily restricted. Requires specific statutory authority for the role. The number of IT roles with that authority is approximately zero.

The criminal record question — the mistake every foreign client makes

Foreign IT employers ask for this constantly. Almost always inappropriate. Worth its own section because the mistake is so common, the legal exposure so avoidable, and the conversation so tedious to have on day one of every kickoff.

The Belarusian criminal record certificate comes from the Ministry of Internal Affairs. Around twenty working days to issue. Routinely issued to individuals for their own purposes: visa applications, immigration, foreign employment. The employer-side question is whether you can require it as a hiring condition.

For most IT roles, no.

• There’s no general “we run criminal checks on everyone” model in Belarusian employment law. The check is statutorily tied to specific role categories. Software developer, product manager, designer, QA engineer — those categories aren’t on the list. There’s no umbrella authority for an employer to demand it across the board.
• Asking anyway, as a contractual condition, creates two layers of exposure. PDP Law exposure for collecting personal data without lawful basis. Labor Code exposure for requiring documents outside the Article 26 list as a hiring condition. Neither is theoretical.
• Voluntary provision is a different analysis. The candidate can voluntarily obtain and provide the certificate. The employer can voluntarily receive it. Different rules, different exposure. But genuine consent has to be genuinely voluntary — not extracted under threat of withdrawn offer.
• The narrow exceptions: roles touching state secrets, certain financial-services positions regulated by the National Bank, security roles in critical infrastructure, healthcare-adjacent IT roles handling sensitive medical data. Each requires its own analysis.

This comes up in almost every kickoff conversation with a new foreign IT client. The instinct comes from US, UK, or German hiring practices where pre-employment screening is the cultural default and nobody questions it. In Belarus the default is narrower. The framework is workable — but “run a criminal check on everyone” isn’t the route in, and trying to make it one creates problems faster than it solves them.

Social media checks 

Less black-and-white than the criminal record question. Still tightly regulated. Worth understanding before the recruiter does what feels like normal due diligence and creates a problem nobody noticed.

• Publicly accessible content (LinkedIn, public X, public GitHub) — generally reviewable. But the review processes personal data. Consent and proportionality still apply. You don’t get to wave them off just because the content was visible.
• Private content — off-limits. Friends-only Facebook, locked-down Instagram, private profiles. Attempting access through deception or pretexting creates clear PDP Law liability, and creates an unwinnable conversation with the candidate if it surfaces.
• Cached, archived, or historical content — same rules as live content. Findability isn’t the same as lawful processability. The fact that a Google search turns up a forum post from 2014 doesn’t make it a free game.
• Proportionality. Senior leadership in a public-facing role can justify deeper review. Backend developers can’t. The PDP Law requires the controller to demonstrate the legal basis and the proportionality of the processing — both, not either.
• Documentation. The Center can ask the controller to demonstrate compliance. “We looked at their LinkedIn” needs to fit into a documented framework — purpose, legal basis, retention period.

Cross-border data transfer — the thing that catches EOR setups

The aspect that catches multinational employers and offshore EOR providers more than any other. Personal data of Belarusian residents flowing to a foreign parent, an offshore HRIS, a US-based recruitment agency, an EOR provider sitting elsewhere — all regulated under the PDP Law. None of this is optional.

The framework requires the destination jurisdiction to provide an “adequate level of protection” for data subjects’ rights. Belarusian adequacy criteria aren’t identical to GDPR’s. Practical groupings:

• EU member states. Generally treated as adequate. Council of Europe Convention 108 membership matters here.
• EAEU member states — Russia, Kazakhstan, Armenia, Kyrgyzstan. Explicitly treated as adequate by the framework.
• United States. More nuanced. Depends on the specific entity, contractual safeguards in place, and type of data flow. Don’t assume — verify.
• Other destinations without adequacy — specific contractual safeguards required, or explicit informed consent of the data subject for the transfer.

Practical implication for foreign IT employers. If you’re a US tech company hiring Belarusian developers through a Belarusian EOR, the background screening data flow has to be designed for adequacy from day one. Retrofit fixes are awkward. Experienced Belarusian recruitment partners build this into their workflows automatically. Our EOR and payroll services are structured around exactly this compliance architecture — including the data-flow design for cross-border HR processes.

What actually works for IT hiring — the practical alternatives

Where the article earns its keep. Real techniques that work within the legal framework — and that produce better hiring outcomes than the document-heavy screening foreign IT employers default to.

Technical screening as the primary signal

For IT hiring, this is the single most predictive signal you can generate. Hands-on technical assessments. Live coding interviews. System design discussions for senior roles. Take-home projects with realistic scope. Pair programming sessions with the team the candidate would join. Public GitHub review where the candidate has meaningful contributions. None of this touches the personal data framework. All of it is more predictive of actual on-the-job performance than any document review. Foreign employers underweight this. Belarusian employers don’t.

Reference checks that actually work

Direct calls with prior managers, with the candidate’s written consent and the prior employer’s willingness to engage. Confirming employment dates, role, scope, reason for leaving. Asking specific behavioural questions instead of generic “would you hire them again” prompts — which produce vague positive answers regardless of actual performance. Cross-checking the candidate’s narrative against multiple independent reference points. Allowed. Works. Underused because it takes time.

Identity and credential verification

Article 26 document review handles identity and prior Belarusian employment. For credentials, verify directly with the issuing body — Microsoft, AWS, Google Cloud, ISTQB, vendor certification authorities. Education verification through the university. LinkedIn cross-check on dates, roles, scope using publicly accessible content. All inside the framework.

The probation period as your real safety net

Belarusian labour law allows probation periods of up to three months for most positions. Sophisticated Belarusian IT employers treat the probation period as the real background check — actual performance on actual work, which is more predictive than any document. The employer can terminate during probation with three days’ notice and minimal documentation. Build the probation period into your hiring framework deliberately and you get the equivalent of due diligence without the personal data exposure. Most foreign clients underuse this. The ones who get it right structure performance milestones at thirty, sixty, and ninety days, and treat the decision at day ninety as the real hiring decision.

Working with an experienced local recruitment partner

Belarusian senior IT talent is a relatively small market. Senior developers in Minsk are largely known quantities within the local community — references travel through industry networks rather than through formal channels. A local recruitment partner with established relationships can vouch for candidates based on long-term market knowledge no foreign recruiter can replicate. Concerns from prior placements surface naturally. Our IT recruitment service and HTP recruitment specifically are built around exactly this kind of local-market depth. Hard to retrofit; obvious in the results.

HTP-specific considerations

Brief but worth flagging — the firm’s audience overlaps heavily with Hi-Tech Park residents.

Hi-Tech Park residency simplifies many HR processes and brings real tax benefits. It does not change the PDP Law framework. HTP residents handling personal data operate under the standard constraints — same consent requirements, same Article 26 limits, same cross-border transfer architecture. HTP’s flexibility on labour terms (foreign worker hiring, contract types, remote work) doesn’t extend to relaxing personal data processing rules. Some new HTP residents assume residency benefits cover this too. They don’t.

Our HTP residency support covers the application and entry process. The HR processes inside the HTP framework still follow the standard PDP Law architecture.

The consent document — where most of the legal work lives

The single document doing most of the heavy lifting in any IT screening process. Get this right and the rest of the framework holds together. Get it wrong and you’ve built a hiring process on sand.

A working consent for personal data processing in IT hiring should:

• Identify the data controller — the employer entity, or the recruitment agency where the agency holds controller status.
• List the categories of personal data being processed. Identity data. Contact data. Professional data. Educational data. Reference data. Specific, not generic.
• State the purposes for processing. Recruitment evaluation. Employment relationship. Payroll. Regulatory compliance. Each purpose stated, each justifiable on its own.
• Identify the legal basis — consent under the PDP Law, plus statutory basis for Article 26 data where applicable.
• List third parties who will receive the data. EOR provider. Payroll provider. Parent company. Recruitment agency. Background verification provider where used. All named.
• Specify cross-border transfer destinations and the legal basis for transfer. Adequacy, contractual safeguards, or explicit consent.
• Set the retention period explicitly. For unsuccessful candidates, only as long as necessary for the recruitment process and any defensive purpose — six to twelve months is a typical range. For successful hires, the data shifts into the employment-relationship framework.
• Inform the candidate of their PDP Law rights. Access. Correction. Deletion. Withdrawal of consent. Each spelled out.
• Allow the candidate to consent to specific processing types separately where appropriate. Social media review as a discrete opt-in, for example.

Drafting that doesn’t meet these basics creates PDP Law exposure. We’ve seen consent forms drafted by foreign HR teams that wouldn’t survive a first read by the Personal Data Protection Center. The standard isn’t aspirational — it’s the operating baseline. Anything less and you’re relying on the Center being too busy to look.

Two possible scenarios 

Scenario A. The US fintech that learned the hard way

US fintech, series B, rolling out a global hiring program. Standard internal policy: criminal background check required for every role, every country, no exceptions. The US-based recruiter sent the consent form to the first Belarusian senior developer candidate — strong technical fit, six weeks of pipeline work behind them. The candidate read the form. Declined politely. Withdrew from the process. The recruiter flagged the issue. Five other shortlisted candidates raised the same concern in the next ten days. We were brought in to redesign the screening framework for Belarus. Keep the technical assessment depth — the part that actually produces signals. Keep the reference framework. Dropped the mandatory criminal check. Restructured the consent document to meet PDP Law standards. The role filled six weeks later. The framework now applies across the company’s other CEE hiring.

Scenario B. The Berlin scale-up with the proper EOR setup

Berlin-based scale-up hiring twelve Belarusian developers through a Belarusian EOR. German hiring instinct centred on prior-employer references as the primary signal. We helped structure the consent framework to meet PDP Law standards. Set up the cross-border data transfer architecture to enable the German parent to access HR data through compliant channels. Built the three-month probation period into the hiring workflow as the practical performance filter — milestones at thirty, sixty, and ninety days, with the day-ninety conversation as the real hire-or-not decision. Twelve months later: eleven of the twelve hires are still in role, and three have been promoted to senior positions. The framework that looked restrictive on paper proved entirely sufficient in practice when combined with strong technical assessment and structured probation.

Different profiles. Same underlying lesson. The Belarusian framework works when designed correctly from the start. The mistake foreign IT employers make isn’t failing to follow Belarusian law — it’s assuming their home-country playbook will translate without redesign. It won’t. But the redesign isn’t that hard, once someone walks them through it.

The decision framework — what to actually screen for

Practical checklist. Cut this out and give it to your recruiter.

Always (legally clean for any IT role)

• Article 26 document verification — passport, education, employment record book.
• Direct verification of education with the issuing institution.
• Direct verification of professional certifications with the certifying body.
• Technical assessment proportionate to the role.
• Reference checks with the candidate’s written consent.
• Documented consent for personal data processing meeting PDP Law standards.

For senior or sensitive roles (with a proper consent framework)

• Detailed reference checks with multiple prior managers.
• Public profile review with documented proportionality.
• Architectural and leadership-decision discussions for technical leaders.
• Multi-stage interview process, including non-technical leadership conversations.

For specific regulated roles only

• Criminal record certificate — only where statutorily required for the role category.
• Financial regulatory checks — only for regulated financial services positions.
• Healthcare-specific screening — only for roles handling sensitive medical data with a statutory basis.

Never (without specific statutory authority)

• Mandatory criminal record checks for general IT roles.
• Credit history checks.
• Polygraph testing.
• Mandatory medical examinations beyond labour code requirements.
• Private social media access through any means.
• Pretexting, deception, or undisclosed third-party investigation.

Frequently asked questions

Can we require a Belarusian criminal record certificate for a senior developer role?

Not as a legal matter. The certificate is required by statute for specific position categories — state security, law enforcement, education, healthcare, finance, customs — and a senior developer isn’t one of them. Asking for it as a contractual condition creates exposure under both the Labor Code and the PDP Law. Different analysis if the candidate volunteers the certificate. But volunteering has to be genuinely voluntary.

Our US parent runs background checks on everyone. Why can’t we do the same in Belarus?

Different legal framework. US background screening is built on the Fair Credit Reporting Act and a nearly universal culture of pre-employment due diligence. Belarusian employment law restricts what an employer can demand to a finite list. The PDP Law further restricts processing. The US, UK, and German playbook doesn’t translate without redesign. The framework is workable — just not by porting the US version wholesale.

What if the candidate volunteers their criminal record certificate?

Different analysis. Voluntary provision is permitted. But voluntary has to be genuinely voluntary — not extracted under threat of withdrawal of the offer. And the employer’s subsequent processing still requires consent and proportionality. Most foreign IT employers we work with abandon the criminal check altogether for general IT roles once they see what compliance actually requires. The information value is rarely worth the design overhead.

Does the PDP Law apply if we’re using a US-based recruitment agency?

Yes. If the agency processes the personal data of Belarusian residents, the law applies to that activity. Extraterritorial reach similar to GDPR’s. The agency must be set up to comply with proper data processing agreements between the agency, the EOR (if one exists), and the parent company. All three sides of the triangle need to be aligned.

How long can we retain data on unsuccessful candidates?

Only as long as necessary for the recruitment process and any related defensive purposes. Six to twelve months is a typical range, though the right number depends on the role and any potential dispute risk. The retention period should be specified explicitly in the consent document. Indefinite retention isn’t permitted, and “we keep CVs forever” is the kind of thing that catches you in a Center audit.

What happens if we get this wrong?

Administrative liability under Belarusian law, supervised by the National Personal Data Protection Center. Specific penalties depend on the violation type, the controller’s scale, and whether the violation was systematic. The reputational exposure with candidates is sometimes more significant than the legal exposure — Belarusian IT talent is sophisticated about data protection and notices when employers overreach. Word travels in a small market.

The framework that actually works

Belarusian law on background checks is more restrictive than foreign IT employers expect. That’s the honest framing. The fix isn’t a workaround or a clever document — it’s designing the screening framework around what actually works in this jurisdiction. Strong technical assessment. Direct credential verification. Reference checks are built on real conversations. A consent document that meets PDP Law standards. A probation period structured deliberately as a real performance test.

The IT employers we see succeed in Belarus aren’t the ones with the most thorough US-style background check apparatus. They’re the ones who designed for Belarus from the start — and who built their screening around the things that actually predict on-the-job performance rather than the things that feel reassuring in an HR audit.

If you’re building out IT hiring in Belarus and want to design the framework correctly from the start, get in touch. Short scoping call, framework review, structure recommended. Most foreign IT employers benefit substantially from that conversation happening before the first candidate hits the pipeline. After the first candidate walks it is later than it needs to be.

GDPR Compliance for Belarusian IT Vendors Working With EU Clients

Here’s a pattern we’ve been seeing for the past two years.

A Belarusian IT company wins the technical conversation with a European client. Strong portfolio, solid references, the chemistry is right, the price is competitive. Everyone on the call thinks the deal is close to done. Then the conversation moves to legal and compliance — and somewhere between the proposal and the signed contract, the deal goes quiet. Sometimes the EU client comes back with a polite “we’ve decided to go with a vendor closer to home.” More often they just stop replying.

The blocker is usually the data protection conversation. Sometimes formally — the GDPR review fails some specific test. More often informally — the EU client’s internal compliance team flags Belarus as a third country, the procurement process gets harder, the deal slips a quarter, and the contract ends up in Warsaw or Bucharest.

This article walks through what’s actually happening on the other side of that compliance review. What EU clients are really asking. Where the friction sits for a Belarus-based vendor, specifically. And what the practical setup looks like in 2026 — the one that gets through procurement instead of getting parked there.

Standard caveat first. We’re a recruitment agency, not a law firm. We hear this conversation from both sides of every placement, but for the legal mechanics of your specific contract you need a qualified data protection lawyer. What this article gives you is the lay of the land.

The starting fact that most people misunderstand

Belarus is not on the EU adequacy list. This single fact drives most of what follows in this article, and it surprises many Belarusian IT companies the first time they encounter it.

Under the GDPR, personal data of EU residents can move freely inside the European Economic Area, plus to a small list of countries the Commission has decided offer “adequate” protection — the UK, Switzerland, Japan, South Korea, Israel, a few others. Belarus is not on that list. So any transfer of personal data from an EU client to a Belarusian processor is a transfer to a third country, and Chapter V of the GDPR kicks in. You need an additional legal basis. Almost always that means the European Commission’s Standard Contractual Clauses — and since the Schrems II judgement in 2020, a Transfer Impact Assessment on top.

This is the part where Belarusian IT companies sometimes push back: “But we have Belarusian Personal Data Protection Law compliance. Law No. 99-Z of 2021. Doesn’t that count?”

It counts for what Belarusian law requires of you domestically. It does not substitute for the EU-side mechanics. The Belarusian law was built broadly on GDPR principles, but it hasn’t been recognised as adequate by the Commission, and EU clients still treat Belarus as a third country. Having local compliance is necessary; it just isn’t sufficient. The EU client needs their own transfer paperwork in place regardless of what you’ve done locally.

This isn’t unique to Belarus. Most countries outside the EEA are in the same position. The point is that hearing “we have a privacy policy that mentions GDPR” doesn’t carry the weight some Belarusian vendors think it does in a European procurement conversation.

What EU clients actually ask — and what they’re really worried about

From conversations with our placement clients on both sides, the questions that come up most often during procurement:

• “Where is the data hosted?” — they want to know if EU personal data ever physically leaves the EU.
• “Where are your engineers located?” — because a Belarusian engineer accessing data sitting in an EU data centre is itself a transfer under GDPR, even if the data doesn’t move.
• “Do you have Standard Contractual Clauses in place?” — at this point this is table stakes, not a differentiator.
• “Have you done a Transfer Impact Assessment for Belarus?” — increasingly common in 2025 and 2026, used to be rare.
• “What does Belarusian law say about government access to personal data?” — the Schrems II concern, applied directly to your jurisdiction.
• “Are you GDPR-compliant?” — the question that doesn’t quite mean what it sounds like. What they actually mean is: can you sign our Data Processing Agreement, pass our security review, and not create a problem for our compliance team.
• “Do you have a Data Protection Officer?” — sometimes legally required, often expected even where it isn’t.

What they’re actually worried about underneath these questions usually isn’t the formal law. It’s a reputational risk. Audit trail risk. The possibility that a data subject brings a complaint, a regulator opens an investigation, and a Belarusian vendor’s documentation becomes the EU client’s problem — not the vendor’s. The EU client is the data controller. They carry the liability under GDPR. Your job in procurement is to convince them that working with you doesn’t increase their risk surface in a way they can’t defend later.

The Schrems II problem, in plain English

In July 2020 the Court of Justice of the European Union issued the Schrems II judgement, which changed the practical conversation around third-country transfers. The headline finding was that the EU–US Privacy Shield was invalid. The broader finding, which matters more for everyone else, was that SCCs alone aren’t enough.

The court held that the EU exporter has to assess whether the recipient country’s laws and practices allow public authority access to personal data in ways that would conflict with the rights guaranteed by EU law. If they do, the exporter needs supplementary measures to bring the protection back up to an essentially equivalent level — or they shouldn’t be transferring the data at all.

The European Data Protection Board published recommendations on supplementary measures the following year, and those recommendations now sit at the centre of every serious procurement review involving a third-country vendor. For a Belarus-based vendor, the honest TIA conversation includes the Belarusian Personal Data Protection Law as a domestic framework, the operational realities of state access to data held by Belarusian companies, and the specific supplementary measures the vendor takes to mitigate identified risks.

Encryption in transit and at rest, with key management held outside Belarus. Strict access controls and logging. Pseudonymisation of personal data wherever the use case allows. Data minimisation — engineers shouldn’t have access to data they don’t need for the task. Clear documentation of who can access what, and an audit trail that shows it.

Here’s the part that separates a useful TIA from a useless one. A TIA that says “Belarus poses no concerns, no supplementary measures required” is the TIA that fails a senior compliance review on the EU side. A TIA that says “here are the realistic concerns about state access, here are the specific mitigations we have in place, here’s why this particular data set can be transferred under these specific safeguards” — that’s the document EU compliance teams will actually accept. Honesty in the assessment is what gets it approved.

The contract layer — SCCs, DPAs, and what foreign counsel expects

The contractual stack a Belarusian vendor needs for EU work is fairly standard at this point. Three documents do most of the work.

Standard Contractual Clauses (2021)

The European Commission’s updated SCCs were adopted in June 2021 and have been the working transfer mechanism since. They come in modular form — controller-to-controller, controller-to-processor, processor-to-processor — and the Belarusian vendor signs whichever module matches the role they’re playing. Most often that’s the processor or sub-processor. The Commission keeps the official SCC text and guidance up to date.

Data Processing Agreement (Article 28 GDPR)

The EU client, as controller, will want a DPA defining the scope of processing, the purposes, the categories of data, the security measures, sub-processor rules, breach notification mechanics, and audit rights. Sometimes the DPA is a separate document; sometimes it’s incorporated into the main services agreement as an annex. The Belarusian vendor’s job is to read it carefully before signing — not after.

Sub-processor chain documentation

Anyone touching the personal data on your behalf counts as a sub-processor — cloud providers, third-party tools, downstream contractors, all of them. The DPA will ask you to name them, obtain the client’s sign-off, and notify the client when the list changes. Vendors who skip the documentation step end up in awkward conversations several months in, when an audit turns up a relationship nobody told the client about.

One mistake we see often. EU procurement teams present their standard DPA to the Belarusian vendor, and the vendor signs it without carefully reading the operational obligations. Then a year later, something happens — a small data incident, a sub-processor change, an audit request — and obligations the vendor can’t actually deliver come into focus. Notification timelines that are unrealistic. Audit rights that would require disclosure beyond what the vendor can disclose. Negotiate at the signing stage. Don’t be afraid to mark up the DPA. EU clients respect a vendor who reads what they’re signing more than one who just signs it.

The technical and organisational setup that actually works

Past the paperwork, there’s the operational stack the EU client’s security team will want to see. The practical defaults for a Belarusian IT vendor working with EU customers in 2026:

• EU-hosted infrastructure as the default — AWS Frankfurt, Azure West Europe, Google Cloud Belgium. This single architectural decision removes a meaningful portion of the transfer conversation, because the data physically remains in the EU and only the access component is cross-border.
• Access control and audit logging, identifying who accessed what data, when, and for what purpose, retained in accordance with contractual and jurisdictional requirements, and available to the EU client on request during audit.
• Encryption in transit (TLS) and at rest, with key management held in the EU where the use case permits. Encryption is one of the core supplementary measures identified in the EDPB recommendations.
• Pseudonymisation and data minimisation. Engineers working on production data should be working on the minimum necessary subset, pseudonymised where feasible. Production data on development laptops is among the fastest routes to a failed security review.
• A designated DPO where Article 37 GDPR requires one — large-scale systematic monitoring, large-scale processing of special category data. Even where designation is not strictly mandatory, having one named and reachable signals seriousness to the EU client.
• A documented breach notification procedure aligned with the 72-hour clock. The procedure must be written, tested, and known to the operational team — not assembled in the moment an incident occurs.
• A maintained, disclosed, and updated sub-processor list, with change notification mechanics agreed with the client in advance.
• For HTP-resident companies, much of this is already standard enterprise practice. The High-Tech Park framework supports paperless contracting, English-language commercial relationships, and elements of English commercial law — all of which make the EU-facing contractual conversation more straightforward. For non-HTP companies, the gap is typically wider, and that is where setup work tends to concentrate before serious EU engagements can be signed.

For HTP-resident companies, much of this is already part of standard enterprise practice. The High-Tech Park framework supports paperless contracting, English-language commercial relationships, and elements of English commercial law — all of which make the EU-facing contract conversation smoother. For non-HTP companies, the gap is usually wider, and that’s often where setup work concentrates before serious EU contracts can be signed.

The part nobody talks about openly: the sanctions overlay

Here’s the section that distinguishes an honest article from a marketing piece. Some EU clients have internal procurement policies that go beyond what GDPR strictly requires. They won’t process personal data through vendors based in countries on certain sanctions lists, regardless of whether the GDPR-compliant mechanics are in place. This isn’t a GDPR question. It’s a procurement policy question. And it’s increasingly the actual reason Belarusian IT vendors lose European deals.

The formal GDPR conversation can be passed. The internal policy filter is harder, because it’s not a legal test — it’s a risk-appetite test set by the EU client’s own compliance leadership. Sometimes the bar is unreachable from Belarus regardless of how good the vendor’s documentation is. Other times it’s manageable, but requires the vendor to think about structure rather than just compliance.

The structural responses Belarusian vendors actually use in 2026 cluster into three patterns.

Belarus-only with strong documentation

The vendor contracts directly with the EU client from Belarus, with SCCs, DPA, TIA, and the full operational stack. Works for smaller EU clients without restrictive procurement policies, or for clients where the relationship pre-dates the policy tightening. Cost-effective. Won’t work for tier-one enterprises with strict third-country policies.

Belarus plus an EU entity

The vendor establishes a subsidiary or branch in an EU jurisdiction — Poland, Lithuania, Cyprus are the common choices — that contracts with EU clients directly. The Belarusian entity becomes an intragroup sub-processor under the EU subsidiary’s primary contract. Significantly easier to clear procurement. More expensive to set up and maintain. Doesn’t eliminate the underlying GDPR mechanics — the intragroup data flow still requires SCCs and a TIA — but it changes the commercial-facing structure to something EU procurement teams find easier to accept.

Belarusian vendor as a sub-supplier under an EU prime

The EU client signs a contract with an EU-based prime contractor, and the prime contractor subcontracts the work to the Belarusian vendor. The compliance umbrella belongs to the prime. The contract paperwork largely lives in the relationship between the prime and the end client. This works well when the EU client needs an EU-headquartered counterparty on the front of the contract but is comfortable with the actual delivery happening from a third country further down the chain.

None of these three structures makes the underlying compliance questions go away. What they do is take friction out of procurement. The honest read for a Belarusian vendor: when a pipeline keeps stalling at the compliance step, the problem isn’t always the paperwork — sometimes it’s the structure itself. And if that’s the case, no amount of additional documentation fixes it. The fix has to be structural too.

Common mistakes Belarusian IT vendors make

The patterns we see consistently.

Treating compliance as a website privacy policy

“We have a GDPR-compliant privacy policy on our site.” This is necessary but is not what an EU client’s procurement review is asking about. They’re asking about an operational system — documented, auditable, defensible under scrutiny. The privacy policy is the cover page. The substance is the operational stack behind it.

Signing the EU client’s DPA without reading the operational obligations

EU procurement DPAs sometimes come loaded with obligations a Belarusian vendor can’t actually deliver as written. Notification timelines are pinned to specific local laws. Audit rights that run afoul of Belarusian confidentiality rules. Direct data-subject notification requirements that don’t match how the vendor actually operates. Sign without reading, and the problems don’t show up right away — they surface twelve months in, during an audit, when it’s too late to renegotiate. Read first, push back where it doesn’t fit, then sign. That order matters.

No documented Transfer Impact Assessment

In 2026, not having a TIA is increasingly the line item that loses the procurement check. EU clients have stopped treating it as nice-to-have paperwork — they treat it as a file they expect to see. A Belarusian vendor without one is at a specific, well-defined, and easy-to-close disadvantage. There’s no good reason to leave it open.

Engineers accessing real client data without controls

Production data on personal laptops. Database dumps shared over messaging apps. Real EU customer records were used in development environments because seed data felt like too much work. Every audit catches some version of this. The fix is technical and organizational — controlled environments, pseudonymized dev data, and real access logging.

Undisclosed sub-processors

Your cloud provider. Your email tool. Your monitoring service. Your analytics platform. Every one of them might be touching EU personal data on your behalf, and every one of them should be on a sub-processor list that your EU client has seen and approved. Sub-processors that nobody told the client about are one of the fastest ways to fail an audit — and the conversation when they’re discovered is always worse than the one you’d have had upfront.

Treating Belarusian local compliance as a substitute for GDPR mechanics

Covered earlier, but worth saying again because it’s the misunderstanding that costs the most deals. Complying with the Belarusian Personal Data Protection Law meets the requirements Belarus imposes on you. It doesn’t handle what the GDPR requires of the EU client sending data your way. SCCs, TIAs, Article 28 DPAs — none of that gets ticked off by a Belarusian compliance certificate. The two regimes run alongside each other, and you need both.

A short setup checklist

Built to be saved and forwarded internally.

• Standard Contractual Clauses (2021 modular version) prepared and in place with EU clients.
• Data Processing Agreement template reviewed by counsel, with non-negotiable terms identified.
• Documented Transfer Impact Assessment for Belarus, available on request, refreshed annually.
• EU-hosted data infrastructure as the default, where the use case permits.
• Access control and audit logging with retention aligned to contract requirements.
• Encryption stack documented — algorithms, key management, scope.
• Pseudonymization and data minimization practices for development and testing environments.
• DPO designated where required by Article 37; reachable contact details published.
• Breach notification procedure documented, tested, and known to the team.
• Sub-processor list maintained and disclosed to clients, with change notification mechanisms agreed.
• All client-facing documentation in English, structured for procurement review rather than internal use.

FAQ

Do we need to establish an EU entity to work with EU clients?

Not strictly. EU clients can contract directly with a Belarusian vendor under SCCs and a properly documented compliance setup. In practice, the answer is more nuanced. For smaller EU clients without restrictive procurement policies, Belarus-only is workable. For tier-one enterprises with strict third-country policies, an EU subsidiary or a sub-supplier-to-EU-prime structure is often the practical route. The decision is commercial more than legal.

Is the Belarusian Personal Data Protection Law equivalent to GDPR?

The Belarusian law was modeled broadly on GDPR principles, but it has not been recognized as adequate by the European Commission. From the EU client’s perspective, Belarus remains a third country, and the standard transfer mechanics apply regardless of local compliance. Domestic compliance discharges domestic obligations. It does not substitute for the EU-side framework. The two regimes operate in parallel, and both need to be in order.

What does a Transfer Impact Assessment for Belarus actually look like?

A document — usually 8–15 pages for a typical vendor — that identifies the personal data being transferred, assesses the risks under Belarusian law and practice (including state access concerns), and documents the supplementary measures used to mitigate those risks. Encryption, pseudonymization, access controls, contractual safeguards. An honest TIA acknowledges risks; it doesn’t pretend there are none. EU compliance teams trust honest assessments more than reassuring ones.

Can we just sign the EU client’s DPA without changes?

Sometimes. The problem is that EU procurement DPAs sometimes contain obligations that don’t align with the operational realities of a Belarus-based vendor. Notification timelines tied to specific local laws. Audit rights that conflict with local confidentiality. Direct data-subject notification requirements. Read carefully before signing. Negotiating the DPA at the signing stage is normal practice and won’t cost you the deal — signing one you can’t deliver against will cost you the relationship later.

Do we need a DPO?

Article 37 of the GDPR is the place to look. It makes designation mandatory in three situations: you’re a public authority, your core business involves large-scale systematic monitoring of people, or your core business involves large-scale handling of special category data. Most Belarusian IT service vendors don’t fall into any of those buckets, so formal designation isn’t legally required. That said, plenty of EU clients expect one anyway — and naming a trained DPO with a real, reachable contact line signals you take the topic seriously, which matters in procurement regardless of what the strict legal reading says.

What about the EU AI Act — does it apply to us?

The AI Act, in force since 2024 with phased application through 2027, applies to providers and deployers of AI systems whose output is used in the EU, regardless of the provideris location. If you’re building AI features that EU clients use, you’re likely in scope for at least some obligations. The compliance work is separate from GDPR, but increasingly comes up in the same procurement conversation. Worth raising with counsel as a distinct workstream.

How does HTP residency affect our GDPR conversation?

HTP residency doesn’t change the GDPR position — Belarus is still a third country regardless. But the HTP framework supports English-language contracts, elements of English commercial law in commercial matters, and paperless contracting, all of which make the EU-facing contractual conversation smoother. Most of the Belarusian IT companies that successfully serve EU customers are HTP residents, and that’s not a coincidence.

Are we losing EU deals because of GDPR or because of sanctions?

Honestly, often both, and the two get tangled in the same procurement conversation. The formal GDPR review can be passed with the right documentation. The internal policy filter — some EU clients have written policies that exclude Belarus-based vendors regardless of GDPR documentation — is harder. If your pipeline consistently stalls at the compliance step, the structural responses (EU subsidiary, EU prime contractor relationship) may be more useful than additional documentation. Diagnose which it is before you spend on the fix.

The bottom line

EU clients raise GDPR questions for a straightforward reason: they’re the data controller, they carry the liability under EU law, and their compliance team needs documentation that supports sign-off without exposing them to risk they can’t defend later. Most Belarusian IT vendors who lose EU deals at the compliance stage do so for one of three reasons: the documentation isn’t there, the operational stack isn’t structured for external review, or the corporate setup makes the EU client’s compliance team’s job harder than it needs to be.

Most of this is solvable. SCCs and a DPA template can be put together in a quarter. A TIA written honestly takes a few weeks. The operational stack — EU hosting, access controls, encryption, pseudonymized dev data — is enterprise-standard work, well understood by HTP-resident engineering teams. The structural side is more involved and more expensive, but it’s also where the most stubborn pipeline blockages get cleared.

At Recruitment.by we work with Belarusian IT companies on the people side of all of this — building teams that can deliver on EU contracts, supporting HTP residency for vendors building the right structure, joining the HTP for those who haven’t yet, and providing HR consulting for the organizational side of compliance setup. 

Bonus and Compensation Structures for IT Companies in Belarus: What Actually Motivates Developers

Here’s something we’ve been telling clients for years.

Two companies. Same kind of work. They both pay a senior backend developer roughly the same, within five, maybe ten per cent of each other on gross. One of them keeps that developer for four years. The other loses them after fourteen months. Same role, same money, completely different outcome.

The salary wasn’t the thing. It almost never is, by itself.

After more than a decade of placing developers into Belarusian IT companies — and quite often watching the same developers come back to us a year and a half later — we can tell you what the thing usually is. It’s the way the bonus and compensation structure is put together. How predictable the year-end conversation feels. Whether the performance bonus rewards things the engineer can actually do something about. Whether the long-term piece is real or just a line in the offer letter. Whether the whole thing holds up when the developer explains it to their partner at the kitchen table.

Base salaries in Belarusian IT have largely converged in 2026. Most companies in a given segment pay similar numbers. The real work has moved upstream, to the structure above the base. That’s where retention is won and lost now. This article is about how that structure actually fits together and where it tends to come apart.

Why salary alone stopped working

Through 2023 and 2024 the salary picture in Belarusian IT was unstable. Numbers moved fast in both directions. By 2026 things have settled. Most companies competing for senior developers are clustered fairly tightly around the same base ranges, and the ranges themselves don’t shift dramatically from quarter to quarter.

Within that band, the base salary becomes a hygiene factor. Are you paying the market salary or not? Pay market salary and you’re in. Pay under the market and you’re not. But paying the average amount of salary isn’t the same as winning it. And in2026, it cannot provide a total victory.

Specifically, in the structure of the annual cash bonus. Whether long-term incentives exist and feel credible. Whether the salary review actually happens when it was supposed to. Whether the whole compensation picture was explained well when the developer first joined and again at the end of year one.

When we see senior developers leave companies in 2026, it’s rarely about the base salary. It’s almost always about the structure above the base, feeling opaque, arbitrary, or simply ignored. And the awkward part is that fixing this is mostly free in cash terms. It costs attention.

Four layers — and why most companies build only one of them properly

We use a simple model when we’re advising clients on structure. Four layers. Each does a different job.

• Layer 1 — Base salary. Fixed, predictable. Pays the bills. Doesn’t motivate, but its absence demotivates instantly.
• Layer 2 — Annual cash bonus. The 13th-month salary, the performance bonus, or some mix of both. 
• Layer 3 — Long-term incentives. Equity, phantom stock, retention bonuses. The reason senior developers stay through year three and beyond, rather than checking the market every spring.
• Layer 4 — Non-cash motivators with structural weight. Career progression, L&D budget, recognition, and team quality. The stuff that doesn’t show up on the payslip but explains most of the retention story.

Almost every company offers Layer 1 carefully. Then they put something generic on Layer 2 — usually a 13th-month salary copied from what other companies do. They forget about Layer 3 unless they’re at a stage where investors are asking about it. And Layer 4 quietly becomes whatever HR has time for that quarter.

The result is a comp structure with a strong foundation and three unfinished floors. Which is why so many companies end up paying a competitive base and still losing senior people. They’re solving the easy part and ignoring the part where retention actually lives.

Layer 1: What base salary actually looks like in 2026

Honest market ranges for mid-2026, gross monthly in USD equivalent, before any benefits or bonus accrual.

• Senior backend developer (5+ years): $3,500 to $5,500
• Mid-level frontend: $2,200 to $3,500
• Senior DevOps / SRE: $3,800 to $5,800
• Senior QA / SDET: $2,800 to $4,200
• Tech Lead: $5,500 to $8,000 and up
• Staff Engineer or Principal: $7,000 to $10,000+

These are general numbers, taken from open sources. If you want the proper breakdown by stack, seniority band, and company type, our IT salary research covers it in detail.

Two structural points on base that matter more than the headline number.

The review. The default in Belarusian IT used to be annual review. At the better employers in 2026 it’s semi-annual, with quarterly conversations for high performers. The cadence matters less than the consistency though. A scheduled review that consistently slips — “we’ll do it in Q4,” which becomes Q2 of the following year, which becomes “let’s wait for the funding round to close” — is one of the most reliable ways to push a senior developer to start looking. By the time the review finally happens, they’ve usually already decided to change the company.

Layer 2: The annual cash bonus — three patterns, three different outcomes

This is where most Belarusian IT companies make the most consequential structural choice, usually without meaning to. Three patterns dominate the market right now.

The pure 13th-month salary

One month of base salary, paid in December, no performance variation. Everyone who’s still employed by 31 December gets it.

The advantage is simplicity. Developers know exactly what’s coming. There’s no negotiation, no political theatre at year-end, no scoreboard. Culturally it lands well — Belarusian developers grew up with the 13th-month as a normal concept, and seeing it in the offer reads as a serious employer rather than someone testing local norms.

The flip side is that it doesn’t differentiate. The developer who shipped a major platform migration gets the same December bonus as the developer who quietly coasted for nine months. Over time the 13th-month stops feeling like a bonus and starts feeling like a delayed slice of base salary. That’s not necessarily a problem — but you should know that’s what you’ve designed, because the bonus is now anchoring expectations as a guarantee rather than a reward.

Best fit: companies under roughly 100 people where everyone knows everyone, companies where individual contribution is genuinely hard to isolate, and companies that explicitly value team cohesion over individual differentiation. 

The pure performance bonus

Variable by individual or team KPI. Can pay out at zero in a bad year, or 200% of target in a great one. Calculated against a written formula or scorecard that’s hopefully in the developer’s offer letter.

When this works, it works beautifully. Excellence is rewarded visibly. Compensation connects directly to outcomes. High performers feel seen by the system rather than waiting to be noticed by a manager. Underperformers get an unambiguous signal, which is occasionally what they actually need.

When this doesn’t work, it does real damage. The moment developers conclude that the KPI structure rewards things they can’t actually influence — sales numbers they had no part in, company metrics that depend on the strategy team and not the engineering team — the bonus becomes a frustration instead of a motivation. Worse, when the KPI structure gets gamed by people closer to leadership, the rest of the team notices fast, and trust takes a beating that’s hard to recover from. We have watched performance bonus systems destroy team morale at precisely the companies that thought they were investing in performance culture.

Best fit: companies above roughly 150 people where individual contribution is measurable, sales-adjacent engineering functions, and engineering organizations with genuinely mature OKR or scorecard practices. If you don’t have that maturity yet, this structure tends to do more harm than good.

The hybrid — half guaranteed, half performance-linked

The pattern we see most often at mature HTP companies in 2026. The annual bonus pool is split — typically half and half, sometimes 60/40 — between a guaranteed 13th-month component and a performance-linked component.

The guaranteed half provides the basis and lets the developer plan their year financially. The performance half rewards excellence without making the whole bonus feel like a lottery. People know what they’re guaranteed; they have something to play for above that.

This requires more administrative work and a lot more communication. The split has to be explicit in the offer letter. The performance criteria need to be written down and reviewed quarterly, not pulled together hastily in November. The payout has to actually happen on schedule — and at the agreed amount, not 60% of it because cash flow got tight in Q4. Companies that do this well retain noticeably better than companies on either pure structure.

Best fit: most growth-stage Belarusian IT companies, particularly product companies and HTP residents serving international clients.

Layer 3: The long-term piece — where retention past year three is decided

This is the layer most Belarusian companies underinvest in, and it’s the most consequential for keeping senior developers past year three. By year four, a developer without a long-term incentive line in their compensation has typically had multiple recruiter conversations, and the only question is which offer they accept.

Equity grants

You can run RSUs and stock options in Belarus. They’re not impossible, just a bit more involved than in Berlin or London. HTP residents have it easier because the regulatory framework was actually written with these instruments in mind. The mechanics aren’t quite as smooth as you’d get in Western Europe, but they’re workable, provided someone takes the setup seriously.

The trick is doing all the boring paperwork before the grant lands in the offer letter, not after. Vesting schedule, written down. Dilution mechanics, spelled out. Tax treatment is understood for the specific instrument you’re issuing, not the general concept of equity. The version that goes wrong is the one where someone tells the candidate, “We’ll sort the details later.” It almost always falls apart around month six. The developer asks for the documentation, finds out it doesn’t exist, and now they’re quietly re-reading every other promise in their offer letter, wondering what else wasn’t real.

Equity actually pays off at companies with a believable path to liquidity or a valuation that’s visibly moving in the right direction. If you’re a Belarusian IT services company without anything resembling an exit on the horizon, equity tends to oversell what it can actually deliver, and developers eventually do the math themselves. Usually, sooner than the people writing the offer letters realize.

Phantom stock

Tracks the value of equity without conveying actual shareholder rights. Pays out as cash at defined events — sale, IPO, scheduled vesting milestones.

Often this is the better fit for engineers who’d rather have a clean cash outcome at vesting events than navigate currency control mechanics around a future liquidity event. Administratively simpler. Sits more comfortably with the developer’s tax planning. Worth considering at companies where actual equity creates more friction than value.

Retention bonuses

Sometimes called loyalty bonuses in Belarusian HR practice. A defined cash amount that vests on tenure milestones — typically 12, 24, and 36 months. Increasingly used at senior+ levels as a direct response to outside recruitment pressure.

These work best when they’re public and structural, not negotiated quietly with individual developers. A retention bonus that becomes known across the team as something a few favoured engineers received does more harm than the bonus itself does good. If you’re going to use retention bonuses, put them in the published compensation framework where everyone can see them.

Layer 4: The non-cash stuff that decides most of the actual retention

From our placements, we hear consistently what developers say about why they’re considering a move — or why they accepted a previous one. The non-cash factors come up more often than the cash ones. By a meaningful margin.

Career progression that’s actually visible

A documented path from senior to staff to principal, with criteria, with timelines that match what actually happens. Most Belarusian IT companies say they have this. Most don’t, in any form a developer can navigate. The companies that genuinely do — published levelling, real criteria, promotions that happen on the published schedule — retain better than the companies that don’t. It’s not close.

L&D budget you can actually spend

Not just the number. The friction. A $1,500 budget with a one-step approval beats a $2,500 budget where the developer has to argue with finance over every conference ticket. The friction is what the developer remembers six months later — not the higher headline number.

Recognition that’s structural, not occasional

Public acknowledgement when something ships. Peer recognition systems. Technical leadership opportunities — chairing architecture reviews, mentoring juniors, representing the team externally. These are cheap to provide and significantly underused at most companies. The companies that get this right rarely have to ask why their senior developers stay.

Working conditions that are specific, not vague

Remote and hybrid clarity. Equipment quality at the senior tier. Real autonomy over working time. Companies that hedge on these — “we’re mostly remote” without specifying what that means in practice — quietly lose candidates to companies that are precise.

The team you’re being placed on

The single most cited reason senior developers accept an offer is who they’d be working with. Strong engineers want strong engineering teammates. Companies with a reputation for engineering quality recruit on that reputation; companies without one are paying a hidden premium they don’t see in the numbers. This is also why deliberate team-building matters as much as raw headcount growth.

FAQ

How do we structure performance bonuses without making them feel arbitrary?

Three things, all of them required, not optional. Write the criteria down in advance — ideally in the offer letter. Review the scorecard quarterly so developers can adjust before year-end. Make sure the criteria depend on outcomes the developer can actually influence with their work, not on company-level outcomes they have no leverage over. If you can’t honestly tick all three boxes, default to 13th-month for now and come back to performance bonuses when your scorecard maturity catches up.

Are stock options or phantom stock administrable for Belarusian developers?

Yes, with structure. The HTP framework explicitly accommodates equity-style instruments, which makes residents’ lives easier. The mechanics need to be set up before the grant goes out, not patched together afterward. For developers outside HTP, phantom stock or cash-based long-term incentives are usually administratively simpler. Get advice on the specific structure before promising anything in writing — “placeholder equity” is one of the most common offer-letter mistakes we see.

How often should we do salary reviews?

Annual is the baseline. The better employers in 2026 are doing semiannual reviews for everyone and quarterly conversations with high performers. The cadence matters less than the consistency, though. A slipped review damages trust more than a smaller raise. Whatever cadence you pick, hit it on schedule. Every time.

How do we keep developers from leaving for a 10% higher offer?

Usually, by making sure the structure above the base is genuinely strong. A developer who’s leaving for 10% more on base alone is almost always a developer who didn’t have a long-term incentive they cared about, didn’t have a clear progression path, and didn’t feel like this year’s bonus was going to mean anything. Fix those three, and the 10% offer doesn’t get taken. Don’t fix them, and you’ll eventually lose that developer even if you match the offer, because what they’re actually leaving isn’t the salary.

The takeaway

Salary parity is mostly solved. The structural work has moved upstream, to the layers above the base. Companies that design those layers carefully retain developers through year three and beyond. Companies that don’t end up paying market-rate salaries with above-market attrition, which is the worst possible combination of outcomes — you’re paying what the good companies pay, and you’re getting what the worst companies get.

We work with Belarusian IT companies on both recruitment and compensation strategy through HR consulting. To anchor your structure, our IT salary research provides the actual compensation developers in your segment are being paid. For a conversation about your specific structure — what’s working, what’s not, where the next adjustment should land — contact us.

How to Build an Employer Brand on LinkedIn That Actually Attracts Senior Belarusian IT Talent

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 Outsourcing vs IT Outstaffing in Belarus: A Decision Framework for Foreign Companies

Roughly half the foreign companies who contact us asking for “outsourcing in Belarus” actually need outstaffing. A smaller but expensive subset asks for “outstaffing” when what they really want is fixed-price project delivery. The two models look almost identical from the outside — Belarusian developers working on your software, paid in BYN, billed to you in EUR or USD — but underneath, they’re different products. They split differently on who runs the work, who carries IP risk, who absorbs staffing churn, and what happens the morning a developer decides this isn’t for them anymore.

Pick the wrong one and you’ll feel it within the first three months. Pick the right one and you’ll wonder why nobody explained it this way before. So here’s the framework we walk new clients through before they sign anything.

The two models, in a paragraph each

IT Outsourcing

You hand a piece of work to a Belarusian provider — a project, a feature, a discrete deliverable. The provider assembles their own team, manages it, and ships you the result. You don’t choose the developers (or you choose them once at the start and then lose visibility). You pay for the deliverable, usually as a fixed-price contract or time-and-materials with a project manager sitting in the middle. The provider owns the team and the process. Your relationship is with the company, not the people doing the work.

IT Outstaffing

You select specific developers — interview them, approve them — and they then work exclusively for you, embedded in your team, taking instructions from you directly. They stay legally employed by the Belarusian agency (in our case, through our HTP-resident company), so you don’t deal with payroll, taxes, contracts, or labor inspectorate. You manage the work day-to-day; we manage the employment. The closest mental model: “they’re on your team, on someone else’s payroll.”

Where the confusion comes from is no mystery. Both look like “IT services from Belarus,” both involve developers you don’t directly employ, and the marketing language used by global vendors blurs the line on purpose — outsourcing usually sells at a higher margin. A clean breakdown of the same distinction sits in this hiring guide on Recruiting.by if you want a second take.

Side-by-side: where the two diverge

The differences look small in marketing copy and large in practice. The table below is the version we use on calls — dense on purpose.

When outsourcing is genuinely the right answer

Let’s start here, because if we only sang the praises of outstaffing the post would lose credibility on the second paragraph. Outsourcing wins in three situations.

1. Genuinely fixed-scope projects

Migrate this database. Build this marketing site to these designs. Ship version 1 of this mobile app to these specs and hand over the source. If the work has a finish line and you don’t need ongoing iteration, paying for a managed deliverable is cleaner than running an embedded team you’ll have to shut down in three months. Belarus has a deep bench of providers who do this well.

2. Specialist work outside your in-house competence

You need three weeks of a security audit. You need a Solidity team to ship one smart-contract product. Hiring a full-time outstaffed senior for a three-week need is the wrong shape. Outsourcing it is the right shape — you pay for the outcome, not the people in the team.

3. No engineering management bandwidth on your side

If you literally cannot manage developers — no engineering manager, no tech lead, no product owner who can run standups — outstaffing won’t work. The model assumes you bring management. Outsourcing absorbs that for you. We’d rather tell you this upfront than watch the model collapse two months in.

When outstaffing is the right answer (which is more often than you’d think)

For everything outside the three scenarios above — and “everything else” covers most foreign companies hiring developers in Belarus — outstaffing is the better answer. Four reasons.

1. Ongoing product development

Your product will keep evolving. The team needs to learn your codebase, your customers, your engineering culture. Outstaffing builds institutional knowledge in your team because it’s the same people, month after month. Outsourcing rotates people away from it — they finish your project and move to the next client, taking the context with them.

2. You want to control hiring and culture

You interview every developer. You decide who’s on your team. You’re not delegating that to a provider’s PM. This is the most common reason mature engineering teams pick outstaffing — control. Hiring is a strategic decision, and most CTOs aren’t comfortable handing it off.

3. Your scope will change

Software scope always changes. Outstaffing absorbs that for free because the team is yours — you re-prioritize the backlog and the team executes. Outsourcing fights it because every change goes through a contract amendment, a re-scope, and usually a renegotiation. Three scope changes in and you’ve spent more on contracts than on code.

4. You want HTP cost benefits visible in your invoice

This is the Belarus-specific point and it’s the one most global comparisons skip. When the outstaffing agency is HTP-resident, the social-contribution base is calculated against the country-average salary, not the developer’s actual paycheck. For a senior developer on $4,000/month, that’s a meaningful chunk of cost that disappears — and it shows up in your monthly fee. We run this through our own HTP-resident company at a flat €350/month service fee on top of payroll. Outsourcing buries the same benefit inside the provider’s margin; outstaffing surfaces it. Background on why this matters: outstaffing is on the approved HTP activity list, which is what makes the structure work.

The decision framework: six questions

Run through these in order. Each one narrows the answer. By the end you’ll know which model fits.

1. Is the work scope finite and locked, or ongoing? Finite → outsourcing in play. Ongoing → outstaffing.
2. Do you want to interview and choose the specific developers? Yes → outstaffing. No, don’t care → outsourcing fine.
3. Do you have an engineering manager or tech lead who can run the team day-to-day? Yes → outstaffing works. No → outsourcing, or hire that person before going further.
4. How sensitive is the IP? High → outstaffing through an HTP-resident agency gives you a cleaner IP chain and a stable team. Outsourcing can work too, but only with a bulletproof contract.
5. How much will the scope change in the next six months? A lot → outstaffing absorbs it for free. Almost none → outsourcing is fine.
6. What’s your budget visibility? “Fixed price for the whole project” → outsourcing. “Predictable monthly burn per developer” → outstaffing.

Four out of six pointing the same way is your answer. If it’s split three-three, that’s a sign the work itself is two different things — split it.

Why the choice matters more in Belarus than elsewhere

This is where the Belarus angle shows up properly. Three points that don’t apply (or apply less) in other CIS jurisdictions.

HTP changes the math on outstaffing

Already covered above, but worth repeating because it’s the structural advantage. The HTP regime — extended by Decree No. 8 to 2049 — gives resident companies a reduced social-contribution base and exemption from corporate profit tax. That benefit can flow through to your invoice in an outstaffing arrangement, or it can sit inside someone else’s margin in an outsourcing arrangement. Same developer, different cost to you.

Belarusian Labor Code is restrictive on the employer side

Termination requires grounds listed in Article 42. Severance for dismissals without cause is typically three months. Protected categories — pregnant employees, employees on maternity or childcare leave — can’t be dismissed at all in most circumstances. Both models externalize this risk away from you, but outstaffing makes the cost transparent (the agency is the legal employer; the cost shows up in the monthly fee). Outsourcing buries it inside a fixed price you can’t audit.

English fluency is strong, but management still matters

Both models work in English in Belarus — most senior engineers operate comfortably at B2 or above. But outstaffing benefits more from this because you’re managing the developer directly, not through a translator-PM. Current market data on the senior IT bench: average salaries run between $1,600 and $1,900 at mid-level with seniors well above that. Belarus is also still ranked among the top 30 global IT outsourcing destinations — meaningful depth, especially in backend, mobile, and game development. For broader market context, TechBehemoths’ Belarus overview puts the IT sector at roughly 6.1% of GDP.

A worked example

Abstract framework, meet concrete numbers. The case below is composite — based on the kind of inquiry we field weekly — but the numbers are realistic for May 2026.

A SaaS company in Berlin needs three engineers — a senior backend developer, a mid-level frontend developer, and a QA engineer — to extend their product. They expect the team to work on the product for at least 18 months and the roadmap is going to shift several times along the way.

Outsourced via a managed Belarus delivery shop: roughly €8,000–€12,000/month per engineer including the PM markup and provider margin, plus 2–3 weeks of scoping and contract negotiation up front, plus a project manager sitting between you and the developers, plus a contract amendment every time the roadmap shifts. The amendments aren’t free — usually 5–10% legal and renegotiation overhead per change.

Outstaffed via an HTP-resident agency: developer salaries at market — a senior backend at roughly $3,500–$5,000 gross, a mid frontend at $2,500–$3,500, a QA at $2,000–$2,800 — plus the flat €350/month service fee per engineer. Onboarding runs 1–2 weeks from first interview to first day. Direct management. No PM markup. No margin on top.

For an 18-month engagement on an evolving product, the math isn’t close — and the difference grows the more the scope moves. Caveat: actual rates depend on stack, seniority, and timing, and the numbers above are illustrative rather than a quote. But the shape of the answer holds across most of the inquiries we see.

If you’re not sure which one fits

If you’ve read this and you’re still not sure which model fits your situation, the answer usually takes a 20-minute call. Tell us what the work looks like — scope, team, timeline, what you’ve already tried — and we’ll tell you the model. If it’s outsourcing, we’ll be honest and point you to a partner who delivers it well. If it’s outstaffing, that’s what we do, and we can have first CVs in your inbox within a week of signing. Get in touch, or browse the rest of our news section while you’re deciding.