Russian law mandates data controllers store and update data collected from Russian citizens using Russian servers. Not only is this obligation technically complicated and often costly from the business perspective, but it is also a headache for the data protection officer. After all, keeping a portion of your user database located outside of the EU in a country that is not deemed adequate under Article 45 of the EU General Data Protection Regulation may conflict with data minimization and may negatively affect your legitimate assessments, etcetera.
The article aims to establish storage of an encrypted instance of the database in Russia without access to the decryption key as a strategy that would be in formal compliance with Russian personal data law while maintaining a high level of protection of data subject's rights and interests. The analysis may also be handy for designing supplementary measures to ensure the validity of the standard contractual clauses with a local hosting provider considering the “Schrems II” decision.
A brief overview of Russian data localization requirements
In September 2015, Russian personal data law made it mandatory for data controllers to store data collected from Russian citizens using databases located in Russia. For ease of reference, we will refer to this requirement as localization going forward.
With just these few lines of text in the law, a whole new area of expertise was born. At the time when the localization requirements were signed into law, many argued that it was a response to the Crimea-linked sanctions by the U.S. and EU. Namely, by forcing companies to keep Russian data locally, the Legislature aimed to provide more stability to the Russian segment of the internet in case communications were blocked (though none could state what good a database would do without the services/websites needed to handle it).
The succinct wording of the law, as well as lack of clarity around the purpose it aims to achieve, created a whole bunch of uncertainty. It was unclear whether localization required the database of Russian citizens is located solely in Russia or if a copy would be sufficient.
However, local regulator Roskomnadzor tasked with enforcing localization was quick to share its position with respect to some of the hotly debated questions. In the following years, certain aspects of localization were also clarified in the official guidance of the Ministry of Communications and by Roskomnadozor’s own commentary regarding the localization law.
In accordance with these oral clarifications of the data protection authority and the written guidance, the main principle that should be complied with is that the database in Russia shall at all times contain more or equal data as the databases abroad. Consequently, writing data directly to a foreign server and mirroring the changes back to Russia is not an option because there would be a lag of fractions of a second between the two events.
On the flip side, localization requirements only apply to data collected from Russian citizens, meaning it does not concern data generated server-side. For example, if you were to purchase a widget on an e-commerce website, the delivery address you fill in would be deemed collected and therefore subject to storage in Russia, while subsequent updates to the delivery-tracking status would be outside of scope.
Since its entry into force, the localization requirements have claimed at least one major victim — LinkedIn, which has been blocked in Russia since 2016. After this enforcement, local and international companies took localization more seriously. An additional reason to not ignore localization was introduced by parliament in December 2019 in the form of fines of up to $77,000 for the first violation and up to $231,000 for subsequent violations. In recent years, the DPA demanded answers on localization compliance from Twitter and Facebook, although this is still an ongoing matter.
Problems associated with localization
Compliance with localization has always been a tough nut to crack. Because the above-mentioned guidance only provides for the result it wishes to achieve, the particular architecture to do so is up to the controller to decide. The solutions proposed have a slew of problems that we briefly discuss below.
Technical issues
Many choose to have a local production database located in Russia. This is obviously a giant investment and puts a significant strain on internal resources of the controller and is a heavy financial burden.
This option is complicated for a variety of reasons. Among others, AWS does not currently have a local server facility — meaning, it is not possible to simply clone your production environment to a new location. Serverless architecture solutions are also not widely adopted among Russian hosting providers, which translates into controllers having to manage the servers they rent. In turn, this makes it more difficult to sync the various production environments you now have for different locales.
Another widely discussed option is to have a proxy service intercept all traffic coming from Russian citizens and write the personal data to a local database before it leaves the country and ends up in your main production environment. While this is generally less expensive to run in comparison to the first option, it can add significant overhead to the response time for service in Russia. It may take some time and effort to convince the regulator that the architecture is not a circumvention of the requirements.
Also, worth mentioning is the localization law does not make any exceptions for cookies and other collections of data that is typically done front end side. From a formal perspective, the metrics you would collect through pixels, beacons and JS scripts injected into your page are also subject to localization.
Privacy considerations
Of course, trouble does not end on the technical side. From the privacy perspective side and in terms of compatibility with GDPR, Russia is quite tricky.
First, Russia is not deemed adequate by the EU Commission for purposes of data transfer outside of the European Economic Area despite the fact that Russia has signed and ratified Convention 108. This is, in particular, because the Russian DPA is not formally independent, but subordinate to the Ministry of Digital Development, Communications and Mass Media.
While the local personal data law is somewhat reminiscent of the EU Data Protection Directive, there are ample reasons to regard that storage of data in Russia poses an additional risk for data subject’s rights and freedoms in comparison to the EU.
As detailed at length in the Russian Federation chapter of the "European Essential Guarantees Guide," Russian investigations law does not fully meet the level of guarantees afforded by European law. Perhaps even more relevant to the discussion at hand, the law mandates (part of the so-called Yarovaya package) that communications providers store the traffic they transmit for a set period of time and disclose it to Russian enforcement agencies upon request.
Such a regulatory landscape may negatively affect the assessments that privacy professionals conduct when considering the risks posed to data subjects. For example, this may make it necessary to further shorten retention periods for legitimate interest assessments, introduce supplementary measures for data transfers, etcetera.
Benefits of encryption
What is important to understand with respect to Russian personal data law and the localization requirements is that enforcement is driven by the regulator and its interpretations. As Roskomnadozor can be formalistic at times, this creates both problems (e.g., the rule prohibiting to first write data to a foreign database because of the less-than-second lags) and opportunities.
Roskomnadzor has been consistent in its position that applying security measures does not change the nature of the underlying data. For example, it has repeatedly confirmed that hashing is only a security measure and does not render the data anonymized. By this logic and from a formal reading of the law, any personal data that is stored in an encrypted format still constitutes personal data for purposes of personal data law and, in particular, localization requirements.
At the same time, there are no requirements either in the law or in the implementation acts that the controller shall present the DPA decryption keys during an audit. The only exception to this rule are controllers who had previously registered with the local DPA in a special register for those disseminating information.
This theoretically opens the possibility to implement an architecture that relies on end-to-end encryption where the local database stores encrypted bits of traffic without a key to decipher it. Even if the hosting provider were to grant access to such a database to the enforcement authorities, it would present little to no value to them due to the cost associated with having to break the encryption.
Such a setup can be regarded as an additional guarantee for purposes of assessing the data subject’s risks under the GDPR and would thereby alleviate at least some of the concerns raised in the earlier section of this article.
It is important to note that the proposed solution is not without risk and should be thoroughly considered before implementation. It is impossible to exclude that the courts would side with the regulator in that the controller was not able to demonstrate one’s compliance to the regulator’s satisfaction and should, therefore, be fined. It is also worth noting encryption regulations are fairly opaque in Russia and professional legal advice should be sought before implementing it.
However, from the perspective of the protection of people’s rights, more security measures are certainly better than less. We at RPPA side with the idea that effective privacy shall not be undermined for purposes of demonstrating compliance.
Head of Authority Communication Direction Vadim Perevalov and RPPA co-founder Alexey Muntyan contributed to this article.
Photo by Irina Grotkjaer on Unsplash
