Conducting a DPIA before launching your new SaaS?

Conducting a DPIA before launching your new SaaS?

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

GET STARTED

Data Privacy By Design and Default Your Essential Guide

Data Privacy By Design and Default Your Essential Guide

What is data protection by design exactly?

 

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.

 

Data protection embedded into the design 

 

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.

 Relentless Privacy and Compliance Services  have a wide range of Data Privacy services for organisations of all sizes
GDPR Data Breach What You Need to know

GDPR Data Breach What You Need to know

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

 

  • Identify,
  • report and
  • 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.

It is mandatory to report certain breaches to the regulator – Find your National Data Protection Authority online. – within 72 hours.

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
  • Board Toolkit
  • 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 happened
  • 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

 

Keeping Records

 

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

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other