Third-party app plugins pose serious data risks. A report from Netskope shows 97% of Google Workspace users have authorized at least one third-party app access to their corporate Google account. This potentially exposes data to third parties due to scopes like "View and manage the files in your Google Drive."
In short, sharing data allows businesses to garner greater insight from user activity. Gartner loudly states that “Data Sharing Is a Business Necessity to Accelerate Digital Business”. So while we have established that it is a necessity for any digital business in today’s world, what does it look like in practice?
Some of the most common scenarios for sharing data are:
As you can see, we’ve all become used to handing over access to data in return for convenience. There are literally thousands of reasons to share data and it’s hard to imagine a company that is able to keep all of its data locked up; never mind willing not to share it.
However, sharing customer personal data comes with risk.
The two major areas of risk when sharing data are security and legal.
Security risks are associated with all kinds of data breaches that may happen when data transfer is poorly organized. Although this area of risk is already known, data breaches occur regularly.
Top-5 data breaches:
Read more to see how much they were fined and how the breaches happened
Legal risks are a relatively new phenomenon, but equally important given the large fines that we have seen in recent years. Fines aren’t the only cost of non-compliance, though. Consumers care about privacy, meaning a lax approach will lead to a loss of brand trust. Companies that find themselves in the papers for large data breaches have seen customers switching to competitors in their droves.
So all this means that you need to take care of who you share customer data with and put safeguards in place to mitigate the risks of sharing data with third parties. Let’s take a closer look at what you can do to shore up your data practices.
First of all, make sure you are using a secure channel. I strongly recommend you use encrypted communication when transmitting any data or when the data will pass through an untrusted network. This seems obvious, but not everyone does it.
Use a secure communication method such as Transport Layer Security (TLS) or a Virtual Private Network (VPN). This will provide assurance that the content of the communication cannot be understood if intercepted, provided the method is implemented correctly.
If you can’t make a secure data transmission channel, then you need to focus on the security of the data itself. You can do this by implementing application-level data encryption before transferring or data masking.
As a side note here, keep in mind that you are better off using a push model of interaction over the pull model for data sharing in channels. Push models are when you send data on demand to a third party upon request and there is no way someone could access the data directly. Pull is when they have access to your data as they wish.
Implementing a push model will help you mitigate the risks that someone could hack the API and gain access to all personal data that goes through it.
An obvious way to reduce risks when sharing data with third parties is to know exactly what data is actually transferred. Double-check that you are only sharing the minimum required data with third parties. For example, there is absolutely no need to share your customer phone numbers with notification platforms if you are using only email notifications.
Try to avoid batch requests. If you push the data (and you should be if you want to keep breach risk low!), try to send single entities instead of data bunches. By keeping requests as single entities you can flag when there are an abnormal amount of requests being made and put a stop to it.
“100 requests per day is normal and is most likely a person manually working with data, 100-150 times is above normal but could mean that the person is working very diligently, over 150 requests is suspicious and reason to think that it is not a person accessing the data, but rather a script or bot.”
10-step guide to getting your data security right
So, by creating a channel for data transfers and then only pushing data to third parties when necessary, you are already massively reducing risks, fencing off your data to stop anyone accessing it directly.
As I mentioned above, if the legal requirements on how you handle customer data were something that used to be worried about later, now they need to be built in from the beginning. For third-party data sharing, this means being aware of what you are required to do by law and what best practices you can follow to ensure there is no fall out with your customers later down the line.
First and foremost, before sharing any data with third parties, you need to have an agreement in place. The agreement should ensure confidentiality and data privacy.
You need to come to some kind of agreement on security measures that the third-party recipient applies.
For example, these measures could include:
Your privacy policy is a key document that covers the practices you employ and is how you tell your customers about what you do with their data.
Privacy legislation is cropping up all over the world and each jurisdiction has its own specific nature. It’s best to speak to your legal department to figure out which restrictions apply, but you must secure a legal basis for the transfer.
Last but not least: you need to monitor what data you actually transfer, asking yourself and checking whether there is any suspicious activity or things happening out of your control, for example. Only by controlling what happens in real-time, is it possible to assess the current risks.
As a general rule of thumb, you need to monitor:
If one API is being used by multiple consumers (i.e. multiple third parties), you want to know who these parties are.
You need to be monitoring for data access anomalies. For example, if you usually have 10 requests per data for personal data from a third party and this balloons to 10,000 on a certain day, this is a massive red flag.
You will want to know in advance if more or different sets of personal data is going to be transferred to third parties as a result of one of your developers making updates to the code. If you have your monitoring set right and the developer forgets to tell you, this should flag in any case and you can update the schema.
Checking data transfer schemas may help you understand what data is transferred. However, there are no guarantees that the text field with the name "additional_info" in your schema does not contain the customer’s address or credit card number. This is why you want to do monitoring in real time to analyze the data being transferred right now so that you can react rapidly.
The last thing you need to be tracking constantly is the sensitivity of data being transferred to third parties and making sure that they need this data to carry out the service that you employ them to do.
So, third parties have become a necessary (convenient) evil, but by using data channels, knowing what data you transfer to them, complying with the laws on data transfers to third parties, and by constantly monitoring the data you provide to them you can drastically reduce the risk of your customer personal data being exposed.
