- Alexander Ermakov
- October 12, 2016
- 6850
Personal Data Protection Law: New Challenges in Russia for Storing ERP Database
More than a year has passed since this law entered into force and it is interesting as nobody yet understands how to apply that. Regardless numerous discussions, at the date this blog article is published, there are still unclear topics and no court practice in Russia. Awara IT Solutions, being a part of Awara, is closely related to this legal topic, as many of our customers have to deal with implications of this new law. I feel it would be reasonable to describe the problem and give few recommendations on solutions to avoid much risk.
According to this law, since September 01 2015, all personal data operators will be required to keep personal data of Russian citizens in Russia. Basically, it requires that databases that store personal data should be kept on the servers on the territory of Russia. One say that it has been introduced in order to protect personal data of Russian citizens from foreign “secret services”. Other say that it has been made in order to allow Russian authorities to have easier and quicker access to the data of companies, as it is much easier to do that on the territory of Russia than demand it from other country. Below is the explanation of the principles and suggested options of planning the architecture, if you plan to deploy ERP system for implementation in Russia.
What data are personal data?
Personal data refer to any information which allows identifying a person, including:
- Email address if it includes surname and company name
- Bank card number and CVC in certain cases
- In some cases, mobile phone number (classified as “sensitive” personal data)
For example:
- ivan.ivanov@post.com = personal data
- ivan@post.com not personal data
It should be noted that even if data do not allow definite identification, such data could still be classified as personal data under certain circumstances. Roskomnadzor (federal regulatory agency) is currently working on a definition of personal data by developing criteria for personal data. That is, contact persons of company, agreements, and even Active Directory user names are also a subject of that law.
Which companies will be subject to the new requirements of the law?
- Russian companies registered in Russia
- Foreign companies with representative offices and branches in Russia
- Other foreign companies if the performance of their activities is related to Russia and/or involves personal data of Russian nationals.
For example: If a Russian national employed by a Russian representative office is able to view and post information about him/herself in the career opportunities internal system of a global company and the server in which his/her personal data are stored is abroad, this company will in such case be in breach of personal data localization requirements in Russia.
What are the options for architecture of the solution?
Most of our customers are foreign companies, rolling out their customized solutions to Russia. Many of them desire to have one database for all the countries, storing and administering it in one place, somewhere in the headquarters. They should consider the implications of this new law, as they for sure will operate with personal data and need t consider the risks of storing that abroad. I see 4 major options of architecture (Sweden has been selected as a sample country only – it is valid for any other country outside Russia).
Under this option, the server that contains the database is located inside Russia. The database stores personal data, related to Russian citizens. It might be either:
- physical server, located in company’s premises
- physical server, moved to datacenter
- virtual space rented (e.g., Azure Pack provided in Russia)
This is the safest option in terms of Personal Data protection legislation.
Under this option, the database server is located outside Russia in head office in some other country. The sever can be either in some datacenter or database can be placed in Microsoft Azure, which does not assume any Russian location. The access to the database can be made from any territory, but the database contains personal data of Russian citizens.
This solution is the violation of Personal Data Protection legislation and should be avoided.
Most desired for all of our foreign customers :-). Under this option, the primary input of data is made to the database located outside Russia. However, there is a duplicate copy of the database that is located inside Russia (any location option). The more realtime the data exchange is between the databases, the least risk it contains in terms of Personal Data Protection legislation. In best case, the SQL should be setup in such a way that both databases are synchronized realtime. There should be always a possibility to access the database, stored in Russia, in case inspection would like to check it (meaning, not only the database should be available, but also the application server and client software).
However, this option still contains risk, because theoretically it can be interpreted as a violation since the primary input of data is made not to Russian database. Note that this topic is yet unclear and there is no any court practice or real samples of application of this law.
Under this option, the primary input of data is made in Russia, thus there is no risk in terms of violation of Personal Data Protection law. If there is a need to have the same data in common general server in headquarters, there is an automated routine to feed the server in headquarters with data; it can be done realtime as well or by schedule, e.g. once per night.
Summary
Basically, if you do not want to abuse the personal data protection law in Russia, you should have your primary data to be collected and stored in Russia, and you are allowed to have a copy abroad. There might be other options, but they are more risky. Note that court practice is yet missing.
Originally posted on Microsoft Dynamics NAV Community.