Satori selected as a representative vendor in the Gartner Market Guide for Data Security Platforms →

Data Governance

Effective GDPR DPIA on cloud data warehouses

|Chief Scientist
Meeting GDPR requirements is important, not only for EU companies but also for any companies dealing with personal data belonging to EU customers, employees, and users. Part of complying with GDPR standards includes conducting a DPIA (Data Protection Impact Assessment) for all your high-risk data processing activities.   In this post we’ll discuss the conditions under which you must conduct a DPIA, as well as other situations in which, though not compulsory, conducting one may still be advisable, what a DPIA consists of, and how Satori helps complete one relatively easily.

 

Under which conditions MUST you conduct a DPIA?

The conditions which make a DPIA mandatory are a bit vague and leave some open to interpretation. When applicable, we will be using the ICO (UK Information Commissioner’s Office) standards, as they provide relatively extensive interpretations of the requirements
  1. If you’re using new technologies. The term “new technologies” is, of course, blunt. However, according to the ICO, new technologies does not mean technologies which are new to you but rather novel technologies or when using existing technologies to solve new problems.
  2. Tracking people’s locations or behaviors.
  3. Systematically monitoring a publicly accessible location on a large scale.
  4. Processing personal data related to:
    • Racial or ethnic origin
    • Political opinions
    • Religious or philosophical beliefs
    • Trade union membership
    • Genetic & biometric data which can uniquely identify a person
    • Health data
    • Sex life or sexual orientation
  5. Processing data that is used to make automated decisions which may have legal (or otherwise significant) implications for people.
  6. Processing children’s data.
  7. Processing data which could result in physical harm to the subjects if leaked.
For example, you should perform a DPIA for a COVID-19 tracking platform which stores locations of known patients, as it  tracks both people’s locations and health data.  

Under which conditions SHOULD you conduct a DPIA?

Even in cases where you are not specifically obligated to conduct a DPIA, having a  DPIA process in place for data processing activities can be a good practice to reduce risk and prevent liability issues down the road. In other words, it may help prove that you had a way to reduce risk of a data breach, but, more importantly, it may even prevent the aforementioned data breach. Tentatively, the Article 29 working party of EU data protection authorities published activity guidelines which may indicate when activities are high-risk (and therefore require a DPIA to be conducted). The “rule of thumb” offered by the ICO is that, if at least two of the following activities are being done, a DPIA is required, but this is a “soft” decision with no rigid criteria:
  1. Evaluation or scoring.
  2. Automated decision-making with legal or similar significant effects.
  3. Systematic monitoring.
  4. Sensitive data or data of a highly personal nature.
  5. Data processed on a large scale.
  6. Matching or combining datasets.
  7. Data concerning vulnerable data subjects.
  8. Innovative applications of new technologies or organizational solutions.
  9. Preventing data subjects from exercising a right or using a service or contract.
The ICO itself specified a more elaborate list of processing activities requiring a DPIA, but, in this case, meeting certain criteria may not necessarily mean that you must conduct a DPIA. Here are the processing activities that may necessitate a DPIA:
  1. Innovative technology: processing involving the use of innovative technologies or the novel application of existing technologies (including AI). A DPIA is required when this processing is combined with any of the criteria from the European guidelines.
  2. Denial of service: Decisions about an individual’s access to a product, service, opportunity, or benefit that is based to any extent on automated decision-making (including profiling) or involves special category data processing.
  3. Large-scale profiling: any profiling of individuals on a large scale.
  4. Biometrics: any processing of biometric data. A DPIA is required when this processing is combined with any of the criteria from the European guidelines.
  5. Genetic data: any processing of genetic data, except for data  processed by an individual GP or health professional for providing health care directly to the data subject. A DPIA is required when this processing is combined with any of the criteria from the European guidelines.
  6. Data matching: combining, comparing, or matching personal data obtained from multiple sources.
  7. Invisible processing: processing of personal data that has not been obtained directly from the data subject in circumstances where the controller considers that compliance with Article 14 would prove impossible or involve excessive effort. A DPIA is required when this processing is combined with any of the criteria from the European guidelines.
  8. Tracking: processing which involves tracking an individual’s geolocation or behaviour, including but not limited to the online environment. A DPIA is required when this processing is combined with any of the criteria from the European guidelines.
  9. Targeting of children or other vulnerable individuals: the use of personal data belonging to children or other vulnerable individuals for marketing purposes, profiling, or other automated decision-making, or offering online services directly to children.
  10. Risk of physical harm: processing in which a personal data breach could jeopardize the physical health or safety of individuals.

When is the DPIA conducted?

The DPIA is prepared before and during the planning phase of the data processing operation. By preparing the DPIA before data processing, you assess the risks in a phase where you can influence the project and integrate the data protection into the data processing project, rather than adding it as a patchy cover.  

What does a DPIA look like?

A DPIA can be an internal process or can be outsourced, but conducting one is always the organization’s responsibility. The key person involved in a DPIA process is the organization’s DPO (of course, with the help of all relevant stakeholders in the project such as information security, legal, and engineering). The DPO may decide to outsource the process, set guidelines for the process, decide whether a DPIA project should be performed, and more. The process itself can be quite flexible, as long as it assesses the risks involved with the new data processing project. A suggested template for a DPIA from the ICO can come in handy, as it lays out a manageable process for the DPIA, which will highlight the main risks and offer mitigations. The process consists of the following steps:
    1. Identifying the need for a DPIA. It may be useful to look at some of the suggested criteria above to explain why the data processing project requires (or does not require) a DPIA.
    2. Description of the data processing plan. This is an overview of the project data architecture which will describe the nature, scope, context and purpose of the data processing.
    3. Consultation process. Lists the different stakeholders involved which will be consulted within this DPIA.
    4. Assessing necessity and proportionality. Here, we reach the heart of assessment by examining the process against alternatives and ensuring it is in-line with our data protection goals.
    5. Identifying and assessing risks. Now that we have the right people for the discussion and the process itself, we identify data protection risks in the project and put them in risk buckets (low, medium, and high) according to their likelihood of producing harm and the risks’ severity.
    6. Identifying measures to reduce risk. Once we have identified the main risk factors, we can discuss how to mitigate or reduce them. This step is where measures like Satori kick in to reduce risk of the project getting out of control  and move the project  forward.
    7. Sign off and record outcomes. This is the summary of the decisions made, action items, and risks approved and the procedure of setting up a continuous review process. 

How Satori helps with a DPIA

As a company, we feel obligated to help organizations push forward their data processing projects and thus enhance innovation and increase their value. Our main contributions to any data processing project will be implementing effective risk-reduction measures for data processing projects, enabling these projects to move forward. Moreover, we believe that data engineers and people whose mission is enabling the organization to use data in the best possible way should do just that. Using Satori helps organizations achieve this efficient data utilization by reducing risks and enabling faster and safer data processing projects.  

Common risks in cloud data warehouse data processing projects

Cloud data warehouse solutions (such as Snowflake, BigQuery, and Redshift) eliminate many of the risks associated with data processing projects, such as physical security, operating system updates and patches, and maintaining the DB engine. However, several risks which require mitigation or, at least, reduction mechanisms remain. Here is a list of the main elements to consider when assessing risks for a DPIA project. Of course, the specific risks may vary depending on your project, architecture, and technologies used.  
Risk factor Description Risk reduction using Satori
Unauthorized data access Project data is accessible by users or teams which should not have access to the project. Satori helps reduce this risk both by enhancing visibility to the data flows (to show who accesses which data) and by adding fine-grained, easy-to-maintain permissions management for cloud data warehouses.
Over-privileged data access Similar to the above scenario but specific to users who should have some access to the project in some timeframe who maintain the privilege despite not needing access to it anymore. Satori provides reports which analyze over-privileged access configurations for cloud data warehouses.
Data access from external networks Access to the planned project’s data may be enabled from outside the organization’s network. In many cases, this is a necessity, as network access can only be set up for the entire cloud data warehouse. By using Satori, you can implement specific network access policies to deny access to specific data types (e.g. PII) or certain objects (e.g. this project’s databases, schemas, or tables).
PII Exposure Employees or other users who may be exposed to PII which they should not be exposed to. Satori offers clear visibility of access to sensitive data using our analytics layer in addition to our Just-In-Time data classification, as well as the ability to perform “Data masking on read” to eliminate PII exposure.
Geographic separation Employees from certain regions are exposed to data from other regions (such as non-EU employees exposed to EU natural persons’ details). Satori offers fine-grained access control on top of the cloud data warehouse capabilities, allowing creation of geo-based access controls.
Admin access to sensitive data Administrators of the DB systems (data engineers, DBAs, and others) may be exposed to sensitive data. Satori enables visibility and security that is decoupled from the data infrastructure itself and can alert or block such access attempts.
Cumbersome incident handling In the event of an incident (such as data leak), investigating can be cumbersome and may have limited logging capabilities, requiring extensive resources for the investigation. Satori decouples the security auditing of the cloud data warehouse from the data infrastructure itself, allowing extensive analytics for the data activities to enable easy incident response.
Function creep and data creep Over time, new functionalities and data will “creep” into the project and may change what types of data are stored, where they are located, and how they are stored This variation may change the project’s risks without addressing the added risk. Satori continuously classifies the data being transferred and can be configured to notify you when it encounters new types of data.
  As the table above demonstrates, Satori delivers a multitude of risk reduction and mitigation mechanisms  for new and existing data processing projects. If you’d like to discuss any of your new or existing data processing projects with us, we’d be happy to help you. Click here to schedule a 30 minutes personal demo.
Learn More About Satori
in a Live Demo
Book A Demo
About the author
|Chief Scientist

Ben is an experienced tech leader and book author with a background in endpoint security, analytics, and application & data security. Ben filled roles such as the CTO of Cynet, and Director of Threat Research at Imperva. Ben is the Chief Scientist for Satori, the DataSecOps platform.

Back to Blog