Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Before 2018, it became mandatory for businesses to put in place measures to ensure privacy and maximum protection of personal data that pass through them. All companies within and outside the EU must abide by this law, i.e., the General Data Protection Regulation (GDPR), provided they'll be processing EU citizens' data. Because personal data flows between different businesses, every party involved in control, processing, or sub-processing must understand the requirements of the GDPR.
What's more, all parties must enter into a legal agreement known as the Data Process Agreement (DPA) to uphold the law's requirement. Read on as this article addresses what you should know about DPA.
Based on the European data protection law, European Union citizens' data can only be shared and processed by third parties outside the union if they enter into a process-regulating agreement known as the DPA. This legal document aims to ensure strict regulations of the terms and conditions of processing people's data.
In this agreement's scope, personal data is any information that can help identify a person, e.g., surname, first name, residential address, date of birth, etc.
As you can see, this information could easily compromise people's privacy or even safety. The GDPR, therefore, requires all involved parties, i.e., controllers, processors to enter the agreement before they start to share data. The essence is to establish the responsibility of each member that is signing the legal document. Another thing is that the DPA creates a limitation to liability. For example, if a controller and processor were in agreement, and there's a breach from the processor's side, the DPA has the potential to limit the controller's liability for that breach.
According to the requirement of Article 28(3), a DPA must have the following.
The Controller is the legal person, business, agency, or public authority, which by himself or in conjunction with other company or persons establishes and determines the purpose/condition of processing data.
This processor can also be a person, business, agency, or authority that undertakes processing data on behalf of the Controller based on the Controller's instruction. The processor and controllers are the ones directly involved in signing the DPA.
A sub-processor is technically a processor but doesn't sign the DPA directly with the Controller. However, sub-processors must also agree to the same clause that binds the processor in the DPA initially signed with the Controller. The sub-processor is usually a third party agency or business who has access to data through the processor.
As a tech business owner, outsourcing software development is a business move that allows you to transfer some or all of your tech company's software development operations to a third-party vendor or agency. This vendor could be in the same zip code as you; however, most tech companies engage outsourcing agencies or tech professionals from other locations of this world.
This move offers many advantages to hiring companies, such as the liberty to hire more talent due to higher exchange rates than the location of the vendor, time zone difference maximization, access to global talent, and more. The data controller here is the client, i.e., the bankroller, which could be you, the software project owner, outsourcing to an offshore client.
On the other hand, the data processor is the contractor or vendor, who processes the data on behalf of the controller/client according to established instructions. You could also be the contractor or vendor and decide to transfer data to a third party processor to get the job done. That third party company you outsourced is a sub-processor.
To get a picture of the controller/processor relationship, let's look at a typical software development project.
Assuming a customer based in Europe hires an outsourcing company to design a healthcare facility management app, this kind of project falls under the General Data Protection regulation because it will involve patients' records. Therefore, according to the regulation, the responsibility of how the European customer and outsourcing agency will protect the patients' data falls on the European company that wants the product made and the outsourcing company that needs the data to accomplish the tech product's design.
After signing a DPA with a European customer, the processor automatically and voluntarily becomes bound by the GDPR. If you are the processor, your data controller will let you know what you have to do and how to do it. Essentially, you'll have to follow your Controller organization's requirement, which is already stated in the DPA. If you outsource some of your operations to third party vendors or agencies you may likely transfer the Controller's data to, you'll need to bring them into the picture.
In recent times, there have been stories of breaches which isn't limited to the private sector only. Regulators have become more active in sensitizing the public about their rights regarding the safety of their data and organizations' role in ensuring this protection. Furthermore, because of the increase in global data usage and new technology developments, data protection has become more challenging. It can get tricky when data transfer occurs among multiple jurisdictions, especially when a cloud-based facility is in use.
Therefore, when a data controller wishes to outsource their data processing operation to a processing body, they must prove the processor can guarantee the protection of customers' private data. In software development, the type of software product isn't as vital seeing as the work dynamics usually involve the design of a new product or the maintenance of existing software. This aspect will often give outsourcing companies access to their clients' customer database.
Therefore, there is a need to establish how data is processed, stored, and utilized. Altogether, if you get into business with a company that fails at data protection and security compliance, you may cause unfavorable issues for your company, such as:
Here are some of the things to pay attention to when entering a DPA.
Take time with your DPA
Yes, a DPA might be cumbersome to create, it may even require investing extra resources and time, but once you get it right, it's all going to be worth it in the end. Processing and securing data is essential in complying with GDPR, and your DPA is what will ensure duties align with regulation. Now, incorrectly creating your DPA may be slightly similar to not signing it at all, as you may open your organization to potential risks. Altogether, aside from being a guide to all parties involved in processing peoples' data, DPAs can further help your organization improve in general security in terms of data handling.
No breach Guarantee
On the side of data controllers, one of the core concerns in signing a DPA is being sure the processor can provide sufficient guarantee that it will adequately protect the data they'll be receiving. Here's the thing with the GDPR, even if there's a data compromise from the processor's side, the Controller is not off the regulators' hook. Both parties may likely be accountable, meaning where the breach came from might be irrelevant. In that regard, controllers should only do business with processors with appropriate data safeguard protocols.
Consistency
As a Controller, you should ensure that the DPA prevents the data processor from using data for any other purpose other than what is in the agreement. Therefore, there must be agreement on the consistent use of data. In that regard, you'll do well to ensure the processor's DPA scope is less than the legal grounds your company initially established to process personal data.
Furthermore, keep open the possibility of periodically auditing your processor to ensure there is no derailment in the DPA/GDPR requirements.
Misinterpretation & ambiguities
Both controllers and processors have responsibilities. Therefore, you might want to eliminate any possibility of misinterpretation of roles by any processor you are hiring to handle data. Ambiguities usually leave room for misinterpretation, so it's best to be specific on every rule. For example, add a particular time limit expected to process data subject access requests and that all data needs deletion if the business relationship no longer exists between you both.
We hope you found this article useful. Here at Cloud Employee, we assist companies looking to hire dedicated offshore developers across many technologies. Talk to us, learn more how Cloud Employee works, or see our Developer Pricing Guide.
.png)
One of our recruitment officers will get in touch with you today!
