Skip to main content

Privacy Risk Assessment Template

Privacy risk assessment is an iterative process that outlines risks and their consequences, allowing organizations to prioritize these risks based on predefined criteria.

Privacy Risk Ingredients​

  • Asset: Something of value that requires protection.
  • Vulnerability: A weakness in a system, or process that can be exploited.
  • Threat: A potential danger that could exploit a vulnerability.

Standard for Privacy Risk Assessment ISO/IEC 27005:2022​

This document is based on the methodology outlined by ISO/IEC 27005:2022 (illustrated below)

More information about ISO/IEC 27005:2022

This methodology employs an iterative approach to conducting risk assessment, allowing for an increased depth and detail of assessment at each iteration. This ensures that risks are appropriately assessed throughout the project lifecycle. While other risk management methodologies are available, the choice of ISO/IEC 27005:2022 is driven by its well-established nature and its support for information security, cybersecurity, and privacy risk management.

Prompt

Elements of Privacy Risk Assessment​

0 - Context Establishment​

  • Defines the context and scope for the risk assessment.
  • Identifies the factors that can influence the risks.
  • Sets the criteria against which the risks will be assessed
Elements of context establishment
  1. Scope and Boundaries of the risk assessment process.
  2. Basic Criteria including the approach for risk assessment, risk evaluation, and consequences.
  3. Risk Acceptance Criteria such as the risk tolerance level.
  4. Organization for Risk Assessment including the roles and responsibilities, resources, documentation, and communication and reporting mechanism.
  5. Monitoring & Review of the context on a regular basis to ensure that it remains relevant and up-to-date.
  6. Communication and Consultation with relevant stakeholders to ensure that the risk assessment process is transparent and inclusive.

1 - Privacy Risk Identification​

There are 2 approaches:

  1. Event-based approach: risks can be identified and assessed through an evaluation of events and consequences.
  2. Asset-based approach: risks can be identified and assessed through an inspection of assets, threats and vulnerabilities.

Asset Identification and Valuation​

Create a comprehensive list of assets.

More information about assets

An asset is anything that has value to the organization and therefore requires protection.

  • Examples: services, networks, data and infrastructure.
  • The level of detail used through asset identification can be refined in further iterations of the risk assessment.
  • Some assets are more critical than others.
  • Each asset is subject to a valuation process. The value is determined by the replacement value of the asset and the consequences of loss or compromisie of the asset, including legal consequences from the disclosure, modification, non-availability and destruction. The higher the value, the more important the asset.

Vulnerability and Privacy Threat Identification​

Create a comprehensive list of vulnerabilities and threats.

More information about vulnerabilities and threats.

Identifying vulnerabilities involves a systematic process of evaluating potential weaknesses in systems, processes, or practices that could lead to privacy breaches or unauthorized access to personally identifiable information (PII). A security analyst for example can identify vulnerabilities by scanning the system with automated tools, or manually.

Options for privacy threat identification:

  • Use LINDDUN's thread knowledge base which consists of a comprehensive and detailed description of key privacy threat characteristics.
  • A list of privacy threats (called failure modes) for machine learning along with the corresponding data protection principles and controls are available in: "Data Protection by Process: How to Operationalize Data Protection by Design for Machine Learning".

The organization needs to pinpoint overall risk origins, areas of impact and potential consequences. It is essential to consider sources, whether or not they are within the organization's control. Identifying risk sources aids in recognizing threats. While a risk source is where a risk originates, a threat is any event that could potentially arise from the risk source and cause harm to organizational assets.

2 - Privacy Risk Analysis​

Categorize each risk with its appropriate severity level (consequence) and probability and estimate the risk level.

Techniques for Risk Analysis​

  1. Qualitative, using a scale of qualifying attributes (e.g. rare, moderate, likely)
  2. Quantitative, using a scale with numerical values (e.g. monetary cost, frequency or probability of occurrence)
  3. Semiquantitative, using qualitative scales with assigned values.

Risk Level Estimation​

privacy_risk(threat, asset) = likelihood(risk) * consequence(risk)

More information about risk estimation

Example of estimation of likelihood of a risk materializing which involves the assignment of values within a small interval ranging from 1 to 5:

  1. Rare
  2. Unlikely
  3. Moderate
  4. Likely
  5. Almost certain

Similarly, an understanding of the potential consequences can be expressed as:

  1. Insignificant - will not cause serious harm
  2. Minor - can cause harm, only to a mild extent
  3. Significant - can cause harm that may require attention, but limited treatment
  4. Major - can cause irreversible harm that requires attention
  5. Severe - can result in fatality

This assessment is susceptible to human assessor bias, and while some subjectivity is inevitable, bias can be mitigated by referencing past relevant events. Considering the frequency of past threats can help anticipate their likelihood, assuming future occurrences won't deviate significantly from historical patterns. The likelihood assignment also depends on the ease of exploitation by skilled attackers and is influenced by existing controls' effectiveness. Identifying and assessing the functionality of current controls is crucial, as an improperly implemented or malfunctioning control could itself become a vulnerability and pose a threat.

3 - Privacy Risk Evaluation​

Compare the identified risk levels against a set of criteria established during the initial context establishment, and these criteria may be subject to review throughout the assessment process.

A popular approach for assessing risk levels involves the use of a risk matrix. In this matrix, each cell represents a particular combination of likelihood and consequence values. It's important to note that ISO 27005 does not specify a standard risk matrix. Therefore, organizations have the flexibility to develop their own matrices tailored to the unique characteristics of their activities. Example of color code for risk matrix:

  • Green or low risks: may be treated by Acceptance.
  • Yellow or modest risk: must be treated only if additional cost-benefit analysis is carried out. Treatment by acceptance is possible.
  • Orange or tangible risks: must be treated soon; treatment by acceptance is prohibited.
  • Red or high risks: must be treated as a matter of urgency; treatment by acceptance is prohibited.
More information about risk matrix

While risk matrices may vary in their formats, they consistently feature two axes: one measuring the likelihood of a risk, and the other measuring its consequences. To render the matrix meaningful, a minimum of four risk levels is required (very low, low, moderate, high).

4 - Privacy Risk Treatment​

The treatment process entails choosing one or more options to confront the identified risks.

More information about risk treatment

Common options include implementing new controls to decrease likelihood or consequence, transferring risks to other parties, or accepting risks.

When selecting options, it is crucial to consider not only the outcomes of the assessment phase but, if feasible, also the anticipated costs of implementing those options and the expected benefits resulting from them. Additionally, due consideration should be given to relevant legal and regulatory requirements.

Other frameworks for privacy and security threat modelling
  • LINDDUM provides a rich catalog of privacy threat types to investigate a wide range of complex privacy design issues and enable to identify them in your software architecture.
  • STRIDE is a security threat modeling approaches that can be used as a framework for ensuring secure application design. This method is intended more for searching for technical security vulnerabilities.
  • DPIA (Data Protection Impact Assessment) is all about identifying and minimizing risks associated with the processing of personal data. DPIA is the name used for impact assessments in the European Union's General Data Protection Regulation (GDPR). The DPIA requirement is covered in GDPR articla 35 and article 22 FADP, and required where processing is likely to result in a high risk to the rights and freedoms of natural persons. A software provided by CNIL is available.
  • PIA (Privacy Impact Assessment) is used for analysing how personally identifiable information is collected, used, shared and maintained.