Since POPIA (the Protection of Personal Information Act) has kicked in fully on the 1st of July, one of the most frequent tasks across my desk has been to review Data Processing Agreements (or Addendums, Annexures, Schedules and a variety of other names, often abbreviated to DPA). These documents can be confusing, longwinded, and in some cases even unnecessary. In today’s post, I’ll go through some of my own pointers as to what to look out for in these documents.

Why are they needed?

In both GDPR in the EU (General Data Protection Regulation) and POPIA in South Africa, a written agreement needs to be in place between a Responsible Party – the company that is making the decisions on how to collect and process data – and an Operator – the company that is processing the data collected by the Responsible Party, under the Responsible Party’s instructions. For the purposes of this article, I’ll be focusing on POPIA.

Section 20 of POPIA states that an Operator processing information on behalf of a Responsible Party must only do so with the knowledge and authorisation of the Responsible Party, and must treat all information that comes to them as confidential. Further to this, Section 21 states that a Responsible Party must enter into a written contract with the Operator, which is where this requirement comes from.

Now there aren’t a whole lot of responsibilities for an Operator under POPIA, and that’s where these contracts come in. Under POPIA, the Responsible Party takes the lion’s share of responsibility and accountability in terms of the act. It’s up to them to do their due diligence on suppliers to ensure that data stays secure, because if a supplier or third-party has a breach of the Responsible Party’s information, the Responsible Party is the one that ‘takes the heat’ for it. These contracts form part of this due diligence and add a few extra protections.

What should be included as a minimum?

While GDPR expects a lot more in a data processing agreement, POPIA has minimal information that has to be included. Under Section 21, the agreement needs to ensure that the Operator will notify the Responsible Party immediately when they “have reasonable grounds to believe” that someone unauthorised has accessed or acquired information; in other words “Breach notification”. To try and avoid these breaches, the agreement also needs to ensure that the Operator will implement and maintain security measures in their business, as detailed in Section 19.

Section 19 in turn states that a company must take reasonable technical and organisational measures to prevent the loss of information or unlawful access to information. To do this, the company needs to:

  • Identify reasonably foreseeable internal and external risks to information,
  • Establish and maintain safeguards against the risks,
  • Regularly verify the safeguards, and
  • Ensure that the safeguards are continually updated to address new risks or inefficiencies in the safeguards.

These safeguards, as mentioned, include technical and organisational measures, better known in the privacy industry as “TOMS”. Technical measures can be things like security implementations, alarm systems, firewalls etc, while organisational measures could be processes, procedures, and policies. Both categories of security measures work together, and both should be part of your privacy regime, regardless of whether you are a Responsible Party or an Operator.

So why is my DPA so cumbersome?

Given that there’s so little to include, why on earth are you seeing such a monstrous agreement? Surely it could be a one-pager? Well, yes it could, and should be, if you’re processing minimal information. That said, most organisations are looking to the GDPR for guidance on their DPAs, which introduce a lot more responsibility in the space (this is a good thing, in my opinion). Remember that I mentioned that the Responsible Party takes the lion’s share? Well, these agreements are cumbersome to try and prevent (at least contractually) anything going wrong during processing, and therefore landing the Responsible Party with a fine.

Effectively, the Responsible Party will contract out many more obligations than just TOMS in order to safeguard their interests, including the right to civil action against the Operator to try and recoup some of the costs in cases where they do get penalised by a regulator or sued by the public. GDPR and European agreements are very mature in this space, and the DPAs to support it are relatively standardised.

How do I look into these?

As with any contract you would look at, these are a negotiation. Do not just simply accept a Data Processing Agreement from your clients. Below are a number of the considerations to make when looking into these documents. Don’t be scared of them, be sure to read them, just like you would your normal service agreements.

They should be customised to the processing

The Responsible Party does need to ‘throw you a bone here’ and assist in what they’re looking for. Too many times we see that a company is sending out a blanket DPA that doesn’t match with the actual processing. If you’re simply processing a name and email address to post a virtual birthday card for a client, you woulnd’t need a 30 page document. However, if you’re processing sensitive information, you may need an incredibly comprehensive document compiled by an attorney. Be sure to know where you stand, and have a discussion with those sending the agreement to you.

Don’t accept incomplete DPAs

This I’ve seen a number of times, often in much larger enterprises where a DPA has been drafted by the legal department, along with a lot of “[insert something here]” comments, which instead of a project manager / risk manager completing themselves, they try pass on to the Operator. This doesn’t cut it, and they need to give you guidance. If you see a DPA that’s missing content, please go back to the person that sent it to you and ask them to complete it properly.

Related to this, is where you may receive a due diligence document that the Responsible Party’s risk/project manager was supposed to complete. This is again a failure to communicate internally, and often happens in the bigger corporates. If you see wording like “check that the agreement has a clause for xyz” or “does the SLA specify performance metrics?“, ask them whether you should be completing this, or whether it’s an internal document (that they’re passing over the fence).

The “right to audit” is not a bad thing

A clause that scares folks off is the “right to audit” that you’ll see in a GDPR based agreement. This is not a bad practice, and means that your client can come and check that you’re doing the right thing. There are some catches here to be aware of though.

For one, negotiate on the costs here. Sometimes they’ll try and force the cost of an audit on to you along with the right to audit. In most cases, this is unfair and I’d argue that the costs should be borne by the Responsible Party requesting the audit.

Secondly, be sure that there’s an additional clause in there that protects your other clients. An audit should come from a neutral 3rd party if done correctly, and should not be allowed to compromise any of your other clients’ data. The contract should reflect this too.

The “big guys” are generally OK

Companies like Microsoft, Amazon, Zoho and so forth are not likely to budge on their own agreements that they send your way. That said, generally their privacy practices and security measures are very good. Their agreements will most likely be tailored for GDPR, and as such would include breach notification and security measures required by POPIA too.

If you’re a Responsible Party reading this, you’ll need to have these agreements in place too with your SaaS Operators – like Microsoft 365 and other services – especially if they’re outside of South Africa and the EU. In these cases, the DPA may be a separate document, or it will be included as part of the Privacy Policy and Terms of Service. You’ll need to read up for each provider. The quickest way to do this is to Google “[company] DPA” and see what comes back. For example, search “Atlassian DPA” and you’ll be directed to the DPA for JIRA, Trello and the rest of Atlassian’s suite.

TOMS may be just a “Security” section

Technical and Organisational Measures is a term I used earlier, and you may see this either as simply a “Security” section in a shorter DPA, saying that you’ll adhere to security measures, or it can go to an incredibly extensive appendix to the document (normally Appendix 2, if dealing with some of the standard GDPR agreements). If it is just a section on “Security”, look out for wording that refers to other documents that you don’t have in your possession, and ask for them. Often these clauses will state that you must adhere to their security policies, but they seldom provide them. Ask them for their policies so that you can make an informed decision in this aspect. You need to know what you are agreeing to.

TOMS should be filled in for you

When you do get TOMS, they should be completed for you, unless otherwise agreed. The Responsible Party has a duty to set out the minimum requirements that you as an Operator should be following. They should also, however, be reasonable for you.

TOMS should match the processing

Technical and Organisational Measures should be reasonable for your business, and should relate to the processing at hand. This is where a negotiation may need to come in. Often, you’ll receive a blanket TOMS section that demands the best of everything, or incredibly corporate/enterprise grade security – which is wholly impractical for a small business. Do not agree to TOMS that you can’t / won’t implement (remember, they have the right to audit!) and instead negotiate what is actually required with regards to the processing you are doing. Take into account the extent of what you are processing, and how sensitive the processing is. The TOMS should align with this.

Improvements should be negotiated or shared

If you do reach a situation where you would not or could not implement the TOMS required, the agreement should make room for negotiating with the client for the costs of the improvements required by them. For example, if you are a smaller Operator and you land a massive client that suddenly requires loads of encryption and an Enterprise license for SQL, there should be room to negotiate the difference in costs between SQL Standard, SQL Enterprise, and the effort for implementing. Responsible Parties forcing unrealistic security on a small provider is a quick way to sour a relationship, but many are willing to negotiate.

Watch out for Cross-Border clauses

There will likely be a section in the agreement regarding Cross-Border or Transborder Information Flows. This is referring to you as the Operator using service providers that are in other countries to help you deliver your services. This is not to say you cannot do so, but be sure to read the fine-print here. Some DPAs will require that you get written approval from your clients before changing providers, which can severely hamper you or land you in hot water if they find you have used another service. Negotiate these sections, but also try and keep your processing in South Africa, Europe, or a country that Europe has designated “adequate” for processing (we are yet to see which countries South Africa will designate as “adequate”).

Sub-Processors / Sub-Operators

Part and parcel of Cross-Border clauses, is the inclusion of a list of sub-processors / sub-operators. These are service providers that you use to provide the services to your clients. These could be Microsoft 365, Amazon AWS, JIRA, outsourced consultants, or many more proliferations of third-parties. Agreements that are based on GDPR preferences will often have you list these out in a separate subsection (often Appendix 3) which would include the countries that these providers are in. Be honest in this section, and chances are your providers will be approved. Do not hide a processor because you’re afraid that it won’t be accepted, cross that bridge when you actually get there – it’s much worse if you don’t declare and they find out you’ve used additional processors.

Note: This exercise should be part of your own privacy program to begin with, if you can’t do it easily or provide this list, you haven’t considered your processing enough internally!!

Return and Destruction

Most agreements will also detail what needs to happen with data in terms of terminating the master agreement. Often, data agreements will stay in place longer, much like Non Disclosure Agreements (NDAs). DPAs will generally state that you need to securely return or remove all information at the end of the agreement. Because of this, it’s vital that you have some sort of filing system so that you know where information is, but it’s also important that you can actually follow through on the removal. Have processes in place internally to ensure you can do so.

Some agreements will detail secure destruction. When it comes to paperwork, you should always be shredding pages before they leave your premises. Digital information does become a bit more tricky. To securely delete information off computer systems, you need additional tools. If this is in your DPAs, please contact your IT team or assistant to find out more about secure deletion methods and how you can implement them.

Liability Clauses can be ridiculous

Lastly, and probably the biggest challenge in DPAs, is liability and indemnity clauses. These range incredibly in what is being pushed, and often this will be the biggest sticking point. As mentioned before, the Operator has very few responsibilities in terms of POPIA, and as such, Responsible Parties will try and push contractual responsibility to them. What you want here is “we’re going to keep you in check and recoup some costs from you if things fail“, but often what is delivered in these clauses is “if we’re going down, we’re taking you with us“. Some wording to look out for here is “direct”, “indirect”, and “all”. The liability should be in proportion to the type and sensitivity of the processing being done.

Liability for direct costs is generally ok, this is basically that the client can recoup direct costs from any data breach. Indirect or “all” is where it gets hazy; they could claim any number of costs unrelated to the incident from you – something significantly higher than just their direct costs. Coupled with this, is a limit on liability. If you have an agreement with no limit on liability, it’s incredibly dangerous. I’ve seen a number of companies successfully negotiate a limit of their maximum indemnity insurance, or alternatively the maximum fine of POPIA (R10m, which is still high). In any event, you will want to read your liability clauses incredibly carefully, possibly seeking legal advice, and in most cases, negotiate. It’s still a contract, and the same rules apply.

Ross G Saunders consulting is a niche consultancy dealing with data protection (privacy and information security) in tech businesses and SMEs. We take the pain out of understanding four-letter-words like GDPR and POPI, while providing practical advice and smooth implementations. We also provide training to all levels of staff on what can (and does) go wrong in data protection.

Share This

Share this post with your friends!