TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

The Privacy Advisor | 'Pen testing' your privacy program: Steps to test your privacy compliance before the onset of litigation or enforcement actions Related reading: CCPA/CPRA grace period for HR and B2B ends Jan. 1

rss_feed

""

Privacy litigation and regulatory enforcement actions are booming. There has been a sharp increase in plaintiff's firms and consumer groups scanning through company websites, mobile apps and other features in search of privacy compliance issues with cookies, pixels, tags, software development kits and other technologies. Similarly, whether in response to individual complaints, media stories or on their own initiative, privacy regulatory authorities have increasingly undertaken market reviews on these issues. And, litigation and regulatory investigations are expected to follow in the ordinary course after a company notifies of a data breach. 

How can companies prepare for this increasingly contentious environment? Beyond the due diligence associated with the day-to-day development and implementation of a privacy program, another option is to execute a "pen test" of your privacy program. This concept borrows from the longstanding practice of penetration testing or "pen testing" company cybersecurity controls. Pen testing cybersecurity controls refers to a cyberattack simulation launched against a company's network to help discover points of exploitation. Pen tests can help prevent data breaches and test companies' resiliency to cyberattacks.

Pen testing a privacy program is similar to pen testing cybersecurity in the sense that it is an exercise aimed at identifying potential issues with the company's program. A privacy pen test is different, however, because it simulates how a plaintiff's firm, consumer group or privacy regulator investigates and litigates potential privacy noncompliance. 

How do you do a privacy pen test?

Although we are not aware of any formal framework, organizations can draw inspiration for privacy pen tests from cybersecurity frameworks, such as the NIST Cybersecurity Framework. An overview of the phases for a privacy pen test are as follows.

The first phase should involve planning and identifying what key elements of the company's privacy program are subject to the test. The organization should identify particular publicly available websites, mobile apps, other externally-available sites and/or internally-accessible applications in scope for the exercise. The organization should also identify specific aspects of privacy compliance to be evaluated and applicable privacy standards based on laws and regulations in the geolocations and industries to be tested. As with cybersecurity pen testing, it is important to focus on one or more elements of the organization's privacy compliance program and not attempt to test everything at the same time.

The second phase should involve discovering information about relevant elements of the company's privacy compliance program, including simulations of interactions between consumers, employees, patients or other identified data subject categories and the in-scope apps. This simulation should be carried out on live operating versions of in-scope apps and should involve human review and capture of information about applicable privacy notices, links, choices, consents, preference centers and other features. The simulation should also involve the deployment of automated tools to gather information about cookies, pixels, tags and other data collection technologies on the Apps. In addition, because privacy pen tests simulate government and investigations, they should involve a form of e-discovery or legal demands for documents, interviews and other evidence.

The third phase should involve reporting the findings, preferably in the form of privileged legal memorandums that outline the factual findings, legal analyses and recommendations. It is important to work with legal counsel to design a privacy pen test, to align with the proper interpretation of applicable privacy standards evaluated for potential noncompliance, to execute the test to assure proper analysis against identified privacy legal standards and to seek privilege protections to the extent reasonably available.

What are examples of potential areas for testing? 

The particulars of what aspects of the privacy program should be tested will vary depending on the company's industry sector, geography, history of challenges, interactions with regulators and other factors. The testing can be launched from different geolocations and IP addresses, and standards can be drawn from various privacy laws and regulations applicable to the company. Given the detailed nature of the review, a company may wish to pick only one, or a few, of the suggestions below or otherwise execute a combination of elements from among the following, or other, areas:

  • Cookies: The test can interact with in-scope apps and document the privacy notices, links, consents and other privacy features across observable cookies, pixels and other tags. The simulation can also include follow-up interactions after the selection of privacy choices to test the effectiveness of such choices.
  • Direct marketing: The test can interact with in-scope apps and document relevant privacy features, including notices and choices related to direct marketing via email, text, phone and/or other channels. The simulation can also evaluate testing of choice functionality, e.g., "unsubscribe" links embedded in individual direct marketing communications.
  • Geolocation. The test can interact with in-scope apps and document observable information about collection and use of geolocation data and privacy features, as well as additional factual information from questions posed to the company's technical and business leads about the collection, use and disclosure of geolocation data.
  • Age detection mechanisms: The test can interact with in-scope apps, document observable information about privacy features and determine whether such apps are targeted to children under 13, teens between 13 and 18 or other relevant age for minors depending on geolocation. It should document information about age detection mechanisms, parental consent and disclosures of children's personal information. 
  • Incident response and breach notification documentation: The test can posit a scenario where a regulator or a plaintiff's firm seeks copies of policies and procedures on incident response and breach notification, as well as copies of the company's documented risk assessments on security incidents over the past three years. Similar exercises could be implemented across other areas of required documentation, such as records of processing activities, privacy impact assessments, security risk analysis and risk mitigation documentation.  
  • Corporate customer privacy terms: The test can posit a scenario where a critical business application is subject to a ransomware attack and a substantial volume of corporate customer data within the application is subject to unauthorized access or acquisition. The simulation would involve the review of privacy features and customer contract terms regarding the protection of personal information, the role of the company for the impacted data, e.g., as "controller," "processor" or equivalent, and notification obligations in the event of security incidents or data breaches.
  • Vendor privacy terms: The test can posit a scenario where a critical application is hosted or supported by a third-party vendor, is subject to a cybersecurity attack and a substantial volume of the company's customer or employee's personal information is impacted. The scenario could test not only the vendor's contractual obligations to report the incident to the company, but also whether it has imposed its own "upstream" obligations on the vendor, undertaken in key customer agreements.
  • Record retention. The test can posit a scenario that involves an extortion where the cyber-criminal extracted a large volume of data from the company over many months and different business applications, including unstructured drives. This should involve a review of applicable retention policies and relevant statements within privacy features and other documentation to ensure they align with the company's retention policies. It should also review a sampling of raw information from relevant business applications and drives to evaluate whether, or the extent to which it appears, such information is retained beyond applicable retention periods and whether such data, if subject to a breach, might attract mandatory breach notification duties.     
  • Intra-group cross-border data transfers: The test can posit a scenario where regulators in non-U.S. jurisdictions investigate the sufficiency of company intragroup data transfer agreements, transfer impact assessments and other controls for the cross-border transfer of personal information. The simulation should involve a review of core applications that result in the intragroup transfer of personal information, e.g., about customers, employees, patients or others, and a sampling of "upstream" obligations the company undertook with key corporate customers.

At the end of the day, when performed and documented properly, pen testing of a privacy program can serve as an element of an overall effective privacy compliance program, and can assist in uncovering potential privacy legal issues before they mature into litigation or regulatory enforcement actions. 


Approved
CDPO, CDPO/BR, CDPO/FR, CIPM, CIPP/A, CIPP/C, CIPP/E, CIPP/G, CIPP/US, CIPT, LGPD
Credits: 1

Submit for CPEs

Comments

If you want to comment on this post, you need to login.