More instructive guidance from the EDPB would help reduce uncertainty and potentially eliminate the need for DPAs to issue further and potentially conflicting guidance.
Controllers and processors
Another critical issue which continues to raise significant debate is the distinction between 'controllers' and 'processors'. We come across numerous organisations which are uncertain of their role because of the degree of discretion which they have and the types of decisions which fall within their remit. There is also a trend towards parties identifying themselves as joint controllers, even if it is not factually correct. Examples include service providers in the financial sector, companies engaged in clinical trials, and businesses involved in market research.
The available guidance relies heavily on examples which often do not reflect the complexity of business relationships in practice, particularly in the context of technical and innovative environments where many players who are often intertwined. This leaves many questions unanswered. Controllers and processors have to incur additional compliance costs, including legal fees, to analyse the relationship between parties before any compliance action can be taken. To ensure that the fundamental definitions around the relationships between parties are as clear as possible, guidance with practical examples where the relationships are not clear is required.
Article 28 – processor clauses
Article 28 of the GDPR provides certain contractual requirements for controller-processor relationships. However, there is a lack of clarity on what is acceptable and how commercial points can be achieved without infringing upon these requirements, and this has led to an inconsistent approach across the EU.
The Danish DPA has published standard processor clauses to improve consistency in Denmark. An example from the Danish processor clauses is the stipulation that in some cases, such as bankruptcy of the processor, the controller shall have the right to enforce the agreement between the processor and the sub-contractor. While this approach is also common in Spain, this is not usually the case in member states like Ireland and Germany. If this is required to comply with Article 28(4) GDPR, the law should be quite clear on it as otherwise a processor would usually not have the negotiation power to include this in an agreement with a market-leading sub-contractor.
Another example from the Danish processor clauses specifies that the controller has the opportunity to object to any proposed changes to sub-processors, but it remains silent on the consequences to these objections. In some parts of the EU, including Ireland and France, the controller is generally granted a termination right, but it is, in our experience, less common to do so in other member states such as Spain and Germany. It is also unclear if a termination right complies with the GDPR as it could deprive the controller of its right to object in circumstances where the controller relies on a certain processor – like a major cloud provider, for instance – and its only option is to accept the sub-contractor or terminate the contract.
It would be helpful if the EC adopted a set or sets of standard processor clauses as a base standard that can be applied. Those clauses would have to allow for flexibility for commercial terms, but template clauses would at least provide the parties to such agreements with comfort that their agreement has met their obligations under Article 28.
International transfers
Organisations need to be aware of local laws in other jurisdictions to determine whether they contradict the protections offered by the European Commission's standard contractual clauses (SCCs) for transferring personal data outside the EEA. That was the view of the advocate general in the so-called 'Schrems II' case currently before the Court of Justice of the EU (CJEU). If there is a contradiction, controllers and DPAs are expected to act to prohibit, suspend or terminate the data transfer.
This requirement, if endorsed by the CJEU in its formal judgment in the case, makes the SCCs less appealing to controllers and more difficult to use as a transfer mechanism. Adding to this is the fact that the current SCCs have not been updated to take account of the GDPR.
Another longstanding concern is that there are no processor-to-sub-processor SCCs. We have seen a number of creative ways of cobbling together processor-to-sub-processor SCCs but none of these approaches have been approved or recognised by the Commission, EDPB or any DPAs.
For international transfers made to controllers and processors to which the territorial scope of the GDPR applies, it is not clear if a transfer mechanism is required at all. This is a fundamental point in relation to international transfers. The UK's Information Commissioner's Office's (ICO) guidance on international transfers indicates that the ICO is of the view that if the GDPR applies to an organisation, a transfer mechanism is not required. The EDPB swerved this point in its guidance on the territorial scope of the GDPR and stated that it will further assess the interplay between the application of territorial scope and international transfers under the GDPR.
From a practical standpoint, a lot of companies have been using SCCs to tick the transfer mechanism box but have not been ensuring compliance with the contractual provisions. The anticipated decision in Schrems II should provide some clarity in relation to the use of the existing SCCs but organisations want the Commission to update the SCCs to make them GDPR compliant and urgently explain what is expected in relation to international transfers and how this can be achieved. This area, in particular, may require amendments to Chapter V provisions of the GDPR to reflect this.
Costs and registration requirements
The costs of complying with the GDPR can be a heavy burden for some businesses. In reality, most controllers and processors are not GDPR compliant. The have prioritised on high-risk areas and their interactions with data subjects, such as ensuring their privacy notices are up-to-date, but are still working on full compliance, such as implementing data protection by design and default. On top of the cost of changing processes, adopting new policies and the administrative burden of compliance, many controllers and processors have incurred additional fees for legal advice, procuring data protection software and hiring data protection experts.
Some member states have introduced different notification and registration requirements which reduce harmonisation and increase the burden of compliance. As examples, Ireland, Spain and the Netherlands require the registration / notification of data protection officers to the DPA. In France and Denmark certain processing activities must be notified to or authorised by the DPA.
It may be possible to implement central EU registers which eliminate the need to comply with multiple local registration requirements.
Fines
At present, it is not clear how fines are calculated by DPAs. Information or reports on the issues are not provided each time a fine is applied by a DPA which results in a lack of transparency around how fines are determined and whether they are being calculated uniformly. Although the EDPB has issued guidance on administrative fines, this guidance is pitched at too high a level.
In October 2019, the Datenschutzkonferenz adopted a common approach across federal and state data protection authorities in Germany for setting administrative fines. The amount of the fine is based on certain criteria, mainly annual turnover, the gravity of the infringement and individual circumstances. Other DPAs, such as those in Ireland and France, have not provided any guidance on how such fines are calculated, whereas Spain has provided guidance which reflects what is set out in Article 82 of the GDPR.
Another issue is how cases concerning the lower level of fines – where fines up to €10 million or 2% of total worldwide annual turnover can be levied – and those concerning higher level fines – up to €20 million or 4% of total worldwide annual turnover – are distinguished. If a controller is fined, for example, for a personal data breach which was due to a breach of the security requirements under Article 32 – a lower level fine, when should a DPA also determine that this is an infringement of the basic security principle under Article 5 – a higher level fine?
We propose more detailed guidance at EU-level on how fines should be calculated. This will allow for more transparency around how fines are applied and encourage consistency in their application.
DPA resources
A number of DPAs across the EU have highlighted the resource constraints they face in light of an increased workload under the GDPR. Both the Irish Data Protection Commission and the Autoriteit Persoonsgegevens in the Netherlands raised the topic in their recent annual reports.
Under the GDPR, the role of DPAs has altered and expanded in comparison to their role under the old Data Protection Directive, requiring them to carry out a shopping list of tasks including, but not limited to, monitoring and enforcing the GDPR, promoting awareness and understanding, and conducting investigations on the application of the GDPR. They are also required to participate in the EDPB and foster harmonisation across all of the DPAs.
Generally, fines the DPAs impose under the GDPR do not go directly towards their funding. Instead, the money collected is pooled centrally by the treasuries of the respective member states. Based on information provided by 17 DPAs at the beginning of 2019, only Hungary had stated that it had sufficient budget for 2019.
Article 52(4) of the GDPR specifically requires that each member state ensures that its DPA "is provided with the human, technical and financial resources, premises and infrastructure necessary for the effective performance of its tasks and exercise of its powers". Where DPAs do not have enough resources, the Commission must put DPA resourcing high on its agenda in its dialogue with member states. If DPAs are better funded, they should be able to be more proactive with their tasks which will benefit data subjects, controllers and processors.