Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

5 Signs Your Privacy Management Program is Not Working for You

220 visualizaciones

Publicado el

GDPR, CCPA, and other privacy regulations have forced companies over the last five years to focus on building out a privacy management program regardless of their size or maturity. Privacy management can range from ad hoc decentralized spreadsheets to fully- optimized, technology- backed solutions, depending on the resources and support provided.

Whether you pulled together the bare minimum compliance requirements or built out an end-to-end privacy management program, the goal is to provide your internal stakeholders actionable insights to make strategic data-driven decisions.

Join this webinar to learn the five signs that signal your privacy management program isn’t built to last and find out how you can get on the road to recovery.

Key takeaways:

- The five signs that signal your privacy management program isn’t built to last
- What a privacy management program should include to provide actionable insights to make strategic data-driven decisions

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

5 Signs Your Privacy Management Program is Not Working for You

  1. 1. © 2020 TrustArc Inc. Proprietary and Confidential Information. 5 Signs Your Privacy Management Program is Not Working for You August 26, 2020
  2. 2. Speakers 2 Paul Breitbarth LL.M Director, EU Policy & Strategy TrustArc Edward Hu Senior Counsel and Data Protection Officer TrustArc
  3. 3. Agenda 3 5 Signs 1. Inability to scale 2. Inability to map data flows to country specific laws & regulations 3. Inability to respond to requests from individuals and regulators 4. Frequent security incidents 5. Inability to perform a function because someone is absent
  4. 4. © 2020 TrustArc Inc. Proprietary and Confidential Information. Inability to scale
  5. 5. Inability to Scale - Fundamental Concepts 5 The difference between a scalable process vs. program Program ● A privacy program is the company’s management of its data protection and data handling obligations from laws, contracts, consumer expectations, and operations. Process ● A privacy process is the implemented organizational or technical safeguard in place to satisfy a data protection or data handling obligation. For example ○ Inventorying and updating data flows for systems, products, and services that process [personal] data. ○ Assessing and testing technical measures to manage data processing. ○ DSRs process.
  6. 6. Inability to Scale - Making the Case 6 Why do you need to be able to scale? Increase agility, minimize risk ● Meet the demands of business growth ○ Increase in the number of business processes ○ Increased volume ● Meet the demands of increasing regulatory requirements ○ Expansion into other countries. ○ E.g. increase in total DSRs after GDPR, CCPA, et alia. ● A scaling exercise helps even without current business growth or additional regulatory requirements. ○ Identify and remedy process inefficiency (scaling down easier than scaling up) ○ Certifications
  7. 7. Inability to Scale - How to Do It How to build a scalable process? A scalable program? Scalable processes ● Repeatable and capable of withstanding an increase in volume or throughput ● In order to do that, map the process and identify inefficiencies ● Identify repeated actions and remove inefficiencies (templates, workflow) ● Automate where possible Scalable programs ● Regulation agnostic ● Based on controls and activities ● Frameworks can adapt to any law(s) ● Better than adapting to laws individually (which may be vague or not cover all areas of risk) 7
  8. 8. Inability to Scale - Example Frameworks ● NIST Privacy Framework ○ (100 controls, 8 functions, 29 control categories) ○ ● TrustArc + Nymity Framework ○ (55 controls, 3 pillars, 16 categories) ○ (130+ PMAs, 3 pillars, 13 PMC) ○ ● APEC Privacy Framework ● ISO 27001 (Information Security Management System) ○ (114 controls, 14 groups, 35 control categories) 8
  9. 9. Inability to Scale - Example Framework Categories and Controls Nymity PMC: Maintain a Governance Structure ○ PMA: Assign data privacy responsibility to an individual like General Counsel, Privacy Officer, CPO, etc. ○ PMA: Conduct regular communication between privacy office and others responsible for data privacy in the organization. TrustArc Categories: Disclosure to Third Parties and Onward Transfer ○ Control: Assess vendors handling personal data for effective safeguards and controls. ○ Control: Ensure personal data is adequately protected when transferred internationally, including transfers to third parties and vendors. 9
  10. 10. 10
  11. 11. 11
  12. 12. When to build a scalable process or program? Processes ● Removing inefficiency is always a plus, but sometimes there are costs. ○ Cost of undertaking ○ Cost of software solutions ● Cost benefit analysis for software ○ Quantify the cost of an existing process ○ Determine the cost savings over time. Hidden costs (operational, fines or penalties) Programs ● Not many situations in which you wouldn’t want to use a framework ● Investing now for cost and time savings and risk mitigation Inability to Scale - When to Implement, Effect on Bottom Line 12
  13. 13. © 2020 TrustArc Inc. Proprietary and Confidential Information. Inability to map data flows to country specific laws & regulations
  14. 14. Map Data Flows to country specific laws & regulations 14 Today’s Privacy Landscape Source: Nymity Research - Maps & Charts
  15. 15. Data Transfer - Countries with Restrictions Source: Nymity Research - Maps & Charts
  16. 16. Inability to Map to Legislation - Fundamental Concepts 16 Ad Hoc Compliance v. Accountable Program Ad Hoc Compliance ● Every new law is a challenge to comply with and takes up resources for implementation of compliance measures. ○ Controls are too specific ○ No way to monitor what’s coming up – caught unaware Accountable Program ● An accountable program allows an organization to leverage existing processes to comply with new laws ○ Identify the delta between laws ○ Assess any gaps and additional requirements
  17. 17. Accountability Based Approach 17 Leverage existing activities to comply with many laws and evidence of accountability to demonstrate compliance ONE ACCOUNTABLE PRIVACY PROGRAM Evidence of Privacy Management Activities or Controls exists throughout the organization (within the privacy program as well as operations); evidence is collected in a centralized repository, structured in a line with the Privacy Management Categories or Standards. MANY REGULATORY REQUIREMENTS Evidence of accountability is mapped to requirements allowing the organization to demonstrate compliance with laws and regulations on-demand, supported by evidence.
  18. 18. Hypothetical Scenario - “SaaS Europe” Business Process ● Your company uses a vendor, Wamazon S4, to provide a hosting service in Germany. ● The platform hosted on Wamazon collects PI from Portugal, Sweden, France, and the UK. ● The Wamazon server syncs with your company’s data center (American Web Svcs) in Virginia, U.S. ● Employees in Virginia (U.S.) and technical support staff in Oregon (U.S.) login to the U.S. server and sometimes access PI to provide account management and tech support. ● Document the locations for your data subjects and systems and the data flows. ● (Also document processing purposes, controls, roles (controller/processor), vendors, etc.) Understanding Your Own Data - Mapping Your Data Flows 18
  19. 19. Data Flow Map Europe Understanding Your Own Data - Mapping Your Data Flows 19
  20. 20. Data Flow Maps - World View Understanding Your Own Data - Mapping Your Data Flows 20
  21. 21. Hypothetical Scenario - “SaaS Europe” Data Flow Diagrams Understanding Your Own Data - Mapping Your Data Flows 21
  22. 22. © 2020 TrustArc Inc. Proprietary and Confidential Information. Inability to respond to requests from individuals and regulators
  23. 23. Inability to Respond to Individual Requests 23 Most Data Protection Laws allow for Individual Requests ● > 110 countries with Individual Rights Requests ○ Right of Access ○ Right of Correction ○ Right of Deletion ○ Right of Data Portability ○ and others Challenges ● Volume of Requests (may increase following publicity and/or data breach) ● Finding the Data (structured and unstructured) ● Respecting the Deadlines
  24. 24. Individual Rights Request Timeframes: from <7 days to >30 days 24
  25. 25. Inability to Respond to Individual Requests How to Respond to Individual Requests Improve processes ● Centralise entry point for requests (web form, email address, etc.) ● Develop standardised business processes ○ Authentication of Individuals ○ Triage by type of request ○ Compliance requirements based on country of residence of requestor ○ How to retrieve data (including who can offer support) ○ What to do in case of massive volume of requests (how to ensure peak capacity?) ● Automate where possible ● Documentation or record of responses to requests 25
  26. 26. Demonstrate Compliance 26 Centralized management and metrics
  27. 27. Demonstrate Compliance 27 Detailed reporting and record logs (dummy data)
  28. 28. Inability to Respond to Requests: DPA Enforcement 28 Poland - 20 July 2020 The Polish DPA imposed a fine of ~$ 1,350 to an entrepreneur running a non-public nursery and pre-school. The organization had notified a data breach, but with insufficient information to conduct any follow up enquiries, and did not respond to multiple follow up requests from the DPA. The Polish commissioner indicated the fine is “a clear signal to all entities that disregarding their obligation to cooperate, on request, with the supervisory authority, especially by hindering access to information necessary for the performance of its tasks, is a serious infringement and as such is subject to fines Source Argentina - 1 June 2020 The Argentinian DPA imposed a fine of ~$ 4,000 to a company for non-compliance with an access request. The company had no process in place to deal with request for access outside of their platform, nor to deal with requests from the supervisory authority - it assumed it was only subject to court orders, but not to administrative enforcement. Source | Nymity Reference
  29. 29. © 2020 TrustArc Inc. Proprietary and Confidential Information. Frequent security incidents
  30. 30. Frequent Security Incidents 30 No Data Protection without Data Security ● One of the core principles of privacy legislation Challenges ● Human mistakes ● Keeping security up to date at all times ○ BYOD ○ Cost ● Ensuring all security incidents and data breaches are reported ○ Creating organizational trust - in- and externally
  31. 31. Frequent Security Incidents 31 No Data Protection without Data Security Solutions ● Define clear security standards and policies, including for dealing with incidents ○ And train employees on security policies on a regular basis ● Log every security incident ○ And ensure the log is regularly reviewed by the privacy team, IT and company leadership ● Use a certification as a method to systematically address IT and organizational controls and to find gaps. ○ SOC 2, Type 2 (effectiveness of controls)
  32. 32. Frequent security incidents: DPA Enforcement 32 Denmark - 29 May 2019 PFA Pension Fund was criticised for a lack of compliance with Article 32 GDPR. By February 2019, the organization had reported 66 data breaches under the GDPR, of which 62 related to unintentional disclosures of personal data. Following an investigation, the Danish DPA concluded the organization’s security standards were lacking. A fine was avoided, since the organization in the meantime had started a security improvement process. Source | Nymity Reference Netherlands - 17 July 2019 and beyond A hospital in The Hague was fined €460,000 for employee snooping. Over 100 non-authorized employees looked at the file of a reality TV starlet admitted to hospital. The Dutch DPA investigated and criticised the hospital’s security policies. Since the fine was imposed, two further security incidents took place, including the use of the backside of a document containing patient data as a shopping list (which was subsequently left behind) and collecting patient survey data via a third party, without an appropriate data processing agreement. Source | Nymity Reference
  33. 33. © 2020 TrustArc Inc. Proprietary and Confidential Information. Inability to perform a function because someone is absent
  34. 34. Lack of Resiliency - Signs of a Problem Fault Tolerance Definition: The ability for a system to continue operating properly in the event of the failure of some of its components. How do you know you have a problem? ● Turnover, PTO, or even an overburdened individual may reveal the existence and extent of the problem. ● Inability to meet internal SLAs. ● When institutional knowledge exists only within individuals. 34
  35. 35. Lack of Resiliency - Why It’s a Problem Why is lack of fault tolerance a problem? ● Privacy laws are often bound to specific deadlines for responses. ○ Article 30 requests which are due right away. ○ DSRs - Missing deadlines or frequently extending deadlines. ● Contractual obligations are often bound to specific deadlines. ○ Notice in case of a breach. ○ Changes to sub-processors. ○ Prior notice for audits. ● Resource cost to reinvent/rediscover an already existing process. 35
  36. 36. Documentation ● Document existing policies and procedures ○ They don’t have to be perfect, but they do have to be documented. ● Document who the backup persons are. ● E.g. ○ DPAs and other contracts ■ Playbook of positions and acceptable terms ■ Checklist vis-a-vis relevant privacy laws ○ Security or privacy assessments Matrix Your Staff ● Designate primary responsibility, designate a backup person ○ Provide adequate training (shadow / walkthrough), using the documentation ○ Ensure access is in place (network permissions, created accounts, etc.) ● In addition to having fault tolerance, you will have a load balancing solution! ○ Load balancing solutions must be in place before the overload occurs. 36 Lack of Resiliency - Solving the Problem
  37. 37. © 2019 TrustArc Inc Proprietary and Confidential Information Q&A
  38. 38. © 2019 TrustArc Inc Proprietary and Confidential Information Thank You! See for the 2020 Privacy Insight Series and past webinar recordings. If you would like to learn more about how TrustArc can support you with compliance, please reach out to for a free demo.