A Glossary of
Security and Data Privacy Terminology

What is Static Application Security Testing [SAST]?

Static Application Security Testing (SAST) is a technique to identify security vulnerabilities by scanning an application’s static source code. 

Scanning static code means scans are done on code as it is written, i.e., without running the code or application. This method enables code to be reviewed piece by piece early in the development process before applications are completed or launched.

SAST tools can be run each time code is submitted for review or in the CI/CD (continuous integration and continuous deployment) pipeline when new versions of software are pushed live. SAST tools recommend security improvements by identifying vulnerabilities such as unauthorized access risks, cyberattack risks, unsecured pass keys or API tokens, and outdated software packages. 

What is Code Scanning?

Code scanning is a technique used to proactively identify privacy risks, security vulnerabilities, or errors present within a software application's code.

Code scanning tools are typically run during the software development process to help ensure there are no privacy, security, or functionality issues with the code before it is pushed live. Engineering and DevOps teams can set scans to run each time new code is submitted for review or schedule periodic scans of all code to prevent issues before they occur.

Any issues identified are typically categorized and sent to the appropriate team for immediate resolution.

Code scanning has traditionally been used primarily to identify and resolve security vulnerabilities, but now there's a growing number of code scanning tools designed for identifying and resolving data privacy risks.

Since enforcement began for the EU's General Data Protection Regulation (GDPR) in 2018, data privacy regulation and enforcement has steadily increased globally, creating the need for proactive and automated privacy risk detection.

By scanning the code that runs websites, user-facing applications, and backend systems, privacy risks regarding data collection, usage, sharing, and storing can be automatically identified, eliminating the need for most manual assessments.  

Code Scanning Approaches

Static Analysis Security Testing (SAST) scans static source code to detect application vulnerabilities such as unauthorized access risks, cyberattack risks, unsecured API pass keys, and outdated software packages. Scanning static code means scans are done on code as it is written, i.e., without running the code or application. This method enables code to be reviewed piece by piece early in the development process before applications are completed or launched.

Privacy Code Scanning solutions scan static source code to automate full lifecycle data maps and enable programmatic privacy governance. Privacy code scanning can identify privacy risks at scale and in real-time because the logic for how personal data is collected, used, shared, and stored is written in the code running websites, user-facing applications, and backend systems. 

Dynamic Application Security Testing (DAST) identifies security vulnerabilities by testing code that is being run, i.e., during runtime, by simulating cyberattacks. DAST simulates cyberattacks that could be deployed on a live application in the web, on mobile, in the backend, etc. By subjecting the application to a library of known attacks such as cross-site scripting (XSS), SQL injections, and denial of service (DoS) and monitoring the response, DAST can identify security vulnerabilities that may not be detected by SAST. 

Interactive Analysis Security Testing (IAST) identifies security vulnerabilities by testing code during runtime, trying various inputs, and monitoring the outputs. This approach detects anomalous behavior that indicates exploitation of known or novel vulnerabilities within the application.

Source Composition Analysis (SCA) identifies an application’s dependencies on external code libraries / applications and checks them for known vulnerabilities that could impact the application’s security. As the use of open-source code libraries and applications grows, it is important to carefully examine each open-source component from a security perspective.

What is Data Protection Impact Assessment [DPIA]?

DPIA is a process that helps organizations identify and mitigate privacy risks. 

The objective of a DPIA is to investigate potential problems in advance so that they can be mitigated, thereby decreasing the likelihood of their occurrence and associated costs. Following that, organizations can take appropriate steps to mitigate and manage identified risks.

GDPR requires a Data Protection Impact Assessment (DPIA) when introducing new data processing processes, systems, or technologies. (GDPR Article 35)

DPIAs are critical for meeting the requirements for "data protection by design" and "data protection by default" as they help demonstrate compliance with data protection principles and the accountability principle. (GDPR Article 5.2, 25)

Conducting DPIAs before implementing or launching a new project involving the processing of personal data can help avoid non-compliance, the potential costs of a claim, and associated reputational damage.

When to do it?

GDPR requires DPIAs to be conducted 'prior to processing.' Therefore, organizations must ensure that no new projects are initiated before a DPIA is considered and, where necessary, conducted. As a result, determining whether a DPIA is required should be done early on as part of project management procedures.

Do I need a DPIA?

Ask yourself: Are you a controller or processor? 

The controller is responsible for performing a DPIA. 

Processors involved in relevant processing activities are required to assist under their contract with the controller, but they are not required to conduct DPIAs directly.

Ask yourself: What are the nature, scope, context, and purposes of the processing?

A DPIA is mandatory only if there is a high risk to data subjects' rights and freedoms or if otherwise required by law. (GDPR Article 35)

GDPR lists four situations requiring a DPIA:

1) A systematic and extensive evaluation of personal aspects of natural persons based on automated processing, including profiling, that would have legal or other significant effects on the persons.

2) Large-scale processing of special categories of data (Article 9.1) or personal data relating to criminal convictions and offenses (Article 10).

3) Systematic, large-scale public area monitoring.

4) Any processing on a list published by your competent supervisory authority or the European Data Protection Board.

This is a non-exhaustive list, and there are numerous data processing activities. Examples are provided in the list published by the EDPB (ex-data protection working party) Guidelines (Reference Below). Thus, it is essential to determine if your personal data processing activities fall into one of these categories.

You should consult with a DPO to identify these activities, as they should have the necessary experience and expertise.

If you do not have access to a DPO, you may contact the supervisory authority instead.

How to conduct DPIA?

Under Article 35(7) of the GDPR and the ICO's Code of Practice, the following steps must be taken:

1-Explain data processing activities and processing purposes 

2-Assess the necessity and proportionality of the processing activities in relation to the purposes 

3-Evaluate data protection risks 

4-Identify measures to address risks 

Even if a DPIA is not required for proposed processing activities, organizations must ensure that all proposed activities involving personal data adhere to GDPR principles.

After the DPIA:

Documenting agreed solutions is an essential part of the DPIA process. 

Findings will need to be communicated internally, and a plan should be agreed upon on how the proposals will be integrated into the project. Additionally, it will be important to follow up with the project team to ensure the agreed-upon changes are implemented and have the desired impact. Completed DPIA can also be used as a post-implementation tool for future data protection audits and updates to DPIA.

In conclusion, DPIAs should be considered whenever new technologies or processes involving the collection, use, and sharing of personal data emerge or when significant changes are made to existing data processing activities, even if only a portion of these projects are required to conduct a DPIA under the GDPR.

Reference:

Guidelines on Data Protection Impact Assessment (DPIA) and determining whether the processing is "likely to result in a high risk" for the purposes of Regulation 2016/679-DATA PROTECTION WORKING PARTY- https://ec.europa.eu/newsroom/article29/items/611236

What is Privacy Impact Assessment [PIA]?

Privacy Impact Assessments are used to determine the level of risk that your processing activities pose to individuals' rights and freedoms. Based on the results of this survey, you assess the project's privacy risks and implement appropriate mitigation measures and controls.

In short, PIA is a process that helps organizations identify and minimize the privacy risks of new projects or policies.

How is it different from Data Protection Impact Assessment?

While these terms are frequently used interchangeably, the term DPIA is clearly defined in the GDPR and includes specific elements (specified in article 35) that must be captured when a DPIA is conducted.

While Data Protection Impact Assessment is a legal requirement that is not always mandatory, all organizations that process personal data should have privacy impact assessment integrated as a valuable organizational practice.

While DPIA should be kept in a GDPR-compliant format, PIA can be kept in a more flexible format. A brief risk analysis or survey can be used as an example of privacy impact assessment and can be used to determine whether DPIA is required. 

PIAs are practical tools for identifying privacy risks and accelerating an organization's ability to manage data privacy and privacy processes.

How to do PIA?

PIA can be all-encompassing as it is a flexible process that must consider the balance between the risks and benefits of the processing activity.

Some laws in the United States may require you to conduct a PIA, and in that case, it should be considered that each state's laws and practices and PIA requirements must be addressed separately. PIA is not directly mentioned in GDPR.

For example, the California Privacy Rights Act (CPRA) establishes a fairly broad threshold for performing a PIA.

Data controllers must balance the risks and benefits of the processing activity and include context, the relationship between the controller and the consumer whose personal data will be processed, reasonable consumer expectations, and anonymized data in their PIAs. It is important that PIAs do not become pointless box-checking exercises.

Using a concise set of screening questions to determine the extent to which a PIA is required can help prioritize projects and maximize the use of limited resources. PIAs can also be used as auxiliary tools in the development of DPIAs.

You can automate this process by requiring project teams to describe their proposed data processing activities at a high level and answer a few key screening questions online.

For those who want to focus on the DPIA requirements of the GDPR, you can limit the screening questions to the high-risk areas defined in the GDPR, ICO lists, and related guidance.

In addition to screening questions, it is advantageous for the project kickoff documents to request fundamental information about the project context and participants. This information can serve as the foundation for descriptions of processing activities, consultations with interested parties, and risk assessments.

What is Data Flow?

Data Flow is the journey of data from the point of collection to where it flows to third parties throughout your organization.

Understanding the data flow allows us to map the data journey and enable businesses to manage and secure their customers' data fairly and securely. Implementing any type of security is difficult without thoroughly understanding the data lifecycle.

Data flow is the tracking of where data flows from source to destination, and it is possible to visualize data flow by asking the following questions about data management processes:

• What data exists?
• Where is it kept?
• Under what conditions is it kept?
• Where is it transferred? (if any)

When you can answer these questions thoroughly, we can safely assume that you have a comprehensive understanding of the data flow within your organization.

Understanding the Data Flow is a crucial step before performing Data Mapping and determining the regulations to which we will be subject, particularly when transferring data to third parties (third country or an international organization).

Components of Data Flows

The data flow has four fundamental components: data items, formats, transfer methods, and locations.

You will be able to build your data map based on those components.

1- Data items are information itself. 

It addresses the question: What information do you have about a data subject? For instance, if the transaction uses only one person's address, that address will be the transaction's data item.

2- Formats is the state in which data items are stored. 

You can fully comprehend the data flow by identifying all the actual data storage formats you utilize.

3- Transfer methods explain how physical or electronic data items are moved from one location to another.

E-mail, fax, or cloud storage? At this point, data flow takes on a physical form.

4-Locations are locations where data is stored and processed.

Data servers, cloud servers, portable hard drives, and any other physical location?It is critical to answer this question to find data quickly when needed.

‍

In conclusion, when we talk about data flow, we usually mean the movement of data from the point of data collection to third parties throughout the organization. The first step in safeguarding this data is comprehending the term "Data Flow" and visualizing its movement. You can start by visualizing the data flow and tracing its path from the source to the final transfer point.

‍

*Reference: IT GOVERNANCE PRIVACY TEAM. (2020). EU General Data Protection Regulation (GDPR) – An implementation and compliance guide, fourth edition. IT Governance Publishing. https://doi.org/10.2307/j.ctv17f12pc  (Data Mapping-Page 191,192)

‍