Is Bitrix24.ru legal to use in Moldova? GDPR, data transfers and Russian servers

A CRM is, almost always, the densest store of personal data a company owns: names, phone numbers, email addresses, conversation history, notes about a client's budget or family situation, documents the client uploaded. The question "where does this data physically end up?" is not a technical one but a legal one — and since 23 August 2026 it is asked in new terms in the Republic of Moldova.

What GDPR is, and which law applies in Moldova

"GDPR" is the everyday name of Regulation (EU) 2016/679, the act governing personal data protection in the European Union. Moldova is not an EU member state, so the GDPR does not apply here automatically simply because a company is registered in Chișinău.

What does apply is Law no. 195/2024 on the protection of personal data, adopted on 25 July 2024 and published in the Official Gazette no. 367–369 of 23 August 2024. The law states in its own opening text that it transposes Regulation (EU) 2016/679. Under art. 89(1) it enters into force 24 months after publication — that is, on 23 August 2026.

The practical consequence for a Moldovan business owner: the shape of the obligations is the one European companies already know — legal basis, transparency, security, records, a separate rulebook for transfers — but the text you cite in an inspection, a complaint or a contract is the national law, not the European regulation.

When the GDPR may apply to you as well

The GDPR can become applicable to a Moldovan organisation depending on what it does, not on where it is registered. Article 3 of the Regulation extends it to controllers outside the Union when they offer goods or services to people located in the EU/EEA, or monitor their behaviour. If you sell only in Moldova, this does not concern you. If you have clients in Romania, Germany or Italy, it is worth checking separately.

Symmetrically, Law no. 195/2024 has its own art. 3: it applies to a controller with no establishment in Moldova when that controller offers services to people located in Moldova or monitors their behaviour.

Two terms that recur throughout

• Controller — whoever decides why and how the data is processed. In our scenario: your company.
• Processor — whoever processes the data on the controller's behalf, under a contract. In our scenario: the CRM provider.

The distinction matters, because responsibility for choosing the provider and for the basis of the transfer stays, in the main, with the controller.

Where Bitrix24.ru stores your data

No inference is needed here: the answer is in the provider's own public documentation. The security FAQ on the Bitrix24.ru helpdesk states that all Bitrix24 user data — employee information, client information, documents and files — is stored in data centres located on the territory of the Russian Federation.

A second page on the same helpdesk, dedicated to the storage of personal data, names the infrastructure providers — АО «Корп Софт» and ООО «Цифровое облако» — with data-centre addresses in Moscow, and refers to Russian Federal Law no. 152-FZ on personal data.

The table summarises where the data goes. It does not say that one option is "compliant" and another is not: the third column only tells you whether the transfer rulebook has to be worked through.

What a cross-border transfer actually is

The plain version: as long as your customers' data stays processed in Moldova, you have the general rules of the law to follow. The moment that same data comes to be processed on a provider's infrastructure located in another state, an additional set of rules kicks in — Chapter V.

A concrete example. A real-estate agency in Chișinău keeps in its CRM, for each client:

• full name;
• phone number;
• email address;
• conversation history and the agent's notes;
• property preferences (district, number of rooms, floor);
• available budget and how the purchase will be financed;
• uploaded documents — copies of IDs, statements, contracts.

If the infrastructure receiving and holding this data sits in the Russian Federation, the processing is no longer purely local, carried out in Moldova. Nobody "sends" anything across a border by hand — the transfer happens through the very fact that the data is entered into a system hosted there.

The law does not define "transfer" separately. What it sets out, in art. 44(1), is the general principle: data undergoing processing or intended for processing after being transferred to another state may be transferred only if the conditions in Chapter V are complied with, including as regards onward transfers. The same provision states the purpose of the whole chapter: that the level of protection guaranteed by the law is not undermined.

The exception that simplifies the analysis considerably

Article 44(2) provides that this chapter does not apply to transfers to member states of the European Economic Area, and that no special authorisation is required for them. In other words: infrastructure in the EEA takes the discussion out of Chapter V. The rest of the law's obligations of course remain.

What the CNPDCP says about the Russian Federation

The national authority is the National Centre for Personal Data Protection (CNPDCP). Under art. 45 it is the Centre that decides whether a state ensures an adequate level of protection; the list is approved by decision and published. A transfer to a state on that list requires no special authorisation.

The criteria the Centre uses are listed in art. 45(2) and are instructive in themselves: the rule of law and respect for fundamental rights, the relevant legislation — including on national security and public authorities' access to personal data — the existence of an effectively functioning independent supervisory authority, the international commitments the state has entered into, and the European Commission's adequacy decisions. What is assessed, then, is the legal framework of the destination state, not the technical quality of the provider.

In its public materials, the CNPDCP has explicitly used the Russian Federation as an example of a state that does not ensure an adequate level of protection. In a notice addressed to the users of a ride-hailing app, the Centre refers to the "cross-border transfer of personal data to States which do not provide an adequate level of protection (such as, for example, the Russian Federation)". The same notice draws attention to platforms run by non-residents with servers outside the country, where state oversight is difficult and the individual's ability to exercise their rights is limited.

Is Bitrix24.ru banned in Moldova?

No. No provision of Law no. 195/2024 names Bitrix24.ru, and none prohibits a particular piece of software. The line "Bitrix24.ru is illegal in Moldova" is inaccurate, and we do not make it.

What can be said is something different and more nuanced: if you use Bitrix24.ru to process personal data, and that data ends up on the Russian infrastructure the provider describes, then you are in a transfer to another state and you need to be able to rely on one of the mechanisms in Chapter V:

• an adequacy decision issued by the Centre for the destination state (art. 45); or
• appropriate safeguards (art. 46) — standard data protection clauses approved by the Centre or adopted by the European Commission, binding corporate rules, an approved code of conduct or a certification mechanism, each accompanied by enforceable commitments; certain contractual clauses are available only with the Centre's authorisation; or
• a derogation for a specific situation (art. 49), which is the last resort, not the starting point.

In parallel, the obligations that have nothing to do with location still apply: the legal basis for processing (art. 5–6), informing the data subject (art. 13), the contract with the processor (art. 28), the record of processing activities — which expressly requires the categories of transfers and their legal basis (art. 30) — and security of processing (art. 32).

As for consequences, art. 88(2)(c) provides that infringing the transfer provisions (art. 44–49) is subject to fines of up to 2,000,000 lei or, in the case of an undertaking, up to 2% of total annual turnover for the preceding year, whichever is higher. That is what the text provides; we make no predictions about how or when it will be enforced.

Is the customer's consent enough?

The honest answer: it can sometimes be a valid basis, but a generic checkbox is not a universal solution and should not be treated as one.

Article 49(1)(a) permits a transfer where the data subject "has explicitly consented to the proposed transfer, after having been informed of the possible risks such transfers may entail for them due to the absence of an adequacy decision and appropriate safeguards". There are three conditions packed into one sentence, and they are easy to miss:

1. consent must be explicit, not inferred from a general "I agree to the processing of my data" tick;
2. it concerns the proposed transfer, so the client has to know the data goes to another state, and which one;
3. the person must be informed about the risks that arise precisely from the absence of an adequacy decision and safeguards.

On top of that, art. 49 is built as a derogation: you reach it in the absence of an adequacy decision (art. 45) and of appropriate safeguards (art. 46). And the general conditions for consent (art. 5–7) still hold — among them, that consent can be withdrawn. If a client withdraws consent, processing of that data in the system in question has to stop; it is worth establishing early whether that is operationally achievable.

There is also one case where consent is the least comfortable basis: employee data. A CRM holds not only clients but internal users too. In European practice, employee consent is treated with caution because of the imbalance of power in the employment relationship — an employee can hardly refuse freely. This is not a prohibition, but it is a serious reason not to build your whole compliance position on it.

What the company is actually risking

The risks are not only of the "fine" variety. They come in several kinds, and in practice they surface in roughly this order:

• Compliance. A transfer with no identified Chapter V mechanism remains a transfer without a basis. This is not something you fix with settings inside the platform.
• Transparency towards customers. Article 13 requires informing the data subject. If your privacy policy does not mention that data goes to another state, the information given is incomplete — whatever transfer mechanism you chose.
• Being unable to demonstrate. In an inspection the question is not "do you or do you not have a Russian CRM", but "show me the basis for the transfer and the documentation". The record of processing activities (art. 30) explicitly requires the categories of transfers and their legal basis. If the document does not exist, there is no answer.
• The sub-processor chain. The CRM provider has providers of its own — hosting, backup, technical support. The art. 28 contract has to cover that layer too; otherwise you do not know where the data goes at the second step.
• Security and jurisdiction. The platform's technical measures (encryption, 2FA, WAF, backups) are real and useful, but they answer a different question. The art. 45(2) criteria concern the legal framework of the state, including public authorities' access to data. A system can be technically well secured and, at the same time, sit in a jurisdiction that the adequacy assessment treats differently.
• Documentation and audit. Without records, a sound analysis carried out in the IT director's head cannot possibly be demonstrated two years later.
• Trust and reputation. Not a legal risk, but a real one: for B2B clients, EU partners and procurement processes, "where is our data held" turns up in vendor questionnaires more and more often.

What to check if you already use Bitrix24.ru

The list below does not replace legal analysis, but it puts the questions in the right order. It can be worked through internally, in a single working session, before bringing in an adviser.

1. Inventory the personal data in the CRM. Which fields actually hold data about people — clients, contacts at partner companies, employees, candidates. Include attached files and the content of conversations.
2. Identify the exact edition and zone. An account on bitrix24.ru, on a European zone, on bitrix24.com, or a self-hosted installation? Check the portal address, not your memory.
3. Establish where the data is physically hosted. The provider's documentation for that zone is the starting point; save the page, with the date.
4. Identify the legal entities involved. Who is the counterparty in the contract, who operates the infrastructure, under which jurisdiction.
5. Re-read the contract and the data processing agreement. Is there an agreement meeting the requirements of art. 28? What does it say about the location of processing?
6. Name the transfer mechanism. Adequacy decision, appropriate safeguards or derogation — and write down which. If it cannot be named, that is the main finding of the exercise.
7. Check your privacy notices. Do the customer privacy policy and the employee notice mention the transfer and the destination state?
8. Map the sub-processors. Who else has access — hosting, backup, support, integrations, marketplace apps.
9. Review retention periods. How long inactive contacts and old files stay in the system. Data you no longer need is the cheapest risk to remove.
10. Test export and deletion. Can you extract the data in full and delete it on request within a reasonable time? Run the test, do not assume.
11. Assess a migration. If infrastructure in Moldova or the EEA would reduce the risk, what would moving cost and how long would it take.
12. Document the assessment. Dated, with the sources consulted and the decision taken. This is the document that counts in an inspection.

Alternatives from a data-location standpoint

This section is about where the data sits, not about which vendor is better. The usual options:

• Infrastructure in the Republic of Moldova. Processing stays local and the Chapter V discussion never opens.
• Infrastructure in the European Economic Area. Under art. 44(2), Chapter V does not apply to those transfers.
• A CRM installed on your own infrastructure (self-hosted), where location and access are controlled by the company.
• A provider able to specify contractually the storage location, the sub-processors and how processing is carried out — useful whatever the specific answer turns out to be.

At Bsmart we implement and configure Bitrix24 and we build custom CRMs, so we are not a neutral observer — all the more reason to say that the right choice depends on your data, not on our preference. If the conversation is about where the data ends up, it belongs before the migration, not after. More on our CRM implementation and custom CRM pages.

Conclusion

The problem is not the name Bitrix24. The problem is what data is sent, where it ends up, who processes it, and under which legal mechanism.

A Moldovan controller who can answer those four questions, in writing and with documents, is in a solid position whatever platform they use. One who cannot has the same problem after migrating somewhere else tomorrow — because what stays undocumented is the analysis, not the vendor.

Official sources

1. Law no. 195/2024 on the protection of personal data — published text (legis.md). Chapter V, art. 44–49; art. 88(2); art. 89(1).
2. CNPDCP — Transfer of personal data.
3. CNPDCP — Recommendations and guidelines.
4. CNPDCP — To the attention of Yandex Go users, where the wording on states that do not ensure an adequate level of protection appears.
5. Bitrix24 — Bitrix24 and the storage of personal data (official helpdesk, in Russian).
6. Bitrix24 — Security FAQ (official helpdesk, in Russian).
7. Bitrix24 — GDPR, for the domain zones hosted in the EU and in the United States.
8. Regulation (EU) 2016/679 (GDPR) — EUR-Lex.

Legislation and the authority's materials can change. The information here was verified on 31 August 2026.

This material is provided for information only and does not constitute legal advice. How data protection law applies depends on the specific circumstances of each organisation.