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.
What is SaaS?
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.
SaaS & GDPR compliance: who’s responsible?
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 importance of a DPIA
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?
When you need a DPIA and what it includes
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:
Innovative technology or use of technology to process data, such as AI (artificial intelligence)
Denial of service based on automated decision making
Large-scale profiling of individuals
Processing of biometric or genetic data
Data matching, including the combining, comparing or matching of personal data from multiple sources
Invisible processing where data has been collected from a source other than individuals without providing a privacy notice
Geo-location or behavioural tracking
Targeting of vulnerable subjects, such as children
Risk of physical harm if a data breach occurs
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:
Why a DPIA is necessary
A description of the data processing
The consultation process undertaken (or why such a process was unnecessary)
An assessment of necessity and proportionality (justifies data processing and shows GDPR compliance, especially regarding individuals’ rights)
Risk identification and assessment
Steps taken to reduce risks
Sign-off by DPO (data protection officer)
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 Relentless GDPR 24/7. This includes DPIAs in its Business and Enterprise packages.
Becoming and staying compliant
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
GDPR mandates the consideration of the impact of any processing activities when developing a new product, technology or service should be taken into account and from the beginning and throughout the life cycle of the product. Security and privacy measures should be integrated into the project, rather than an afterthought in a post design “checkbox” exercise. Companies and organisations who acted quickly and proactively to implement the new regulatory requirement, are in pole position to ensure their products and services are compliant for the new, world GDPR era.
The origins of data protection by design and it’s seven principles
The concept of data protection by design is far from a new concept, with some of the initial discussion and considerations for the topic extending back as far as the 1970’s. What is new is the fact that Regulation (EU) 2016/679 (General Data Protection Regulation – GDPR) now mandates organisations to take privacy by design into account from the conception of a new product, technology or service (Article 25), rather than on a self regulatory basis as it was under the previous regime of Directive 95/46/EC (recital 46). The shift from a recital to a fully-fledged article, imposing a legal obligation is a positive step forward for data protection as a whole.
The modern version of data protection by design (and default) can be traced back to seven principles of privacy by design,
Proactive not reactive, preventative not remedial
Being proactive means that data privacy risk should be foreseen, be at the centre of planning and mitigated before they can manifest rather than rectified on a reactive basis. This ancillary benefit of this type of approach is potential protection from public exposure of data privacy issues which could cause reputational harm (e.g., Marriott Hotel Group breach From the initial conception design of developing a new product, technology or service, organisations should begin to plan the implementation of data-protection-enhancing measures
A clear commitment, at the highest levels, to set and enforce high standards of privacy − generally higher than the standards set out by global laws and regulation.
A privacy commitment that is demonstrably shared throughout by user communities and stakeholders, in a culture of continuous improvement.
Established methods to recognise poor privacy designs, anticipate poor privacy practices and outcomes, and correct any negative impacts, well before they occur in proactive, systematic, and innovative ways.
Privacy as the default
The highest settings of privacy should be enabled by default for the user when they utilise any system or access any service or system. This means that if the user does nothing to change the standard settings, their protection remains full. This guarantees that no action is required on the part of the user to protect their privacy.
Privacy by default also expands to data retention periods: personal data should only be kept and stored as long as it is necessary for the operation of the product or service, and this often translates into creating the mandated data retention schedule and the design and testing of processes for the operation of executing retention periods. Products, technologies and services should by default protect individuals’ data to the maximum, even if organisations may still want to include options where the data subject can disable these measures. Presenting data subjects with choice over what happens with their data is the cornerstone of any new data protection administration within a forward thinking organisation.
Purpose Specification – the purposes for which personal information is collected, used, retained and disclosed shall be communicated to the individual (data subject) at or before the time the information is collected. Specified purposes should be clear, limited and relevant to the circumstances.
Collection Limitation – the collection of personal information must be fair, lawful and limited to that which is necessary for the specified purposes.
Data Minimisation − the collection of personally identifiable information should be kept to a strict minimum. The design of programs, information and communications technologies, and systems should begin with non-identifiable interactions and transactions, as the default. Wherever possible, identifiability, observability, and linkability of personal information should be minimised.
Use, Retention, and Disclosure Limitation – the use, retention, and disclosure of personal information shall be limited to the relevant purposes identified to the individual, for which he or she has consented, except where otherwise required by law. Personal information shall be retained only as long as necessary to fulfil the stated purposes, and then securely destroyed.
Privacy measures should form the foundation stone upon which the whole system/service is built upon rather than being glued on at the end of the development cycle. The advantages to “securing” these measures are that data protection becomes an essential part of the product, technology or service, affording the highest degree of protection from the very start.
A systemic, principled approach to embedding privacy should be adopted − one that relies upon accepted standards and frameworks, which are amenable to external reviews and audits. All fair information practices should be applied with equal rigour, at every step in the design and operation.
Wherever possible, detailed privacy impact and risk assessments should be carried out and published, clearly documenting the privacy risks and all measures taken to mitigate those risks, including consideration of alternatives and the selection of metrics.
The privacy impacts of the resulting technology, operation or information architecture, and their uses, should be demonstrably minimised, and not easily degraded through use, misconfiguration or error.
Full functionality, positive-sum, not zero-sum
Functionality of a product or service should not be compromised as a result of trade-offs from “false disagreements” such as privacy vs security, but rather an approach should be adopted where both can be achieved in a “win-win” situation.
When embedding privacy into a given technology, process, or system, it should be done in such a way that full functionality is not impaired, and to the greatest extent possible, that all requirements are optimised.
Privacy is often positioned in a zero-sum manner as having to compete with other legitimate interests,design objectives, and technical capabilities, in a given domain.Privacy by Design rejects taking such an approach – it embraces legitimate non-privacy objectives and accommodates them, in a innovative positive-sum manner.
All interests and objectives must be clearly documented, desired functions articulated, metrics agreed upon and applied, and trade-offs rejected as often being unnecessary, in favour of finding a solution that enables multi-functionality.
End-to-end security for the life-cycle of the product
Privacy by design must consider security from the “cradle to the grave”. Information is always afforded the appropriate security throughout the life cycle of the product (from collection to processing and finally destruction). There should be discrepancies where security measures are not applied to data processed. Choosing and implementing the correct levels of data security measures are applied to the product, technology or service from the beginning of the project is essential to meeting this requirement.
Security − Entities must assume responsibility for the security of personal information (generally commensurate with the degree of sensitivity) throughout its entire life cycle, consistent with standards that have been developed by recognised standards development bodies.
Applied security standards must assure the confidentiality, integrity and availability of personal data throughout its life cycle including, inter alia, methods of secure destruction, appropriate encryption, and strong access control and logging methods
Visibility and transparency
Data subjects who are having their information processed are entitled to be fully informed of what is actually happening with their personal data from the point it is collected to the point it is deleted. The GDPR takes an active role in heightening visibility and transparency for data subjects by increasing the rights over their personal data in Chapter III. Having strong processes for Chapter III rights such as Data Subject Access Requests or Right to Erasure requests is a vital step for the privacy by design approach.
Accountability – The collection of personal information entails a duty of care for its protection. Responsibility for all privacy-related policies and procedures shall be documented and communicated as appropriate, and assigned to a specified individual. When transferring personal information to third parties, equivalent privacy protection through contractual or other means shall be secured.
Openness– Openness and transparency are key to accountability. Information about the policies and practices relating to the management of personal information shall be made readily available to individuals.
Compliance – Complaint and redress mechanisms should be established, and information communicated about them to individuals, including how to access the next level of appeal. Necessary steps to monitor, evaluate, and verify compliance with privacy policies and procedures should be taken.
Respect for user privacy
Privacy for the user should be a central concern for the product, technology or service. The goal is to provide a user-centric experience, rather than one which harbours illicit data processing practices such as mass collection of data or invasive profiling.Having the data subject feel like they are king of the product, technology or service, rather than just a number, is also a good way to increase consumer confidence. Big-data is ever coming under increased attack for treating individuals like cattle, milking them for personal data which is then commoditised.
Consent– The individual’s free and specific consent is required for the collection, use or disclosure of personal information, except where otherwise permitted by law. The greater the sensitivity of the data, the clearer and more specific the quality of the consent required. Consent may be withdrawn at a later date.
Accuracy– personal information shall be as accurate, complete, and up-to-date as is necessary to fulfil the specified purposes.
Access– Individuals shall be provided access to their personal information and informed of its uses and disclosures. Individuals shall be able to challenge the accuracy and completeness of the information and have it amended as appropriate.
Compliance– Organisations must establish complaint and redress mechanisms, and communicate information about them to the public, including how to access the next level of appeal.
All organisations striving for greater customer utilisation of their products should be promoting greater privacy strategies.
Having good security measures in place is great but you can never be 100% safe from a data breach. A data breach could lead to an investigation from the Data Protection Authority (DPA) , resulting in potential enforcement action against your organisation and reputation / brand damage. Being prepared with a solid breach plan is essential.
You need to know how to
respond to a breach.
While it’s possible to do all of this in the event of one occurring, implementing the right actions when you consider the relatively short deadline to inform the Data Protection Authority (DPA) if you haven’t prepared your breach procedure in advance.
You also need to keep records of breaches and take action to reduce the risk of them happening again.
The GDPR also requires you to have appropriate security measures in place. Demonstrating that you’ve done this will not only help to avoid breaches, but will show that you’ve not been negligent in your approach.
Recognising a breach
The next vital aspect of this is detection. How do you detect a data breach? At the operational level, if your employees realise that they’ve exposed sensitive personal data through an error, that could be a breach detection. At the other end of the scale, security monitoring systems should highlight personal data breaches. That could also be classified as breach detection. To do this successfully involves having the correct level of controls in place, an essential requirement of GDPR,. A nightmare scenario is when you fail to detect the breach due to a lack of controls but a third party does discover it and goes public with it. This could lead to a maximum fine of 2% of global annual turnover or €10 million, whichever is greater.
Protecting yourself from cyber incidents The National Cyber Security Centre (NCSC) provides lots of useful and practical information on protection your organisation from cyber threats. Some useful resources include:
Weekly Threat Reports
Information for small and medium sized organisations
Small Charity Guide
Cyber Essentials certification
Some of these incidents may happen through human error and honest mistakes. They could also occur through carelessness and a lack of procedure or guidance. It is therefore essential that your organisation has a suitable data protection policy in place, and that all of your staff, including any volunteers, have completed GDPR and data protection awareness training.
Even when a crime has been committed against you it is your responsibility to follow the necessary procedures, as the breach involves personal data under your control. All staff must know how to recognise a breach and that they have a duty to make the organisation aware. Inform employees that they should report a suspected breach to an identified member of staff (possibly a Data Protection Officer) who handles the rest of the procedure.
When a breach occurs, the organisation should first establish:
the facts of what happened
what personal data was involved
the number of people likely to be affected
the likelihood and severity of impact on the people affected
Reporting a breach
After a breach has been escalated within your organisation, you must decide if you need to report it to the Information Commissioner’s Office. If you fail to notify a re portable breach it can result in a significant fine. When should a breach be reported? Not all breaches need to be reported to the ICO, but if the breach is likely to involve a ‘risk to people’s rights and freedoms’, it must be (Article 33). Such a risk would be one where the people involved could suffer adverse effects as a result of the breach. This depends on what was in the data and how it might be used to damage them, as well as the scale of the breach. The inappropriate disclosure of sensitive or confidential information could be reportable if it would have a negative impact on someone’s sense of privacy. Identify theft, fraud, financial loss and damage to reputation are other risks to rights and freedoms that could result.
The context, scale and level of sensitivity are more important than the nature of the breach. The same type of breach could be reportable or not, depending on the likely effect on individuals.
For example, accidentally sending a bulk email to invite a small number of people to a community event using the ‘to’ and not the ‘bcc’ field is unlikely to be a reportable breach. But sending a similar email to a group of people who are receiving mental health counselling from you would be, as the context identified health information about those people. If you are satisfied that there is no risk to anyone’s rights or freedoms, then the breach does not need reported. In coming to this conclusion, you should make clear the reasons for this decision. How is a breach reported? A breach must be reported to the ICO without undue delay and within 72 hours from when you became aware that a breach had occurred, where feasible. This 3-day limit applies whether the incident happens over weekends or holidays. You need to report to the local DPA and give details of the incident. Even if you haven’t established all of the facts you should still report within 72 hours. Don’t delay, as you will have the opportunity to provide follow up information. The helpline staff can assist with what to do next, whether you need to inform the individuals, and how to take measures to prevent re occurrence. As most DPA helplines are only available from 9:00 am to 4.30 pm Monday to Friday, you should report through their online facility if you need to do so at other times. What happens next? The Local DPA decides what happens next. Breaches are not routinely made public by the Local DPA. In some cases they will simply record the incident. In other cases they can investigate the circumstances that led to the breach. The outcome can range from no further action through to a monetary penalty in the rarer case of a serious breach involving negligent or deliberate action. Informing individuals There is also a requirement in the GDPR to inform individuals affected as soon as possible (Article 34). This will allow them to take precautions and protect themselves against any negative effects, such as identify fraud. The requirement to inform individuals is slightly higher than the need to report to the ICO. Compared to a “likely risk to individuals’ rights and freedoms”, you need to inform people if there is a “high risk”. This difference can be hard to judge. It’s best to take the view that if you need to report to the local DPA you probably need to also tell the individuals. The local DPO can tell you if you need to inform individuals, or require you to do so.
You need to clearly communicate to the people involved:
what personal information was involved
what risks are likely or possible
measures you’re taken or proposing to address the breach
your contact details where they can get more information
Whether you need to report a breach to the ICO or not, you should keep a clear record of every breach incident. The GDPR requires controllers to: document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken
The GDPR also requires organisations to be accountable and transparent. Under the security of processing, controllers and processors must put in place appropriate measures “to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” (Article 32).
Keeping a clear record of breaches will help you to meet accountability requirements and is an appropriate measure to ensure the security of processing.
These records also allow the Local DPA to verify that compliance with the reporting of relevant breaches is happening. You will also need to act on any breach to reduce the risk of recurrence. Identifying patterns or gaps in your practice is important, and keeping records shows that you’re taking responsibility for what happened. You can choose how you keep this record. It could be a long-form written document, or on a spreadsheet. It is advisable to record: the date that the breach happened when it was identified and by whom
if and when the Local DPA were notified (include a case number if given one)
the nature and circumstances of the breach
what types of personal information was involved
how many people were affected
likely effects of the breach, especially if there is evidence of effects
if a breach was not reported to the ICO, the reasons for this decision
remedial action taken to remedy the breach and prevent further occurrences any other information you think relevant
Relentless GDPR 24/7 compliance platform includes all the necessary tools to manage your data breach processes