Data processing agreements in Poland: when is a DPA required and what should it cover?

When does a business need a DPA?

The requirement arises when one organisation processes personal data for another without pursuing an independent purpose of its own. Common examples include:

These categories do not determine the role by themselves. The actual service model matters. If the supplier also uses the data for independent analytics, profiling, development of a separate service or its own marketing, those activities need a separate assessment. One supplier may be a processor for some operations and an independent controller for others.

The DPA may form an annex to the main contract or an identified part of it. The GDPR requires a written form, including electronic form. It should be consistent with the service description, SLA, security terms and liability provisions. Otherwise, separate documents may set conflicting incident deadlines or inconsistent rules for appointing subcontractors.

• a hosting provider maintaining a customer database;
• an accounting firm processing employee data within its mandate;
• a CRM or helpdesk provider storing the customer’s user data;
• an external mailing provider using the controller’s distribution list;
• an IT support provider accessing personal data while maintaining a system.

How should the parties distinguish a processor from a controller?

A controller determines the purposes and means of processing. A processor acts on the controller’s behalf and under documented instructions. Joint controllers determine the purposes and means together.

The practical questions include:

A processor may retain discretion over certain technical or organisational choices without becoming a controller. If it starts determining an independent purpose, however, it may be treated as a controller for that processing. Article 28(10) GDPR expressly addresses a processor that infringes the Regulation by determining the purposes and means of processing.

For cloud and SaaS services, role mapping should precede negotiations over the supplier’s standard terms. The wider commercial agreement is discussed in SaaS agreements with business customers under Polish law.

• who decides why the data is used;
• who selects the categories of individuals and data;
• whether the supplier may use the data for its own purposes;
• who determines retention periods;
• whether the supplier may combine the data with information from other customers;
• who handles data-subject requests.

What must an Article 28 DPA contain?

The contract or other legal act must specify at least:

It must also require the processor, among other matters, to:

Repeating that list verbatim does not solve operational issues. The agreement should identify contacts, the method for issuing instructions, the content and timing of incident notices and the data export and deletion process. Complex processing should be described in schedules that can be updated without obscuring the contractual controls.

• the subject matter and duration of processing;
• the nature and purpose of processing;
• the types of personal data and categories of data subjects;
• the controller’s obligations and rights.
• process data only on documented instructions, including for international transfers, unless applicable law requires otherwise;
• ensure that authorised personnel are bound by confidentiality;
• implement the measures required by Article 32 GDPR;
• comply with the rules for engaging sub-processors;
• assist the controller in responding to data-subject rights;
• assist with security, personal-data breaches, data protection impact assessments and prior consultation;
• delete or return data, at the controller’s choice, after the services end unless the law requires retention;
• provide information needed to demonstrate compliance and allow or contribute to audits and inspections;
• inform the controller if an instruction appears to infringe the GDPR or other data-protection law.

How should a controller verify a supplier?

A controller may use only processors providing sufficient guarantees that appropriate technical and organisational measures will be implemented. This is not a one-off formality at signature. The depth of review should reflect the risks, the data involved, the service scale and the degree of business dependency.

A review may cover:

• system architecture and processing locations;
• access control, authentication, encryption and backup arrangements;
• vulnerability and incident management;
• independent assurance reports or certifications, with attention to their scope;
• material security incidents and corrective actions;
• business continuity and data recovery;
• the sub-processor list and allocation of responsibilities;
• data return and deletion after termination.

How should sub-processors and non-EEA transfers be addressed?

A processor may not engage another processor without the controller’s prior specific or general written authorisation. Under a general authorisation, the processor must inform the controller of intended changes and give it an opportunity to object.

The DPA should cover:

Approval of a sub-processor does not by itself solve an international-transfer issue. If data is transferred or accessed from outside the EEA, the parties must separately identify the relevant Chapter V mechanism, the scope of the transfer and the required safeguards. This may also matter where core infrastructure is located in the EEA but support personnel can access it from elsewhere.

• a current list or accessible register of sub-processors;
• the functions they perform;
• the countries in which processing takes place;
• the method and notice period for changes;
• a workable objection process and the consequences of unresolved objections;
• the obligation to impose materially the same data-protection duties on the sub-processor;
• the primary processor’s responsibility for the sub-processor’s performance.

How should the DPA deal with incidents, audits and exit?

A processor must notify the controller without undue delay after becoming aware of a personal-data breach. The controller may have only 72 hours to notify the supervisory authority, so repeating the statutory phrase may not provide a usable incident process.

The agreement should specify the minimum content of an initial alert, an emergency channel, team availability, progressive updates and preservation of evidence. The contractual response time should reflect the service and the risk. The processor should not postpone the first notice until a full investigation is complete.

Audit rights should enable the controller to obtain enough information to demonstrate compliance. In a multi-tenant service, the process may reasonably begin with documentation and independent reports, followed by a security meeting and, where justified, a remote or on-site audit. Contractual restrictions must not remove the controller’s meaningful ability to verify compliance.

Exit arrangements should determine:

• the format and timetable for returning data;
• responsibility for migration;
• when live copies and backups will be deleted;
• how deletion will be confirmed;
• which data must be retained by law and how it will be isolated;
• whether the controller retains access during the notice period and following a service failure.