Staying GDPR compliant needs constant work. It requires a company to examine its practices and adopt an efficient system of data mapping and management. But what happens when a compliant company develops a new SaaS product? What must it do to ensure continued GDPR compliance before and after the launch date? This is where a DPIA (Data Protection Impact Assessment) comes in.
There are three main types of product stored in the cloud: infrastructure as a service (IaaS), platform as a service (PaaS) and Software as a Service (SaaS). The last of these, SaaS, accounts for the largest part of the cloud market and is still rapidly growing.
Among today’s popular SaaS products are Dropbox, Google Apps, Netflix, Slack and even us. Web-based email services like Gmail, Hotmail and Yahoo! Mail are some of the earliest SaaS examples.
SaaS avoids users having to download software onto their PCs. They’re not forced, either, to download the same programme again and again for updates. SaaS providers have better access to their products and can update regularly, which is helpful for all concerned.
While a company is developing a new SaaS product, it must consider GDPR compliance. One of the chief factors in complying with GDPR is the status of the SaaS company and whether it is a data controller or processor.
To remind you, a data controller is the body that decides the how and why of data processing – the means and purpose. The processor only carries out the processing on behalf of the controller. Both parties have legal obligations under GDPR.
If a company develops SaaS software and supplies its product to customers in B2C fashion, it is both controller and processor. An SaaS provider that works on a B2B basis with other companies who front products is only a processor. SaaS providers often work with independent cloud providers. The latter will be processors or sub-processors, depending on how many companies are in the chain.
The company that delivers the SaaS product to the final customer is a controller, and as such, carries a greater burden of responsibility in the GDPR process. Part of the value of a DPIA (Data Protection Impact Assessment) is that it reminds controllers that a contract defining data responsibilities must exist with any processors. What else does a DPIA do?
A DPIA is always needed if the processing of data in a project is likely to result in high risks. The GDPR defines such risks in Article 35, paragraphs 1, 3 and 4. A list published by the ICO includes various circumstances that would trigger the need for a DPIA:
For the company that decides the means and purpose of data collection – the controller – a DPIA is often a vital part of GDPR compliance. The DPIA analyses, recognises and minimises any data protection risks attached to a new project. If the project is a joint venture with more than one controller, the companies involved may conduct a joint DPIA.
Any company planning to bring an SaaS product to the market should start the DPIA early in the process. That way, the development stage can take risk factors into account. The GDPR does not strictly specify how a DPIA should look or what it must include, but it has to show rigour. Among the topics a DPIA might cover are the following:
A company planning to launch an SaaS product could use an ICO template for a DPIA or create one of its own. Another option for GDPR compliance among small to mid-sized companies is software like PrivIQ. This includes DPIAs in its Business and Enterprise packages.
If your company is planning a new SaaS launch, chances are you’re a controller under GDPR and will need a DPIA. With any luck this article will clarify some details for you and point you in the right direction. Whatever you do, do carry out impact assessments where necessary and either stay or become GDPR compliant. If you’re behind the curve on any of this, get started now!