Data Processing Agreement Checklist for Software Development Outsourcing

Software product development is always dependent on information. Thus, it is one of the most crucial aspects to consider and secure, when it comes to the development itself. For instance, besides general information about the software product, its explanation, list of features, business logic or strategy, or any other data, which can be met in an SRS document, it also includes vulnerable or confidential information.

The situation becomes even more serious when it comes to hiring software development outsourcing companies. In this case, third parties will not only develop your software product, knowing possible vulnerabilities of the final result. Also, they will have to somehow describe and explain them to you, or your future development team. Clearly, this will happen in a face-to-face conversation. Nonetheless, usually, such information is shared in written form. This helps to better understand and return to some specific cases when needed.

This is why it is important not to underestimate the role of documents in software development, even if they are non-technical. Frankly speaking, such documents in software development and their creation can be considered a standalone and full-fledged process, which is as important as the development itself. Clearly, clients won’t analyze and test the software product, developed by a dedicated team, by themselves.

Eventually, it is clear, that the data circulation and sharing between both data controller and software development outsourcing company is a constant process, which also can include sharing confidential information. Here, we come to the need of securing the shared data. Additionally, it is not only a benefit, which helps to improve customer satisfaction but a requirement fixed at the level of law. For example, General Data Protection Regulation approved by European Union. This guideline requires companies to inform the users how they are going to use the information about the users, as well as giving them more control over this personal information and forbidding specific use purposes. Moreover, this law also includes some statements and demands for the overall security of data sharing.

All of the foregoing factors lead to the necessity and appearance of the Data Process Agreement, known also as DPA.

What is a DPA?

Frankly speaking, DPA is a mandatory agreement for software development outsourcing companies, who have an access to the personal information of the citizens of the European Union. To make it simple, it is a document, which prescribes various actions, processes, and other steps, directly related to personal data safety. In fact, it is an agreement between both sides, where they describe all the possible risks, and ways to avoid them. After signing it, each side takes responsibility for ensuring data protection.

Nonetheless, usually, the responsible for the data breaches or poor security standards is the data controller, not the outsourcing team. Therefore, it is the direct responsibility of the client to find a trustworthy software development outsourcing company.

Actually, Data Processing Agreement is not a mandatory thing, if your product is not targeting the EU market and audience. Yet, it is hard to predict whether your audience will include any EU residents, so it is recommended to have such an agreement just in case. Also, this particular standard is a well-designed agreement type, which ensures the data protection policies and the way, how long and for what purposes it will proceed, be stored, or shared. Even if you are not going to work with the European market, you will anyway be sure of the safety of your users' personal data.

Data Processing Agreement Checklist

So, now it is time to figure out what the DPA requirements are, or if there is any Data Processing Agreement Checklist. Honestly, the DPA, as well as most documents in the software development industry has no strict form. In other words, it can vary, depending on the terms of cooperation and the needs of both sides. Yet, it is possible to mark up the most common must-have options and shape the template. For instance, we can divide such Data Processing Agreement Checklist into main chapters.

General Info

Just like SRS documentation, or any other documents in software development, you have to proclaim and explain primary terms, like data controller and processor. Also, at this stage, we have to describe in detail the types of shared data, their subjects, etc. Finally, we have to explain what is the purpose to share and proceed the data and are objectives, you are willing to achieve by sharing information. Here we have also to express the software, used for data processing, the duration of proposed services, and overall agreement conditions. To make it simple, let’s transfer all the foregoing into a checklist:

1. Determine the sides of the agreement:

• Who is the Data Controller, i.e. the stakeholder or a client, who orders data processing services?
• Who is the Data Processor, or simply the software development outsourcing company, responsible for data processing?

2. Explain the major data-related aspects:

• Purpose of data processing, what is planned to achieve, and why these goals require data sharing.
• Amount and types of data, being shared. This helps to clarify the access to information and its volume.
• Required software, which may include various analytical or other tools, the management or processing systems, as well as any other parts of the tech stack.
• Duration and storage conditions, where the processor agrees with the controller on the period of sharing and processing time, terms of storing like security measures or elimination protocols.

Responsibilities of Both Sides

After the general info is shaped and agreed upon, we have to set all legal authorities of both sides. In other words, we need to clearly define all the rights and responsibilities for both sides independently. This part of the Data Processing Agreement Checklist is tricky because it fully depends on the term of the contract and its context. Thus, RaR can and probably will differ from one agreement to another.

If we talk about the client’s side, we can define the right to monitor or request results for the specific moment, or be able to make unappointed revisions, etc. On the flip side, we have to ensure that rights can’t harm the development team or the development process itself. Also, it is possible to add some other responsibilities like taking the blame, providing all needed resources, or other similar options.

Simultaneously, you have to define terms and conditions also for the development team. Most of them are variables, still, we have to mention some must-have terms. Among them is the request not to share the data with anyone else, at least without the permission and agreement of the contractor, and the demand to eliminate all data when the contract ends. The remaining requests are optional.

3. Define rights and responsibilities for both sides:

• RaR for Controller
• Rar for Processor

Working Process Explanations

Next, we need to explain all the aspects, related to data processing. Usually, they are divided into two categories: Technical and Non-technical. It makes it clear and easy to understand.

In the non-technical chapter, you have to explain how the overall process is going to take place, and what steps are to be made. It includes an explanation of how the data will be treated. Also, you can describe a general step-by-step manual about the working process. This helps to better comprehend the need for data processing and answer some related questions, which may appear before signing the agreement, or during the work.

The technical chapter answers almost the same question but from the software perspective. To make it simple, here you have to explain what software, hardware, or other tools will be used during working with the shared data. For instance, are you going to use Python or JavaScript in terms of project development? On the one hand, it helps to figure out what the risks may be and whether there are any third parties, who can get access to the confidential information. Additionally, this helps to better illustrate the technical side of data protection methods, and how this protection will be organized.

Extra Legal Terms

Here both sides can set up additional terms and conditions for the final agreement. For example, whether DPA can be changed, or not. If the answer is yes, then it is important to describe the specifics and conditions, when it is possible to make some changes.

Also, it is recommended to explain the legal status of the agreement, and its supremacy or subordination to other agreements and documents. Actually, the best way to correctly write this chapter is to consult your lawyers first. They can help you to better prioritize and position your DPA agreement to avoid uncertain situations in the future.

: we suggest you include here the ability to add various supplements in the future, which will be considered as legal as the DPA itself. As a result, even if you missed something, or some of the terms need to be changed during the software product development, you will be able to easily implement needed changeovers in a form of supplements.

Supplements

If you followed our advice, here you can add your agreement modifications, extra conditions, etc.

Apart from it, you can also describe some bonus activities and possibilities like the process of audit, prioritize some terms and explain the conditions when the software product development can be considered done, or anything else.

End Line

Summing up all the above, we can state, that having a DPA is both a mandatory and optional requirement, depending on whether you are targeting the European Union market or whether there are citizens of the European Union among your audience. Personally, we believe, that such a document is a great addition to any project regardless of who the users are, or what region it will be operated in. In any case, it can be a very useful method to clarify the term of behaving with various types of information or other project-related data.

As a result, combined with the correct discovery phase, DPA can help you to faster cover all planning activities, which have mostly legal nature, and faster push your project to live.