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.