The GDPR requires organizations that process personal data in the European Economic Area (EEA) to put personal data transfers to third countries under specific data protection safeguards. This ensures that personal data is protected to a similar or higher standard, regardless of where it goes. The EEA includes all EU countries and some non-EU countries including Iceland, Liechtenstein, and Norway. GDPR permits data transfers to third countries on the basis of a data transfer tool. Data transfer tools include:
- An adequacy decision: The European Commission decided that the third country ensures an adequate level of data protection (the full list is available here).
- Standard Contractual Clauses (SCC): Your organization and the entity in a third country signed the SCCs for international transfers adopted by the Commission.
- Binding Corporate Rules (BCR): You transfer data to a parent company with which you signed BCRs approved by European Data Protection Authorities.
Long story short: you must map personal data transfers out of the EEA and ensure you have a lawful basis for each, otherwise you risk a GDPR fine. Mapping cross-border data transfers can be a headache in organizations with complex engineering architecture and dozens of third-party integrations. Below are a few simple steps to help you protect your organization against non-compliance with GDPR.
Disclaimer: this article exclusively focuses on data transfers for the product you build.
Catalog internal services and third-party dependencies
First, get visibility over your applications, services, dependencies, and data storage systems. Document their hosting location—where, geographically, they store the data. If your codebase is still relatively small, you can dig into it manually and document everything in a spreadsheet. Set up a process to have your engineering team document new components and dependencies consistently. Train them regularly and make sure it’s part of onboarding new engineers. You need your engineering team to be aware of the data security and privacy risks that affect your software. This will make your job much easier as you scale. Culture first!
Then, automate with tools as you grow. Consistent visibility over your applications and databases can be time-consuming for companies with hundreds of engineers, microservices, and third-party integrations. Implement automated detection of components and dependencies of your technology stack as early as possible in your software development lifecycle. Your goal is to identify components hosted out of EEA proactively.
Map personal data flows to components hosted out of the EEA
Now that you know which components are outside the EEA, you need to identify which of them you are sending personal data. Start with periodic reviews with your product and engineering teams in the form of surveys or on-site meetings. You should specifically document:
- lawful basis for data processing
- data subject
- data type (e.g., email, social security number)
- data category (e.g., personal, health, or cardholder data)
- data sensitivity
Data mapping quickly becomes tedious when you are rapidly growing. Periodic reviews are not enough to keep up with the pace of development, and international data transfers can go unnoticed for weeks. You will likely seek to automate your data detection and classification capabilities. Implement data mapping early in your software development lifecycle to identify cross-border personal data flows and assess risk before releasing to production.
Identify your data transfer tools
You must document the data transfer tool you rely on for each personal data transfer out of the EEA. You should involve your privacy team at this step. If there is an adequacy decision with the third country, you should document it. If not, you’ll have to review and document the contractual documentation (like the SCCs or BCRs) that serve as the data transfer tool. SCCs are often part of the Data Protection Agreement you signed with your providers. That’s where it can get legal-ish and surely the expertise of your privacy team will be of great help.
It is also key to monitor the privacy landscape to catch evolutions of data regulations. For instance, there was an important update regarding SCCs in 2021: The European Commission published new SCCs that took effect on June 27, 2021. The old SCCS can’t be used for new contracts, and existing data transfers relying on the old SCCs must move over to the new SCCs by December 27, 2022. This might involve legal back and forth with your third-party providers.
Assess your data transfer tools
The privacy team needs to regularly assess if there is anything in the law of the third country that hinder the effectiveness of the safeguards of the transfer tool you are relying on. Specifically, they should have a look at laws laying down requirements to disclose personal data to public authorities, like surveillance laws. If such laws imply that the safeguard of your data transfer tool are not effective, you may decide to either:
- Stop the transfer.
- Adopt supplementary measures that ensure a level of data protection equivalent to that guaranteed in the EEA.
For instance, the U.S. Foreign Intelligence Surveillance Act (FISA) does not respect the minimum safeguards. So you should assess whether or not your data transfers to the U.S. fall within its scope. The European Data Protection Board provides more detailed instructions on how to conduct your data transfer assessment.
Monitor data transfers continuously
Ultimately, your goal is to catch any personal data transfers out of EEA without a reliable data transfer tool as soon as possible. When that happens, you should either get one—for instance, by signing SCCs with your provider—or stop transferring data. Bearer helps security and privacy teams at fast-growing tech companies identify international data transfer risks automatically across the entire software development lifecycle. This means you can prevent unauthorized data transfers and comply with GDPR easily.
