Conducting and Operationalizing Privacy Reviews

On PRAs, PIAs, DPIAs, TIAs, …

Privacy concerns have become increasingly top-of-mind for many stakeholders today. This is true not just for privacy advocates and privacy practitioners, but also for consumers, business customers, regulators, and the mainstream media.

As a long-time privacy practitioner, I can’t count the number of times I’ve heard a startup CEO, a product or business leader, an engineer, or an app developer admit, after suffering a privacy incident, that they simply failed to account for privacy in building their product, project, app, initiative, or system.

Privacy reviews solve for this lack of privacy foresight. They force organizations to operationalize a process that requires them to examine the privacy implications of their products, projects, initiatives, or systems.

This post explains privacy reviews — what they are, their different types, their purposes and uses, their main elements, and how to operationalize them.

I. What Is A Privacy Review?

At a simplistic level, a privacy review (PR) is a process for analyzing privacy issues. In practice, privacy reviews have several flavors.

First, there are privacy impact assessments (PIAs). NIST defines a PIA as follows:

“A PIA is an analysis of how information is handled to ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy; to determine the risks and effects of creating, collecting, using, processing, storing, maintaining, disseminating, disclosing, and disposing of information in identifiable form in an electronic information system; and to examine and evaluate protections and alternate processes for handling information to mitigate potential privacy concerns. A privacy impact assessment is both an analysis and a formal document detailing the process and the outcome of the analysis.”

A data protection impact assessment (DPIA) is a specific type of PIA that is required under the GDPR’s Article 35. In particular, the GDPR requires data “controllers” to assess a new technology’s proposed data processing impact whenever there is potential high risk processing. Controllers must conduct DPIAs before the proposed data processing.

A transfer impact assessment (TIA) is a type of privacy review for cross-border data transfers from the EU, recently required by the EU Data Protection Supervisor (EDPS) following the invalidation of the EU-US Privacy Shield.

Another type of privacy review is a privacy risk assessment (PRA), which is a process of identifying the privacy risks, determining their probability of occurrence, their resulting impact, and the additional safeguards to mitigate such risk. In other words: risk = (impact x likelihood) — mitigation.

Various global data protection laws require privacy reviews in different forms. For example, the newly passed California Privacy Rights Act (CPRA), the Canadian Privacy Act, and US government sector privacy laws such as the E-Government Act all require privacy reviews.

A quick note on the distinction and conflation between impact and risk

Privacy practitioners often conflate and use the terms PRA and PIA interchangeably. That said, there is a clear distinction between risk and impact. Impact focuses on effects or harms, whereas risk takes impact, likelihood, and mitigation into account. For a good discussion of privacy impacts (harms), see Daniel Solove’s A Taxonomy of Privacy. For a privacy risk assessment methodology, see NIST’s Privacy Risk Assessment Methodology (PRAM) and Jason Cronk’s application of FAIR to privacy.

II. What Is A Privacy Review’s Purpose & Use?

A privacy review has multiple purposes, depending on which type is in play. A PRA is used to identify privacy threats, assess the impact of such privacy threats, identify mitigating controls, and assess the overall privacy risks posed by such threats. In contrast, a PIA focuses on the threats or harms.

A privacy review facilitates informed decision-making about a proposed data processing, avoids costly or embarrassing privacy mistakes, and demonstrates that an organization is attempting to minimize its privacy risks and problems.

At a baseline level, a privacy review can be used to document compliance with laws that require them, and to identify other privacy law requirements like the need for data processing agreements, security controls, data minimization, etc., depending on the underlying data processing facts. For example, a privacy review can reveal that a new tool or vendor needs to be included in the company’s data inventory process to comply with records of processing requirements.

Many entities also use a privacy review for different use cases: product development and rollout, project assessment, vendor or third-party assessment, general risk awareness (including determining privacy incident risks), and, now, EU cross-border data transfers.

III. What Are Some Factors to Consider in Creating a Privacy Review Template?

Threshold. When creating a privacy review template, it’s important to start with the threshold question of whether personal information is involved. Data privacy issues arise where there is personal information. The threshold question of whether personal information is involved determines whether a privacy review is needed.

Scope. Next, it’s important to define the privacy review’s scope.

Should your privacy review process apply to product development, project assessment, vendor/third-party assessment, or data transfers? The answer is likely yes given all of these could potentially involve personal data processing. That said, you might also find yourself in a position where you’d only need to create a specific type of privacy review. For example, your organization might already have a robust privacy review process in place, but you were tasked with creating the TIA subprocess in light of the recent EDPS guidance requiring TIAs for EU cross-border data transfers.

Because security of personal information is a critical privacy component, your privacy review template should incorporate a security review. Operationally, it can link to or merge with an existing security assessment process. You will need to collaborate with your organization’s security team to ensure appropriate coverage.

Part of scoping includes determining the type(s) of privacy review you need for your organization. This is partly determined by data processing activities and compliance requirements. To determine whether you have any specific privacy review compliance requirements, you will need to have a good understanding of the applicable data protection laws. These requirements can be found straight from the statute, but also from regulatory guidance. If you have such privacy review compliance requirements, incorporate them into your privacy review process. For example, a DPIA applies to a controller’s high risk processing, whereas a TIA applies to EU cross-border data transfers.

With GDPR, DPIAs need to contain the following requirements: a systematic description of the proposed data processing; the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller; an assessment of the necessity and proportionality of the processing operations in relation to the purposes; an assessment of the risks to the rights and freedoms of data subjects; and the proposed measures for mitigating the risks, including safeguards, security measures, and mechanisms to ensure the protection of personal data and to demonstrate compliance with the GDPR.

Other data protection laws with privacy review requirements will have their own specific substantive requirements.

Audience. Identify the different audiences for your privacy review and draft your privacy review template accordingly. Depending on the organization, will business owners need to fill out the privacy review questionnaire or will this be handled by your privacy practitioners? If your organization has a small privacy team, you may need to outsource information gathering to business owners or “privacy champions” to operationalize your privacy review process. If so, the privacy review template should be written in plain English, eliminating any technical or legal jargon or at least defining such jargon in plain English when its use is unavoidable. That said, if your entire privacy review process is handled by a team of privacy practitioners, you may choose to use privacy jargon for accuracy. Privacy review templates fail to get properly operationalized when drafters fail to account for the different users in creating the template.

Attorney-Client Privilege. There is an ongoing debate on whether privacy reviews should be conducted under attorney-client privilege. There are some pros and cons to doing so. The obvious advantage to conducting privacy reviews under privilege is that it may protect your organization later on from having to reveal potentially incriminating information about its data processing. I say may because different jurisdictions treat privilege differently. Multinational companies and their in-house counsel grapple with privilege issues every day.

One disadvantage to requiring attorney-client privilege is that many organizations don’t have access to privacy counsel. There is a shortage of privacy lawyers, which creates a backlog of hundreds of pending privacy reviews, even in large companies that have privacy counsel. In a startup context, this shortage has prevented privacy reviews from getting operationalized at all.

My personal take on this is: if an organization has access to privacy counsel who can perform privacy reviews, then they should operationalize their privacy reviews under attorney-client privilege. Otherwise, the regulatory risks of noncompliance (not to mention the resulting brand risks) in failing to conduct privacy reviews is more likely to materialize than the likelihood that such privilege will later on protect the organization.

IV. What Are The Main Elements Of A Privacy Review Template?

Privacy reviews typically cover the following main elements:

Introduction and Instructions (User Manual)

Privacy reviews start off with a short introduction. This section provides instructions and the template’s scope. It covers the following points: why the organization conducts privacy reviews, what types of projects require privacy reviews, when a privacy review is required, who is involved in conducting a privacy review, and how the privacy review process works.

What product/project/system is involved?

This section asks for information about the product, project, or system whose data processing is being assessed. This often includes the goals of the project for context and the business owner’s contact information for any follow up questions. This is a good place to check for any historical privacy reviews on the same or similar product, project, or system.

What personal information is involved?

The next section typically asks about the nature of personal information involved, including whose information (e.g. employee, business customer, consumer, vendor, patient, student, children) and the categories of such personal information. This is perhaps the most difficult part to nail down and requires a plain definition of what constitutes personal information (the legal part), and what types of personal information the project collects (the technical part).

It is also challenging to nail down specific categories where unstructured data is involved. For definitional purposes, structured data can be thought of as records (or transactions) in a database environment; for example, rows in a table of a database. Unstructured data can be thought of as data that’s not actively managed in a transactional system; for example, data that doesn’t live in a relational database management system, like email, chat, Zoom recordings, and Word documents.

Another challenge is deciding whether to require broad categories of personal data like health information and financial information or if companies should name specific data elements, like COVID-19 test results or bank account numbers. Using broad categories (such as health or financial information) will often require further specificity to determine whether certain privacy requirements apply, such as PCI DSS for payment card information. Sometimes, it might not be possible to specify data elements, especially where unstructured data is involved. Either way, a good rule is to describe the data involved in a way that enables a fair assessment of the risks involved. For example, “Zoom recordings between Sales executives and prospective customers” is more descriptive than “video recording.”

What data processing activities are involved?

This section asks for a description of the proposed data processing activities and their related purposes. If under the GDPR, these could also include the lawful bases for data processing. These pieces of information are needed to analyze the necessity and adequacy of processing activities in relation to the purpose.

When and how does data collection occur?

There’s also typically a section covering when and how collection occurs. Who does the collecting: is it the entity or a third party? Is it a one-time data collection or a periodic and ongoing one? Knowing the parties involved and the frequency of data collection helps determine the impact. Data collection involving third parties means increased attack vectors over which you have less control. (Of course, this can be mitigated with contractual requirements covering such third party’s privacy and security controls.) Ongoing data collection could mean more data collection and increased exposure to attack.

Who gets access to the personal information?

A privacy review template also asks about who gets access to the personal information and why. Privacy requires the security of personal information. The security principle of least privilege further requires that that any user, program, or process should have only the bare minimum access to data necessary to perform its function. This principle limits the damage that can result from an incident or breach.

If access is given to third parties, this privacy review section asks questions that would determine the parties’ relationship to each other under applicable laws like GDPR or CPRA. For example, who is the controller, processor, and subprocessor under GDPR? Similarly, who is the business, service provider, and third party under CCPA or the incoming CPRA?

Note that because of the compliance implications, your vendors and third parties may not agree with your analysis of the relationship and resulting regulatory labels. This should not affect your privacy review itself, but note that it could manifest itself later during contract negotiations.

Where is personal information stored and processed?

This section asks where the collected personal information is stored and processed. This includes any third party hosting information, which is helpful in assessing any third-party risks. It also includes data storage and data processing geographical locations, which are important for determining legal risks.

How long is the data retained?

Customers often ask about how long organizations store data collected by their products. Different laws also have different retention requirements. For example, different tax laws require companies to retain employee payroll and tax information for a specific minimum period of time.

This section could be used to ask and define the retention policy needed for the data involved. The general rule is that companies should store personal information only for as long as it has a legitimate reason. That said, different laws have different standards for retention. For example, under the GDPR, personal information can be stored for “no longer than necessary to fulfill the original purpose.”

What does the data map look like?

The data map provides a visual summary of the data lifecycle from collection and use to storage and destruction. It also identifies the parties involved: the customer, product owner, subprocessors, and other third parties. Data maps help visually issue-spot privacy and security issues such as any third-party contracts or encryption in transit. This map is usually provided by the business owner.

How is the personal information secured?

This section helps determine available security measures and identify missing ones. This section could also list security certifications that the product or project needs to have based on the entity’s commitments, such as ISO 27001/2, FedRAMP, FIPS 140, or other security frameworks appropriate to the product or industry.

V. How Does One Conduct a Privacy Review?

Once you’ve created your organization’s privacy review template, you will next have to create a procedure for conducting one. This procedure should be socialized with the privacy review key players, which could include business owners, product leads, the procurement and vendor management team, the information security team, and/or the legal or privacy team. This procedure typically includes the following phases:

Information-gathering

The first phase involves gathering information about a proposed data processing that is potentially in scope of your privacy review. You will have to pre-define responsibilities for information-gathering. Your privacy review template should help gather the information needed for the next phase: assessment.

It might take some time to gather the information about the proposed data processing. This is where tools can help, with an accurate picture of the data processing and automated reminders to the key players involved. Regardless of whether the process is automated or manual, it’s important to cultivate investigative skills to get the information needed to perform a privacy review.

This means not just gathering information for the privacy review at hand, but also conducting historical research on any previously conducted privacy reviews on the same or similar product, project, or system in your organization.

Threat Identification, Impact Assessment, and Risk Assessment

The actual assessment phase involves reviewing the information gathered to determine the privacy threats, impacts, and risks involved.

The first step is to understand the threats or harms involved. This includes identifying the threat actor(s): your own organization, a disgruntled employee, a vendor, a hacker, etc. This also involves articulating the threats or harms they could cause. Once you’ve articulated the threats and harms, you can then move to assess their related impact. The likelihood of the impact occurring, mitigated by privacy controls, is the resulting risk. Again, risk = (impact x likelihood) — mitigation.

Let’s take the following example: Your organization fails to operationalize data subject rights (DSRs). This impacts individuals’ ability to exercise their GDPR or CPRA rights and increases your organization’s exposure to fines and penalties. To address these, you temporarily set up a mailbox for receiving DSR requests while you simultaneously work on building your DSR process. Your organization is a B2B company that historically receives a handful of DSRs per month (versus the thousands of DSR requests per month that some B2C companies receive) [low likelihood].

Threat Your organization [threat actor] fails to operationalize DSRs

Impact 1 Individuals’ ability to exercise DSRs

Impact 2 Your organization’s increased GDPR compliance exposure

Mitigating Control (Short-Term) DSR mailbox

Mitigating Control (Long-Term) Operationalize DSR process; build and/or buy DSR solution

The risk articulation is: your organization fails to put in organizational controls which impacts individuals’ ability to exercise their GDPR rights and increases your organization’s GDPR exposure. These impacts have a lower likelihood of materializing given your B2B space. You mitigate them with a band-aid control by instituting a temporary DSR mailbox while you decide whether to build and/or buy a DSR solution as a long-term fix.

There are frameworks that can help identify privacy threats, such aforementioned works like Solove’s A Taxonomy of Privacy, Jason Cronk’s use of FAIR for privacy threat modeling, or NIST’s PRAM.

Recommendations and Mitigations

Once assessments are completed, the privacy reviewer will need to articulate recommendations to address or mitigate the privacy impacts identified and minimize privacy risks. This could mean recommending whether the organization should proceed with the proposed data processing, adding security controls, or other course of action based on the risk assessment. This could also cover compliance obligations, such reporting or getting approval for any high risk processing from a regulator, requiring a DPA for a vendor, or providing a privacy notice to a consumer.

Audit

After providing recommendations and mitigations and wrapping up the assessment, the privacy reviewer will need to follow up on whether their organization implemented their privacy review proposals. This can be addressed through a policy or operationalized through an internal audit process. Depending on whether there are compliance obligations involved, the privacy reviewer may need to closely track whether their privacy review recommendations and mitigations were completed.

Audits can also be used to learn from your organization’s historical privacy reviews. Some things that you might want to consider within the scope of your audit:

• Data surrounding privacy reviews, including how many requests submitted; how many passed the threshold for a privacy review, a DPIA, or a TIA; how many were completed; average time each took to complete; which part of the process took longest to complete; etc.
• Data about the consistency of privacy reviews
• Data on the types of projects/products/systems submitted for privacy reviews

VI. How Does One Operationalize A Privacy Review Process?

The following are some of the components for operationalizing a privacy review process:

Process

Articulate a process for privacy reviews, complete with instructions, templates, definitions, ownership, and an identified tool.

Template. Create a template for the privacy review. This should include the intake form for the information-gathering stage. It should also include a section on the actual assessment. For different compliance requirements that may apply, check out regulatory guidance, such as the FTC’s PIA template, the UK ICO’s DPIA template, or the French CNIL’s version, and incorporate their components into your own template.

Ownership

Confirm ownership for the privacy review process.

Who triggers a privacy review? Ideally, business owners for products, projects, initiatives, and systems that involve personal data processing submit a privacy review request.

Who owns information gathering? In a small organization, business owners and “privacy champions” can be deputized to gather information necessary to perform a privacy review. In organizations with huge privacy teams, privacy practitioners gather information. This could also be a shared responsibility between privacy practitioners and business owners.

Who conducts the actual review or analysis? This part will have to be done by a privacy practitioner who has the requisite privacy expertise or knowledge. In organizations without privacy owners or with a small privacy team, this part can be outsourced to an external DPO or law firm. The security component of the privacy review will have to be performed by a security expert.

Tool

Regardless of whether you are using a manual spreadsheet, building your own in-house privacy review workflow automation tool using existing resources, or buying an off-the-shelf privacy review tool, you will still need to configure your privacy review’s content and scope. The following section walks through the main elements of a privacy review template.

Awareness, Buy-In, and Integration

To increase adoption, you will need to socialize the process with different privacy review owners. It can be incorporated into your annual privacy training so your employees know when to submit a privacy review. In addition to training, you can also request buy-in from organizational leaders such as the CISO, CIO, CTO, etc. who can mandate adoption of your process by their teams. Look for ways to integrate your process into existing and known processes. For example, it’s a good idea to investigate whether it would make sense to integrate with existing security, IT, procurement and vendor management, and product review processes.

Privacy reviews require privacy, legal, technical, and operational skills to build, conduct, and operationalize. But once operationalized, they could save companies from costly legal, compliance, and brand privacy headaches.

Resources

• Sample DPIA: Microsoft’s DPIA on Office 365: https://docs.microsoft.com/en-us/microsoft-365/compliance/gdpr-dpia-office365?view=o365-worldwide
• Sample FTC Privacy Impact Assessments, available at https://www.ftc.gov/site-information/privacy-policy/privacy-impact-assessments
• GDPR Article 35, Data protection impact assessment https://gdpr-info.eu/art-35-gdpr/
• European Commission, Guidelines on Data Protection Impact Assessments, available at https://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=611236
• French CNIL, https://www.cnil.fr/en/privacy-impact-assessment-pia
• UK’s Information Commissioner’s Office, which is responsible for enforcing the GDPR in that country, has prepared a Data Protection Impact Assessment template https://ico.org.uk/media/about-the-ico/consultations/2258461/dpia-template-v04-post-comms-review-20180308.pdf