DPA Agreement: When an IT Company Needs a Personal Data Processing Agreement

A company sells a SaaS service to a client in the EU. The client uploads information about employees or customers to the system, the provider stores it, creates backups, and gives the support team access to it. When negotiating the contract, the client asks the company to sign a Data Processing Agreement, or DPA.

Such a document is often treated as a formal appendix from a standard GDPR package. However, a DPA defines the legal framework for working with data: who determines the purposes of processing, who follows instructions, which contractors have access to the information, and how the parties act in the event of a data breach.

If the provisions of the agreement do not reflect the product architecture, the DPA will not help the company pass a client audit. Moreover, the company may accept obligations that its technical team is unable to fulfill.

The term DPA Agreement is often used in search queries, although the word “Agreement” is already included in the abbreviation DPA. The correct full name of the document is Data Processing Agreement, an agreement governing the processing of personal data.

When a DPA Is Mandatory

A DPA is required when one company processes personal data on behalf of another. This requirement is established by Article 28 of the GDPR and applies to the relationship between a controller and a processor.

The controller determines why personal data is used and establishes the essential rules governing its processing. The processor performs operations on the controller’s behalf and follows documented instructions.

For example, a client uses a CRM to manage its own customer database. It determines what information is collected, the purposes for which it is used, and how long it is retained. The CRM provider supplies the technical environment, stores the information, and maintains the system. In this processing activity, the client is the controller and the CRM provider acts as the processor.

IT companies typically need a DPA in the following cases:

• a SaaS service stores or analyzes information uploaded by the client
• a developer has access to the client’s production database, logs, or backups
• a support team can view user requests and account data
• a cloud provider hosts databases or file storage
• an email service processes email addresses and communication history
• a monitoring system receives IP addresses, device identifiers, and event logs

Article 28 does not require the contractor to regularly review the data. Access may be used only for technical support or incident investigation. If such access is part of the contractor’s functions and involves personal data, the relationship between the parties should be assessed for compliance with the controller-processor model.

A DPA may be executed as a separate agreement or as an appendix to an MSA, SaaS Agreement, or development agreement. The title and placement of the document are not decisive. Its terms must be binding on the parties and comply with Article 28 of the GDPR.

When a DPA Is Not Appropriate

Receiving personal data does not in itself make a company a processor. Its role depends on who makes decisions about the purposes and essential means of using the information.

A bank, payment institution, or professional adviser may process information received in order to fulfill its own obligations. In this respect, they act as independent controllers, so an agreement under Article 28 is not appropriate for these processing activities.

If two companies jointly determine the purposes and means of processing, they may be joint controllers. Their respective responsibilities are allocated under Article 26 of the GDPR.

A single provider may sometimes perform several roles. A SaaS platform may process a client’s database on the client’s behalf while independently using certain technical information to protect the service, prevent fraud, or comply with the law. Each processing activity should be assessed separately. Contractual wording will not change the company’s actual status if the product operates differently.

What Must Be Included in a DPA

Article 28 of the GDPR establishes mandatory requirements for the content of the agreement. A short confidentiality or legal compliance clause is not a substitute for them.

A DPA must specify:

1. the subject matter and duration of the processing
2. the nature and purposes of the data processing activities
3. the types of personal data and categories of data subjects
4. the rights and obligations of the controller
5. the procedure for following documented instructions
6. confidentiality and security requirements
7. rules for engaging subprocessors
8. the procedure for deleting or returning data
9. assistance with data subject requests, DPIAs, and incidents
10. the provision of information and conduct of audits

The description should make it possible to determine what information the processor receives and what it is permitted to do with it. Wording such as “all data necessary to provide the services” creates boundaries that are too broad.

For a SaaS product, registration information, contact details, the content of requests, activity history, and technical identifiers may be specified separately. The exact list depends on the product’s functionality and the data that the client actually uploads to the system.

After the services are completed, the information is returned to the controller or deleted at its choice, unless the law requires further retention. The deletion period should be aligned with the backup policy. A promise to immediately delete all copies is often impossible to fulfill because backup data remains stored until the end of the established overwrite cycle.

Why the Security Section Should Be Agreed with the Technical Team

A general promise to implement appropriate technical and organizational measures does not give the client a clear understanding of how the data is protected. The DPA or a separate appendix should describe access management, encryption, backups, activity logging, and incident response procedures.

The content of this section depends on the risks associated with the processing. A medical platform provider handles more sensitive information than a service used to send corporate invitations. Using the same template security measures for both products will either be insufficient or impossible to fulfill.

The technical team should review the terms before the agreement is signed. The contract may include obligations relating to 24/7 monitoring, specific encryption standards, or recovery times that the product does not currently meet. Once signed, such discrepancies may be discovered during a client audit or an incident.

The controller’s right to conduct audits should also be defined in advance. The agreement may establish a notice period, confidentiality requirements, permitted audit methods, and allocation of costs. A complete prohibition on audits is inconsistent with Article 28, while unrestricted client access to the infrastructure may create risks for other customers.

How to Regulate the Engagement of Subprocessors

A SaaS provider rarely performs all processing activities independently. Hosting providers, cloud platforms, email services, monitoring services, and external support teams may all participate in the processing. If such a contractor receives personal data as part of the services provided to the controller, it becomes a subprocessor.

Engaging a subprocessor requires the controller’s prior specific or general written authorization. Where general authorization is given, the provider informs the client of any addition or replacement of a subprocessor and gives the client an opportunity to object.

The DPA should specify where the current list of subprocessors is maintained, how notifications are sent, and how much time the client has to respond. A link to a webpage does not resolve the issue if the provider can change the list without notifying the client.

The subprocessor must assume comparable data protection obligations. The primary processor remains responsible to the controller for the subprocessor’s performance of those obligations. Before engaging a new service provider, the company should review its contractual terms, security measures, the location of its systems, and the rules governing onward transfers of information.

What to Provide for in the Event of a Data Breach

In the event of a personal data breach, the processor must notify the controller without undue delay. The GDPR does not establish a universal 72-hour deadline for processors. The 72-hour deadline applies to notification by the controller to the supervisory authority where the breach presents the relevant risk.

The DPA should establish a timeframe for the initial notification and specify the information the processor must provide at that stage. The controller will need a description of the breach, the categories of affected data, the approximate number of data subjects and records concerned, the likely consequences, and the measures taken.

A complete report can rarely be prepared within the first few hours. A practical procedure provides for an initial notification once the incident has been confirmed, followed by updates as the investigation progresses. Contact persons, a backup communication channel, and procedures for preserving evidence should be established in advance.

Does a DPA Replace Standard Contractual Clauses (SCCs)

A DPA governs the relationship between a controller and a processor under Article 28 of the GDPR. Standard Contractual Clauses are used as one of the mechanisms for transferring personal data outside the European Economic Area.

If a European client transfers data to a processor in a third country, a DPA alone may not be sufficient. The parties need to check whether an adequacy decision applies or select another mechanism under Chapter V of the GDPR. When SCCs are used, the laws of the recipient country and the actual risks of access to the information must also be assessed.

Modules 2 and 3 of the SCCs approved by the European Commission incorporate the requirements of Article 28. In an appropriate model, they can simultaneously regulate the processor relationship and the international data transfer. To do this, the correct module must be selected and the annexes describing the processing, security measures, and subprocessors must be completed.

Common Mistakes in DPAs

The most obvious problem arises when the agreement does not reflect the product. The document states that all data is located in the EU, while backups are stored in another country. The provider promises to obtain prior approval for every subprocessor, although the technical team engages new services without involving legal counsel. The deletion period does not account for backups, while the incident notification procedure conflicts with the company’s internal process.

Mistakes also arise when determining the parties’ roles. A company may describe itself as a processor for all operations even though it uses some data for its own purposes. The opposite situation is also possible: a provider considers itself an independent controller even though it actually follows the client’s instructions.

A DPA is sometimes confused with a Privacy Policy or Cookie Policy. A Privacy Policy explains to users how the company processes their data. A Cookie Policy relates to the use of cookies and similar technologies. A DPA governs the relationship between organizations.

A breach of the obligations under Article 28 may result in an administrative fine of up to EUR 10 million or up to 2% of the total worldwide annual turnover for the preceding financial year, whichever is higher. The parties may also face claims for damages and contractual liability to the client.

What to Check Before Signing

A DPA review should begin with a data flow map. The company should determine what information enters the product, where it is stored, who has access to it, and which external services are involved in the processing.

Before signing, it is worth checking whether:

• the parties’ roles correspond to how the product actually operates
• all categories of data and data subjects are listed
• the security measures correspond to the company’s actual capabilities
• support activities, logs, and backups are taken into account
• a complete list of subprocessors is provided
• international data transfers are properly structured
• incident notification deadlines are agreed
• deletion and audit requirements can actually be fulfilled

If the client provides its own template, every obligation should be discussed with the technical team. A signed document does not compensate for weak access controls, an unknown chain of subprocessors, or the absence of a data breach response procedure.