EU GDPR Schrems II Impact for CSPs

Raghu Ram Meda
12 min readSep 28, 2021

--

Introduction

In this article I explained the background of GDPR & Schrems II regulation and high level impact for CSPs with the effect of the recent regulation change laid out by Court of Justice of European Union (CJEU) in relation to PI data transfers outside of EU/EEA. Specifically, this article covers the impact for CSPs in case they are transferring the PI data (of their end customers or their employees who are EU individuals) outside EU/EEA as the existing Privacy Shield is invalidated in lieu of latest Schrems II regulation.

This is not an exhaustive analysis but will give a high level understanding of the regulation. I created a generic framework in this article which can be used by CSPs to address the impacts and comply to the principles of Schrems II regulation w.r.t PI data.

Basic Concepts of PI Data Management

PI Data Types

PI Data Processing

Any operation or set of operations performed on PI data is called as PI processing. It may or may not be by automated means such as

  • collection, recording & capturing
  • organizing, structuring, storage & classifying
  • altering, editing & removing
  • using, combining & analyzing
  • sharing, transferring & disclosing
  • accessing, seeing & viewing
  • erasing, deleting & destroying
  • copying, duplicating & replicating

Entities Involved in PI Data Processing of a CSP B2C Context

  • Data Controller: Entity who owns the data, determines the purpose and means of PI data processing, carries out such data processing, is responsible for such processing and is obliged to undertake certain personal data processing by specific applicable law. Eg. Telecom Service Provider who is collecting the end customer PI data (name, email, address, etc) and processes it to provide the required communication services to the end customer
  • Data Processor: Entity who processes the PI data on behalf of Controller and as per the instructions provided by the controller. Eg. The contractors, sub-contractors, vendors & partners who processes the end customers PI data (such as CRM COTS product, Cloud where PI data is stored and processed and the network using which the PI data is transferred) within the policies set by Telecom Service Provider.
  • Data Subject: is an individual to whom the personal data pertains. Eg. End customer who is consuming the services provided by telecom company.

Privacy Impact Assessment (PIA)

It is an analysis of how information is handled to ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy; to determine the risks and effects of the processing of information in identifiable form in an electronic information system; and to examine and evaluate protections and alternate processes for handling information to mitigate potential privacy concerns.

Privacy by Design

Implementing data protection from the beginning of the designing phase of a product or service, instead of an addition. In practice, it means that the system should only collect the data required for its functioning (data minimization), as well as limit the access to this data to the least amount of personal/services required for the processing.

GDPR Chapter V & Schrems II

GDPR Chapter 5 refers to the regulation related to the transfer of personal data to 3rd countries or international organizations outside EU/EEA. As per the recent CJEU ruling in July 2020, existing Privacy Shield is invalidated which will restrict the companies to transfer PI data to US and any other international organization outside EU/EEA without adhering to the new Schrems II regulation that comes into effect since Jul 2020.

As per the new Schrems II rule, CJEU clarified that the Personal Data transferred outside EU/EEA using SCCs (Standard Contractual Clauses) will be valid yet if and only if the SCCs afford a level of protection that is equivalent to the protection provided under GDPR.

In this respect, organizations which are using SCCs to transfer the data outside EU/EEA have to verify case-by-case whether the 3rd Country ensures an adequate level of protection that is essentially the same as that of GDPR.

The new SCCs concerning personal data transfers outside the EEA introduced by the CJEU in Section III of Schrems II, which is the need for the data exporter and data importer to carry out what has come to be known as a “Transfer Impact Assessment” in order to assess the risks of the transfer of personal data and, where necessary, define the supplementary measures whose implementation is necessary to adequately protect personal data.

Effectively, the latest CJEU’s Schrems II rule dictates the organizations to comply with GDPR Chapter 5 for the data transfers & processing outside EU/EEA in the form of new SCCs or otherwise comply with GDPR in its true definition itself.

Transfer Impact Assessment (TIA) of Schrems II

TIA is an explicit analysis defined in Schrems II which is to assess the risks and the effects of the transfer of personal data and, where necessary, define the supplementary measures whose implementation is necessary to adequately protect personal data.

The new SCCs of Schrems II clarify duties and responsibilities of the importer related to the carrying out of the Transfer Impact Assessment. The data exporter is by implication bound to draft the assessment but the data importer warrants that it has made its best efforts to provide the data exporter with relevant information and, jointly with the exporter, warrants that they have “no reason to believe” that the destination territory’s laws will cause the data importer to be unable to fulfill its commitments under the SCCs, both the importer and the exporter having assessed the specific circumstances of the transfer, the laws and practices of the third country of destination and any appropriate supplementary measure to be implemented. Therefore, the SCCs oblige the data importer to collaborate with the data exporter in carrying out the Transfer Impact Assessment, which is essential in order to meets the Schrems II requirements.

New SCCs also specified that the circumstances of the data transfer (listed below) should also be analysed and must be taken into account as part of TIA :

  • the length of the processing chain
  • the number of actors involved and the transmission channels used
  • intended onward transfers; the type of recipient
  • the purpose of processing
  • the categories and format of the transferred personal data
  • the economic sector in which the transfer occurs
  • the storage location of the data transferred

The specific circumstances of the transfer are also crucial to the choice of supplementary measures where the Transfer Impact Assessment finds that on their own, the combination of laws and practices of the destination country with the contractual, organizational and technical measures provided by the SCCs fails to guarantee an EU-equivalent level of protection of the personal data being transferred

Therefore, the TIA is not an assessment of the third country regulations, detached from any reference to the specific case, but, on the contrary, it is an assessment that strongly depends on the concrete features of the specific transfer of personal data in question.

Impact for CSPs with Schrems II

Typically, CSPs use COTS products or In-house Applications which will process the PI data as it is intended for the purpose of service/product that CSP is offering to the end customers. Many of those COTS products/Inhouse applications will be deployed as SaaS model or PaaS model or self-hosted or hybrid model using public clouds and also any existing on-premise infrastructure. Typically public clouds are used to leveraging the various benefits such as availability, flexibility, reliability and scalability while at the same time adopting the latest innovation, standards, best practices and new features that will come out of the box from public cloud provider services.

Scenarios that are affected by Schrems II for CSPs

  • public cloud data center regions/availability zones (either for Live sites or DR sites or both) that are in US, UK and any other international geography outside the EU/EEA boundary
  • underlying communication network hops which can reside outside EU/EEA
  • COTS product vendor who imports and does the PI data processing outside EU/EEA
  • IT partner who is the contractor/sub-contractor for ADMO and who does the PI data processing outside EU/EEA on behalf of COTS product vendor or CSP or both
  • Eventhough the data may be stored within EU/EEA but the Service Agents, Omni channel contact points, Opti channel contact points, Sales agents, etc. can access the PI data outside EU/EEA while providing the service to the end customers.
  • Many CSPs have some portion or all of their Contact Center or BPO Services performed outside of EU/EEA where the PI data is accessed outside EU/EEA eventhough it is stored within EU/EEA
  • CSPs would have outsourced/off-shored the IT & Technology (Application Development, Maintenance and Operations aka ADMO) to their IT partners who will have their teams/employees working outside EU/EEA and involved in processing of PI data of the EU individuals through automated/semi-automated means under the privacy policy compliance laid out by the CSP
  • Employees of CSP (sales agents/customer support agents/service team) who are involved in PI data processing would be working from remote locations temporarily or permanently outside EU/EEA due to flexible working model (eg. covid lockdowns, personal conditions, work choices, adhoc or on-demand work escalations during vacations, work meetings, partner workshops, authority meetings, etc)
  • Auditors of CSP (Security, Contractual, Obligations, etc) who will have their applications/processes/personnel perform PI data processing outside of EU/EEA
  • VPNs, Access Network, Partner Network, Broadcast Network, etc. use different network devices which can reside outside EU/EEA as part of the end-to-end communication path and they may carry the PI data of the EU individuals in transit eventhough the actual data processing happens within EU/EEA
  • CSPs will use Satellite communication path (eg. GPS locations while installing the network equipment at the end customer premise) while providing services to their end customers and that may involve transmitting of PI data and it is assumed it will fall under transfer of PI data outside EU/EEA geography
  • When using public clouds, CSPs are compelled to use regions outside the EU/EEA in case the desired feature/service is not available in EU/EEA region of the given public cloud but the product/feature has to be released to the market as per the business needs and customer expectations
  • When using public clouds, in some cases, CSPs will opt a region outside EU/EEA due to cost optimization and other reliability benefits and PI data may be transferred outside EU/EEA in those cases

There can be more such scenarios where the PI data of EU individuals is processed by different entities along the chain which may reside outside EU/EEA and hence it is the shared responsibility of all the entities involved in that particular PI data processing to ensure the PI data protection and also comply to all the necessary measures laid out by GDPR and Schrems II.

In current state, CSPs would be complying to Privacy Shield that was applicable before Schrems II regulation in case the PI data of their end customers and/or employees is transferred outside EU/EEA in lieu of services provided to them. Now, CSPs have to perform TIA and implement necessary supplement measures in order to comply with Schrems II regulation.

Public Clouds

Although all major public cloud providers confirms that their service terms will ultimately comply to GDPR and Schrems II, it is the responsibility of CSP and all other entities who are using public cloud and who are involved in PI data processing (i.e data exporter & importer aka data controller & data processor) to perform TIA as a mandatory step to analyse case-by-case of the particular PI data that is transferred outside EU/EEA and implement supplementary measures.

None of the Public Cloud service terms will include the Supplementary Measures to be implemented by Data Exporter and Data Importer when the PI data is transferred outside EU/EEA because it is not explicitly specified in the Schrems II regulation to comply.

Most importantly the choice of the Supplementary Measures will be subject to the TIA outcome conducted by data exporter and data importer depending on the combination of laws and practices of the destination country with the contractual, organizational and technical measures provided by the SCCs which should guarantee GDPR equivalent level of protection of the PI data that is being transferred.

AWS

AWS has included new SCCs in its Data Protection Addendum (DPA) which is in compliance with GDPR and Schrems II and DPA is part of AWS Service Terms implicitly and hence it is applied automatically if the customers and partners uses AWS.

Azure

Microsoft also complies to latest Schrems II requirements using SCCs while transferring the data outside of EU/EEA.

Uniquely, Microsoft has come up with EU Data Boundary feature by which it will emphasize its customers to store and process the PI data within EU/EEA only. Microsoft is taking additional steps to minimize the transfers of PI data outside of EU/EEA and it has a target period (by end of 2022) by which it will work with its customers to migrate the PI data into EU/EEA without extra charge or price increase.

Google

Google also complies to GDPR and Schrems II regulation by implementing its Data Protection & Security Terms with the customers using SCCs and/or Alternative Transfer Solution mechanism to enable the transfers outside EU/EEA in accordance with EU Data Protection law.

Enterprise Framework

It is highly recommended to develop the capabilities required for Privacy and Security as Enterprise and common platform capabilities rather than silo and fragmented implementations by different teams or organizations of the enterprise. As there will be legal, brand and financial implications for any security and privacy incidents, it requires strict & uniform compliance against regulatory policies across the product & technology portfolios of the enterprise. Hence it is always efficient and effective to have enterprise capabilities to promote reuse, standardization, alignment and consistent implementation of security and privacy across the enterprise in compliance with regulatory policies.

Security & Privacy capabilities should be developed as a Platform Product/Service so that

  • Centralized Collaboration and Standardized implementation will happen to align across the board in strict compliance with regulation & legal aspects
  • Consistent and Uniform solution will be available for all teams to use/reuse
  • Automated solution (Policy as Code/APIs/PaaS) can be developed easily to plug’n’play by all teams anytime and always and by default from beginning of the product design to final release to market.
  • Easy maintenance & management can be achieved while providing highly reliable and available solution for all teams
  • Continuous evolution will be possible with appropriate resource allocation, budget allocation and priority given to security and privacy aspects by default for all products and solutions
  • Easy to define strategy, alignment and emphasis by Business and Technology Leadership for the teams to adopt easily always
  • Easy to react to any unforeseen incidents and manage the appropriate steps and activities required to recover the PI data loss, answer the authorities, follow legal and penalty procedures, communicate the data subjects, modify/fix the issues immediately, etc.
  • Teams can focus their effort and time on the core business capabilities and products instead of getting immersed in regulatory, legal and compliance matters all the time for every product release.

Although it is maintained and managed as an enterprise platform product/service, leadership should enable the teams across the portfolios to continuously collaborate with enterprise security & privacy platform team to educate about the new features so that platform team will guide and suggest the best practices & standard implementations as required and if required enhance or modify the platform capability in compliance with regulation and at the same time allowing the product teams to design and deliver the features as required for business and end customers.

If it is implemented appropriately, the Enterprise Platform Product/Service model for Security & Privacy will enable autonomy for the teams while ensuring uniform alignment across the board in strict compliance to regulation and hence it becomes easy for the enterprises to manage and maintain the security & privacy aspects effectively.

Enterprise Capabilities for Privacy

The following picture illustrates the various capabilities required commonly across the board to manage and maintain Privacy for PI data in any given enterprise.

Continuous Compliance & Impact Assessment Framework

The following framework can be used in generic by the enterprises for TIA and determine the supplementary measures to be taken case-by-case of PI data when there is transfer outside EU/EEA.

References

--

--

Raghu Ram Meda
Raghu Ram Meda

Written by Raghu Ram Meda

Principal Enterprise Architect, Thought Leader, Domain Consultant & Technology Practioner

No responses yet