It seems that currently, profitability is the new black. Chances are that your organization is already knee deep in cutting costs and also figuring out how to increase revenue. Looking at that good old sales pipeline, wouldn't it be neat to monetize some of those juicy opportunities sitting around.
But let's face it, data protection and information security can create major headaches in terms the speed of closing deals. I'm sure you know the feeling: commercially the deal is done... but then data protection and security departments get involved and deflate any momentum and speed with a plethora of questions and comments regarding your DPA and security measures.
Based on our experience, there are ways to speed up closing deals by removing some of those roadblocks. This is quite a long post, so some aspects may be a bit oversimplified.
Understand why Leads are asking Questions and forget "GDPR Compliant" Tags
When using your service, your customers will entrust personal data of their employees and/or their customers ("data") to you that, generally (we will talk about exception in Part 3) you must only process according to instructions of the controller and under a data processing agreement (DPA).
A bit simplified, your customers primary interest vis-à-vis your organization is to make sure that there is a DPA in place that meets legal requirements and that you have "adequate" security measures in place to make sure their data is sufficiently safe with you. Most companies will (rightly) want to make their own picture in this regard.
Saying that you are GDPR compliant and/or putting a fancy fantasy badge on your landing page may be really cute for marketing, but in essence it means absolutely nothing to most of your potential customers. It bears no significance whatsoever, in particular, if you sell to enterprise or larger organizations. There are certifications (similar to ISO 27001) that are vouched for by independent accreditation bodies, which would provide more clout, however, certifications for GDPR are mostly still in the process of being developed. Bottom line, you probably won't have them (now) and neither will your subprocessors.
The sooner you understand that in many cases your customers will want more substantial answers, and the sooner you can provide meaningful documentation, the faster you'll close that deal.
Simplify your DPA
Legally speaking DPAs are pretty "stupid" contracts (this does not apply for the important description of processing carried out under it). Quite literally everything that is supposed to be stipulated in them is spelled out by Art. 28 GDPR. Therefore, any minute spent on negotiating DPAs is wasted time in our view.
Based on our experience there is a very effective fix, being the use of EU Standard Contractual Clauses (EU SCCs). EU SCCs are a template contract that has been approved by the European Commission. There is a prohibition to modify the core text (there is a bit wiggle room regarding the annexes). Therefore, none of your customers should have anything to nag about regarding the contract.
Important: do not confuse EU-SCCs with SCCs for third country transfers. They are two different things.
You can download the template here:
Set up a strong FAQ for your Sales Team
If you do not want to use the EU SCCs or your customer wants to use their own DPA then give your sales team some useful information to be independent, rather than having to run to legal with every comment in the DPA.
The starting point of the FAQ should contain a list of legal requirements of Art 28. In our opinion, for the sake of simplicity and speed you should kick everything out of a DPA that is not required by law. In particular this refers to provisions for liability and damages or jurisdiction (both can perfectly well be dealt with in ToS or other commercial agreements).
In addition, focus on providing information where it really matters. Based on our experience there are two areas that are frequently (and most fervently) subject of debate and negotiations.
Addition or Replacement of Subprocessors
Art. 28 mentions two options when adding or replacing subprocessors: a prior specific authorization or a general written authorization. The latter must include a prior notification and the right to object to the addition or replacement. Now, it is absolutely critical to understand that both options equally put your customer in the position to effectively object to adding or replacing, while the option to require prior authorization can wreak havoc on your operations. You would basically need to get prior approval from every customer before you can make any infrastructure switches, and only one customer that does not get back to you can block the entire process. Even if you customer says that it's their standard procedure to demand prior authorization, give them push back. If you explain the above to them, in a very high percentage they understand.
Audit Rights
Art. 28 requires the processor to provide all information necessary to demonstrate compliance with [Art. 28] and allow for and contribute to audits, including inspections. Because these things have the potential to eat up a lot of time and resources, a lot of processors will try to limit or exclude them. Sure, if a significant number of your customers starts wanting to do on-site inspections this can jam up your operations. However (and unfortunately for you), you are legally required to contribute to and allow them. If you try to limit or exclude them, in many cases this will lead to pushback from your leads and DPA negotiations and it is legally more than doubtful that such limitations or exclusions would stand in front of a court. If you boil it down you have the choice of creating more negotiations thus prolonging your sales cycle (which also uses resources) or biting the bullet and answer questionnaires or participate in on-site audits. IMHO, I would rather opt for the latter. On-site audits for cloud-heavy operating companies are quite rare in our experience (I mean what is there really to see?) and resources for questionnaires can be preserved with better security documentation.
The next parts of this series will deal with international data transfers, separating between being a processor and a controller, and security documentation, known as "technical and organizational measures" or "TOM". Make sure to add relevant information regarding all of those topics to your sales FAQ.
Stay tuned for Part 2