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
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
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. 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. 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
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
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
14. Map Data Flows to country specific laws & regulations
14
Today’s Privacy Landscape
Source: Nymity Research - Maps & Charts
15. Data Transfer - Countries with Restrictions
Source: Nymity Research - Maps & Charts
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. 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. 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
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
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
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
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. 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. 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
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. 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. 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