Re: [gnso-dataprotection-thickwhois] Conflicts between Whois escrow requirements and data protection laws
All, I enquired with my colleague Mike Zupke,Director, Registrar Programs about this case and he shared the following with me: ICANN had a couple registrars enroll in the RDE service last year with a Third Party Provider (TPP) of escrow services (i.e., not Iron Mountain) as a way to comply with a fairly new Russian privacy law. This sort of arrangement is consistent with all RDE requirements, and in fact, is explicitly permitted in the RAA. Similar arrangements have been made on occasion before (but for unrelated reasons). There is no difference in the substance or type of data that gets escrowed by these registrars. The issue of Russian law was raised by the registrars themselves, so I don't have all of the details, but my understanding is that the new Russian privacy law requires companies who hold personal data to get permission from their customers before using it in certain ways. The TPP arrangement was proposed by the registrars to address this requirement. There may have been other alternatives available but this was the path they chose. In any event, ICANN did not issue a waiver or exemption to the registrars involved. We did agree that, if we have to release the data because of registrar termination, we'd give preference to potential gaining registrars who could comply with that Russian law. I hope that helps. Please let me know if you need additional information. Thanks. With best regards, Marika On 07/02/13 21:27, "Alan Greenberg" <alan.greenberg@xxxxxxxxx> wrote: > > It would be rather useful to know if they have a > similar problem just registering names with .org > or other thick registries. Is the sending of that > data subject to the same rules as we are discussing here, or somehow > different? > > Alan > > At 07/02/2013 02:52 PM, Don Blumenthal wrote: > >> Shared for possible relevance. >> >> I had correspondence with Maxim Alzoba from >> FAITID on another matter and Whois conflicts >> came up. FAITID apparently negotiated non >> standard escrow language because of problems >> with Russian law after Centrohost received an ICANN breach notice. >> >> Here's his summary of what happened. The >> specific language differences are confidential. >> >> =========== >> >> 1. >> 15sep2010 >> Registrator Centrohost IANA#1426 (now it changed >> name to Registrar R01) received warning on data escrow >> (that it must execute data escrow addendum to >> ICANN registrar contract(RAA 2001 at that moment of time) >> - RDE agreement no later than in two months (by >> 15oct 2010) and start uploads no later than in three months (15 dec2010)) >> >> 2. our legal dept read through the RDE agreement >> and found that it will force us to breach russian legislation on >> personal data protection due to two reasons : >> >> 2.1. almost impossible to find a single russian >> company in the Data Escrow business (TPP (Third Party Provider) requirements >> of non-affiliation with the industry, 250k USD >> of liquid assets + 10 years of business ..) in Russia ... >> (we found the way to comply in this bit after >> few months - NCC Group , one of their UK legal >> bodies ... which is UK company and falls under the smae >> Data Protection EU directive) >> >> 2.2. beneficiary of the data could be anyone (and under Russian 152-FZ and >> Convention on protection of the rights of >> individuals in the automated processing of the >> personal data from January, 28th, 1981 ETS ¹ >> 108we should use only countries which used >> "adequate means to ensure security" >> >> - so we requested a guidance from our regulator on what should we do >> >> the reason to ask was this: breach of personal >> data protection russian laws in cases where >100k records involved could >> lead CEO of the russian company to 5 years term >> (it sounds horrible, but that never happens in real life) >> >> 3. regulator issued a letter saying that: >> 3.1. these countries mentioned are - only those which ratified 95/46/EC >> 3.2 we have to ensure that the priority order of >> data beneficiaries are ... russian personal data >> operators ICANN accredited as registrars >> , EU (95/46/EC countries) ICANN accredited >> registrars [ the second tier was negotiated with >> the regulator, since the reference was to 95/46/EC] >> also the letter had reference to >> Convention on protection of the rights of >> individuals in the automated processing of the >> personal data from January, 28th, 1981 ETS ¹ 108 >> (cross border transfer of personal data) >> >> 4. tried to negotiate with ICANN / Iron Mountain - but failed ... >> >> 5. 12 January 2011 we received NOTICE OF BREACH >> OF REGISTRAR ACCREDITATION AGREEMENT >> https://www.icann.org/en/news/correspondence/burnette-to-smekaeva-12jan11-en >> >> 5.1 we found temporary workaround - uploaded all >> data of non-residents and resident & non resident companies >> (non residents and legal bodies are not >> protected by the personal data law in russia) >> and did not upload data of resident private >> persons (luckily only 5% of all domains) >> >> 6. we engaged ICANN with all the facts we know and asked them >> ... were they still trying to force us to break local legislation ? >> >> 7. we started work with Tim Cole & NCC Group & ICANN legal >> which lead us to ultimately to "russian data escrow contract" >> >> 7.1 in which we are exempt from being forced to >> breach local legislation if anything ICANN invents is against russian law >> (in this contract or it's amendments) >> >> 7.2. we have priority list of beneficiaries >> (1tier - russian "personal data operators" who >> are also ICANN accredited registrars, >> 2nd tier (when all russians failed ) - any >> european (countries which ratified 95/46/EC) ICANN acredited registrars >> ) >> >> 7.3. data escrow operator is UK body and works >> under the same Personal data protection directive as we are >> 95/46/EC >> (Russia ratified it too) >> >> !!! in the end .... we managed to change somewhat like 20 or less >> lines of the text in the contract in only 2.5 months =] >> >> ========= >> >> Maxim will send me the relevant laws and regs. >> >> Don > > > Attachment:
smime.p7s
|