Before you read this post, it is advisable to read the GDPR Summary.
This post is for the people who are responsible for the business side of owning software, people who own or are responsible for the intellectual property in software - the people who have to worry about business risk, contracts, sales and so on.
This post is not aimed at you if you purchase standard software from others to use in your business, such as Office or Email services. It is aimed at you if your business develops or has software developed for it, whether for your internal use or for you to provide to other organisations.
Business risk
The GDPR comes with significantly enhanced enforcement powers, to the point where a significant breach of the GDPR will be enough to bankrupt many businesses. This is no longer "just" about reputational damage and a slap on the wrist; this may be about the survival of your company.
- Much higher fines. The fines under the GDPR are much, much higher than under the old regulations, with the top-tier fine being the higher off €20 million or 4% of global annual turnover. A limited number of breaches fall into a lower tier and so are subject to fines of up to 2% of annual worldwide turnover or €10m, whichever is the greater. Failing to notify a personal data breach or put in place an adequate contract with a processor fall into this lower tier.
- Extended and pro-active audits. There is an expectation that the Information Commissioner's Office will be expanding its use of compulsory audits. Indeed, the ICO announced in May 2017 that it would hire an additional 200 lawyers, expanding their workforce by 40% ( https://iapp.org/news/a/uk-ico-to-expand-by-an-estimated-200-new-employees/).
Business models
There are a number of compliance requirements, detailed in the linked posts as well as process and record keeping requirements mentioned below, which will cost you time and money to implement. However, these are just expenses you have to meet but it should not otherwise affect your business.
However, there are also some business models that are simply not viable anymore under the GDPR.
For some businesses, the GDPR will remove their core value proposition, for others it will limit the extent to which they can derive extra value from the data they process.
A lot of the things to consider have to do with consent.
Don't assume consent or obtain it by trickery
Consent now must be informed and freely given. It must be consent to what you do with the data.
- You need explicitly and clearly to tell users what you are going to do with their data. You cannot bury this on page 15 of the terms and conditions.
- You are not allowed to do anything with the data for which you have not explicitly asked for consent to do (other than anything which is implicit in the contract, such as using their address to send them the things they bought from you). A really good example of just how easy it is to cross that line is the ICO fining charities for enriching their donor data with wealth data to target them better. Note that the fines were lowered very significantly in this case because the offenders were charities; if you did this, the fines would be many times higher.
- You must not pre-tick the consent forms or use the infamous double speak in the consent clauses; The default must always be that the user is not consenting and they have to take an explicit action to consent.
Offering a free service in exchange for consent
There are business models that are based on the idea that you offer a free service to users in return for them to consent to you doing something with the data, such as using it for marketing or selling it to a data company. Sometimes this is at the core of a business, at other times it is a value add that funds the company through a bootstrapping period or is just extra value.
You are not allowed to make the provision of the core service contingent on consent to something that is not required for providing the core service. In other words, you are not allowed to tell the user they cannot sign up for your weather notification service unless they agree to receive marketing calls from a double glazing company.
Affiliate business / lead gen / selling of data
It is quite common for business that provide services to consumers to realise that they are sitting on a lot of valuable data which can be useful to credit referencing agencies, insurance companies, marketing companies and so forth and it is common to try to generate extra income by selling the data on. A model we have often seen is to pass details on to insurance companies in order for those insurance companies to contact the consumer to sell them insurance in relation to whatever good or service you just provided.
You are still allowed to do that – but you need to first obtain informed consent from the user.
Withdrawing consent
The GDPR requires users to be able to withdraw consent as easily as they gave it. This comes with a number of technical challenges that are described in the version of this post aimed at software builders.
However, in addition to what you need to do in your own software, you also need to pass this withdrawal on to those partners to which you passed the data on in the first place.
As an example, imagine you are selling bicycles online. When the consumer checks out, they have an option to say something like "please contact me with a great quote on insurance on your new bicycle". When the consumer ticks that, you then pass that data on to an insurance company who calls the consumer and sells them the insurance. So far, so good. But imagine, then, that the consumer changes their mind and goes back in to your site to withdraw their consent to be sold insurance. You now have to pass that withdrawal on to the insurance company.
Arguably, this is just a technical problem; the integration with your 3rd parties just needs to be able to handle this withdrawal. But, from practical experience, this is likely to make the integrations much more complex and therefore costly, which may well undermine the whole business case.
Children
Children under the age of 16 have significantly extended protections under the GDPR. If you deal with any data on anyone under 16, stop reading this and call a lawyer; you need specialist advice.
In the UK, this protection may be reduced to only cover children up to the age of 13.
Automated profiling and decisioning
We are entering an age where machine learning and artificial intelligence can analyse vast sets of data and derive subtle insights that can help inform decisions, ranging from whether someone can get a loan to whether they should be released from prison.
The GDPR reflects a nervousness about how this can affect the fundamental rights and freedoms of individuals and gives a right to anyone to challenge an automated decision and request that a human redo it manually.
This doesn't mean that automated decisioning is dead, far from it. You just need to think about what the impact will be if users start challenging your decisions. You should consider the volume of "negative" decisions and how likely individuals are to challenge – including if someone decides to start a Facebook campaign to get everyone who was turned down to go back to you and challenge your decision.
See Article 22.
Contracts
There are new requirements for what needs to be in the contract between joint controllers and between controllers and the processors they use.
If you provide Software-as-a-Service to other companies, you are most likely a Processor for your customers. If you use NewOrbit to host and manage your software, then NewOrbit is a Processor for you and Azure and Postmark are, in turn Processors for NewOrbit.
There is also the concept of Joint Controllers where two different entities both "own" the data. The definition of joint controllers is complicated and you should seek legal advice if you think it applies to you; in the Article29 Working Party Opinion it stresses the need for a substantive and functional approach in determining whether a controller is independent or joint and while contractual allocation of responsibilities can be useful in assessing this issue, it is not determinative of the result. Instead, the main question is whether the two data controllers share a common purpose or means. For example, a tax authority will clearly be an independent data controller to the disclosing employer. In contrast, the Opinion considers that a pharmaceutical company sponsoring clinical trials, and the company running the trials, may be joint controllers as there may be a great deal of commonality in their activities. See: http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf
You will almost certainly need to amend the contracts between all Controllers and Processors. In the case of Processors like Azure or Postmark, this may happen by them changing their T&Cs.
There are some key principles around the contracts that you should bear in mind;
- The GDPR seeks to establish a clear line of responsibility; If you are the Controller, it is your responsibility to ensure that all your Processors adhere to the GDPR – whether they are in the EU or not. This includes ensuring you have a clause in the contract that, in turn, requires your Processors to ensure that any Processor they use complies with the GDPR. See Article 28.
- There is a concept of joint liability where you may end up liable for failures caused by another Processor or Joint Controller, so ensure you have appropriate safe guards in place. See Recital 146 and Article 82.
- Responsibilities between Controllers and Processors must be clearly delineated.
The ICO is supposed to be providing a set of standard clauses that can be inserted into existing contracts. However, at the time of this writing, the consultation period has only just started so it may be a while.
It is also likely that industry-specific guidance will be developed and that related certification schemes will be introduced over time. These may in the fullness of time provide a shortcut to "being compliant". Unfortunately, at the moment it's up to you to obtain appropriate legal advice to ensure you are compliant within your particular circumstances.
If NewOrbit hosts and manages your software, we will work with you to update the contract between us to reflect the GDPR, including covering things such as the use of Azure. However, you may still need to update your contracts with your customers and partners. If your customers are the Controllers and you are the Processor, you may need to get your customers consent to NewOrbit using Azure, Postmark etc. See Article 28 point 2.
Processes
There are some important processes you need to implement in your business in order to comply with the GDPR. Some are explicitly to do with the law, others are required indirectly in order to be secure from internal as well as external attacks.
Record keeping and risk assessment
Article 30 requires you to keep records of the kind of processing you do, including things such as why you are doing it, what data is involved, how you are protecting it, a risk assessment and so on.
If you are fewer than 250 employees in your organisation, you are theoretically exempt from the need to keep records. This very narrow exemption has led to a wide-spread myth that small organisations are exempt from most of the GDPR, which is emphatically not true. Indeed, article 5 introduces a new concept of accountability, which introduces an obligation on any organisation to be able to demonstrate compliance with the core principles of the GDPR.
In addition, if your processing is high-risk, you need to carry out an Impact Assessment (Article 35). But how do you know if your processing is high risk if you haven't done the assessment yet? So, you may as well make it a habit to carry out the impact assessment and file it with the extra bits of data, so you comply with both Article 30 and 35 and ignore the exemption.
Also note that if your assessment concludes that the processing is high risk then you need to talk to the ICO before you proceed (Article 36).
Data Loss
In order to reduce your risk of accidental or malicious data loss, you should implement internal processes that reduce the risk of data being mishandled or leaked. This means restricting who can access what data. In smaller organisations, this is often a significant culture change that will require sponsorship from the top. The post aimed at Operations people has more details on the kind of processes that should be implemented, as it will typically be managed by those individuals.
You should also look at things like ensuring your employees' laptops are encrypted, that there are strict rules about how to send data to and from customers (no more personal data in spreadsheets attached to emails please) and so on.
If you are a NewOrbit customer, we are working on a set of template processes that you can adopt in your organisation, which reflect the role of NewOrbit as well the role of the people in your own organisation.
Dealing with data breaches
Article 33 requires you to report data breaches to the ICO within 72 hours of you becoming aware of them. Article 34 requires you to notify the affected individuals "without undue delay", when the breach is "likely to result in a high risk to the rights and freedoms of natural persons". Finally, Recital 78 makes it clear that you have to implement the appropriate organisational and technological measures to be able to know when a breach has occurred.
Note that the ICO has clarified that the Article 33 requirement to notify it only applies if there is "risk to the rights and freedoms of natural persons" (note the omission of "high"). See https://iconewsblog.org.uk/2017/09/05/gdpr-setting-the-record-straight-on-data-breach-reporting/.
There are also certain provisions regarding notifying users directly about "disproportionate effort", which may allow you to use newspaper adverts etc instead of directly communicating, but if you are in that situation you probably already know this.
The key thing here is that you will need to report data breaches, quite likely to your customers, very quickly after they happen. In order to be able to do that, you need prepare your organisation emotionally and you need to have clear, well-defined processes in place to report, assess and manage a breach.
Data Breaches are on the rise and, despite all the protections you put in place, you only have to get it wrong once and the attackers only need to get it right once. The cards are stacked against you and you need to think when not if. Also remember that losing one person's data is also a breach; have you ever experienced that situation where an email with personal data went to the wrong person? Or someone had a laptop stolen? Or lost a USB stick? Some of those situations, depending of course on the specifics and how prepared you were, may be a data breach under the GDPR and will require reporting. There is no "triviality limit" on the reporting to the ICO, only a risk limit.
You need to prepare for when it happens, not if.
For an example of how to handle a breach well, see https://www.troyhunt.com/disqus-demonstrates-how-to-do-data-breach-disclosure-right/.
Emotional preparedness
The emotional process people involved in a data breach typically go through has been likened to the five stages of grief; denial, anger, bargaining, depression and acceptance. This is why organisations often try initially to hide the breach, lash out and so forth, only after some time accepting ownership and doing the right thing. The problem is, with only 72 hours to get all your ducks in a row, you simply do not have the time to go through those stages after a data breach has occurred.
You therefore need to spend some time at the management level, including the most senior people in the organisation, to work through what you will do when there is a data breach. Discuss roles and responsibilities, discuss how it will impact your customers' and the public's perception of you in detail and discuss what the best things you can do as an organisation to retain or regain that trust.
When you have time to discuss this calmly, you invariably find that you need to be transparent and open from the start – but you are very unlikely to come to that conclusion in the middle of dealing with a breach for which you were not prepared.
Once you have decided that you will be open and transparent, you need to think about how you are going to go about it. Are you going to involve external PR agencies or external security agencies for forensics? Decide ahead of time, select the relevant companies so you know who they are; it'll be much easier when you are not actually in the middle of responding to an actual breach.
Process preparation
Have a clear, internal process for how to respond to a data breach; Make it clear how anyone in the organisation reports a suspected data breach, ensure there is clear ownership, communication and that there are escalation rules in place so that everyone knows what they need to do.
If you have a public-facing system, consider putting in place a "responsible disclosure" program that gives external people a secure and easy way to tell you if they think they have found a vulnerability in your software.