GDPR | CCPA – 10 Steps to Designing the Right Data Protection Program

In a recent report by DLA Piper data breach notifications topped 160,000 and fines reached 114 million Euro ($126m) since GDPR rules came into effect in the EU in May 2018. The largest of which was recorded in France for 50m Euro against Google for GDPR violations. In the UK the latest information commissioners office report shows that GDPR fines have tripled in the space of a year on the back of BA and Marriott rulings, while in the US, the California Consumer Privacy Act (CCPA) and New York Data Shield acts have just been enacted in 2020 and will certainly see fines escalate if data breach history teaches us anything.
Well, let me start by saying, I’m sorry to be alarmist, but it’s my job in security to be the squeaky wheel sometimes. So, in this article I hope to set you in the right direction if you have more than a passing interest in privacy by design (PbD) and data protection regulations, in particular how EU and US registered businesses in a post privacy shield era can better prepare for GDPR and CCPA regulations using a 10 point plan. The plan has been designed more toward medium to large size regulated firms given that their budgets would allow for security controls like identify and access management (IAM) and and data loss prevention systems which might be beyond the reach of smaller firms.

In order to prime you for these steps, may I recommend that you have a glance at the GDPR FAQ’s from the EU commission press office, CCPA guidance from the Office of the Attorney General in California and New York Shield Act text from the NY Senate which is useful at a high level.

So, without further ado;

Step 1 Build a Data Map

You’ll have likely seen this step in many threads yet If you’ve been winging it a bit when it comes to documenting what you have, it can’t be ignored. There are many reasons to build a data map, but let me mention a subset of important ones here.

GDPR brings in the concept of “Data Portability” Art (18) and the “Right to be Forgotten” (Art 19) in to being. In a digital sense, think of trying to transfer data to other data controllers e.g. if a customer wants to switch insurers or requests to be deleted from your database. Well, the short answer, it wont work without knowing exactly where all the touch points in an organisation where the customer’s data may be found. If you’ve ever done extensive data discovery work, you might understand where I’m coming from, but for other readers who haven’t, trust me, it’s a considerable effort, even with the honor roll of discovery tools. Think of the multitude of structured, semi-structured and unstructured data types that could be involved. CRM / HRM/ Finance system databases, XML/JSON files, email stores, Sharepoint repositories, spreadsheets, word documents, network shares, cloud storage and more. If you’re thinking deleting information is like the scene in The Departed movie where Detective Sullivan erases Billy (AKA Leonardo Dicaprio’s) police record by hitting the enter key, it’s not, it’s just not that easy.

The point here, in order to answer to get where you need to be with Articles 18 and 19 you will need to have a detailed data map of where data lives in your organisation (diagram it and put it in an asset management system) and feed it into a record of data processor activities (or ROPA as its referred to). And yes, there are arguments already that “Right to be forgotten” is really associated with big-tech like Google, and Facebook but, right to be forgotten is really record deletion which really applies to all regulated companies. Deletion of customer data should be part of any firms information lifecycle management (ILM) program.

STEP 2 : GDPR Policy Refresh

For many organisations, policies have been somewhat of static documents which have been more of a box ticking exercise designed to project the idea that your aware of a regulatory and legal requirement for them to exist. I would argue though that your mindset should be more evolved toward a scenario based policy approach as if there was actually a big incident and investigators were crawling all over your estate with a fine tooth comb and your responding to requests for information.

So role playing for a second, you’ve just received a discovery request from your data protection authority or attorney general that goes
“Dear sir/madam, in response to your recent data breach first reported to us 3 weeks ago, this office would like the following.. In advance of our inspectors onsite visit, this office is requesting the following documentation in relation to your data privacy standards and procedures at [your firm].

Please have ready to provide the following for onsite inspection within 15 business days for review by representatives of our office: Including;

a). Your incident management documentation including breach notification, customer notifications, credit card issuer/acquirer notifications and corporate communication plans.

b.) Your data retention and media handling policies (including data destruction procedures)

c.) A list of data custodians in your organisation and data processor organisations.

d.) Your SCC/BCR arrangements / Data Processing Agreements with the 3rd party suppliers listed in attached document.

e.) Your consumer rights documented policies and procedures (including sample forms and or guest access to your consumer request web portals)

f.) A functional org chart showing data protection officer(s), IT, Compliance and risk personnel.

g.) Up to date network diagrams including DLP systems, firewalls, IPS, WAF’s, wireless infrastructure and a list of assets in your organisation

h.) Your log management policy and sample IPS logs for May 1st 2020 in PDF/Excel format.

i.) Your information classification policy and any document relating to your ILM (Information Lifecycle Management)

j.) A copy of certified audit reports/due diligence assessments with “xyz-non-EU / non-US developer organisation” [who we suspect was the source of the breach who lifted your customer database”]

h.) Most recent data privacy impact assessment for the affected system(s)

i.) Data controller and data processor activity records

I’m just getting warmed up here, If I’m assessing you and you’ve provided all of the above, satisfactorily, you’re in the top 2% land. Building your policy portfolio and scenario based readiness in the event of a breach is key to survival in the harsh realities of when things go wrong.

STEP 3 : Data Privacy Audit

Many companies are only beginning to grapple with conducting GDPR data privacy audits as the threat of increased fines looms . But, remember what you’re trying to protect with GDPR, namely consumer confidence and customer data. Consumer queries are ramping up year on year, prompted by the litany of revelations from Snowden, WikiLeaks and legal challenges brought by Max Schrems. A better response to customer questions on data privacy than just directing them to go your company homepage and read the policy might be…”We conduct an independently assessed data privacy audit on an 18 month (or better) cycle for compliance with the most recent EU/US State data protection rules…your last audit completed in June and we’re fully compliant by [accredited body] ”. You could also say that your data privacy audit methodology is based on the ICO’s guide to privacy audits which incidentally will give you a good view of what regulators would expect to see in a privacy audit program. It’s an extensive body of work spanning every part of the organization but, I would say a must do.

STEP 4 : Privacy in Software Development

I wrote in an article about 10 musts for PCI-DSS compliance that the key to development success was “Training supported by tools”. It’s the same principle for Data Protection and GDPR. So, when it comes to development, factoring in data retention settings within the application, minimizing the amount of data collected, data anonymization techniques, exportability outside the system, robust IAM roles, registration and updating of a central database for data being held on a customer would all be good things. Imagine a single pane of glass where you see all PII on any customer. Where you also know that the subject’s data is stored on a defined instance on server_b in an EU Rackspace data center for example (vs a non-EU location). Hopefully your data is not residing somewhere where it would cause you problems, but, it’s okay because you believe the sales guy who said the data they process for you never leaves the EU, great. This mode of thinking takes training to ask the right questions, so, in addition to your OWASP top 10 threats to applications, mature companies will be thinking about training developers on data privacy regulations. A nice reference I came across is titled, Data protection and privacy law for developers from the code project, it’s useful from a guideline perspective in the software requirements phase of the SDLC and will at least get you thinking.

STEP 5 : Data Protection Officer Competency

Your organization may not be publicly listed or have an ample budget for compliance in your organisation but if your company has over 250 people or is a public authority or body or an organisation that “Systematically monitors data subjects [yeah sounds Orwellian]” then you’re likely to fall under Article 35 of GDPR which directs you to appoint a DPO. I’ve written a recent article entitled key qualities of a good DPO which may help you on the topic. A further good external resource on the role definition of a data protection officer can be found here. Suffice to say that the data protection officers mandate is ensure that regulatory obligations are being met within the organisation and processing agreements without.

The number 1 challenge reported now by companies is the administrative workload related to GDPR regulations including keeping a record of processing activities, completing privacy impact assessments/data protection impact assessments, and documenting data processing agreements. In second place are the security obligations of GDPR which are broadly termed “appropriate security measures”. These two challenges are interlinked in that risks to customer data have to be identified and security measures have to be put in place to mitigate them in the context of GDPR.

From the point of view of a DPO, an effective one will have to a good working knowledge of data minimization / anonymization (PbD) techniques as mentioned in the previous step, structured/semi-structured/unstructured data types, discovery tools, encryption and identity and access management. They will also need to well aware of their data protection authorities annual report and enforcement action headlining issues along with legal rulings, industry analysis and twitter feeds from the likes of Max Schrems. In addition, the DPO is expected to directly interface with customers on GDPR related issues which draws on their communication and customer service type skills. In short, the role of a data protection officer is not back-office as many compliance roles could be said of in the past. They must be tech, legal and customer savvy along with organization skills, all not be underestimated.

Step 6: Data Leakage Prevention System Review

The market is abuzz with tools to enable data discovery and provide data leakage prevention functionality which are designed to meet GDPR, CCPA and PCI-DSS standards among others. Technically they will perform what they say on the tin when configured properly as they already have native templates for GDPR / CCPA etc. In context of a good privacy program however, no DLP system will capture all the PII data for you on an initial discovery on it’s own, hence the need for a preemptive data mapping exercise in Step 1, and scoping out what PII information is relevant.

From a personal experience perspective, DLP systems are noisy when it comes to alerts which leads to alert snow-blindness over time which in turn leads to policies being turned off or alerts being ignored. So realistically, it takes focused effort to engage with vendors, conduct regular scans of data repositories, categorize alerts in order of criticality, research and tuning out false positives, continual monitoring as part of BAU process and updating incident response plans.There’s also special cases to be consider with DLP that relate to tagging and tracking source code from leaving the organization, employee leaver monitoring and such.

As a data breach prevention tool, DLP systems are on the frontline in defense of data being ex-filtrated from organizations but they need skill, patience and research to keep them effective in the age of GDPR and CCPA.

STEP 7 : Policies and Forms

Customers are the focus of GDPR rules and hence you will probably be all too familiar with some of their rights outlined below.

1. Data subject requests for their information must be fulfilled within 10 business days of written receipt. Decline letters for information must be issued with appropriate reason code.
2. Data subjects must be informed of their rights upon written or verbal request to know the retention period of their data. Rectification and erasure requests will be facilitated free of charge.
3. Data subjects have the right to lodge a complaint in relation to international transfers of their personal data and actions considered to be individual profiling or automated profiling.
4. Data subjects have the right to object, free of charge, for the use of their data for the purposes of direct marketing Under “Data Portability” rules, data subjects have the right to move their data to another provider using a commonly used structured data format e.g. Excel, CSV, PDF.
5. Data subjects must be provided with a “Cookie Acceptance Policy” if cookie technology is in use.
6. Data cannot be processed on Children under the age of 13 without parent/guardian consent. Such consent, if given must be verifiable to all reasonable extents.

CCPA has a lesser (for now) degree of required polices including ‘notice at collection’ , ‘right to know’, ‘right to opt-out’ which have just been finalized as requirements by the office of the attorney general as of July 1st. The IAPP provides a good comparison chart here of the differences between CCPA and GDPR.

In any case these mandates have likely already driven your organization to post GDPR & CCPA data privacy notices, DSAR (Access Request) web-forms, cookie policies etc and have likely drove an effort to create breach notification policies, update incident management policies, employee monitoring policies, data processing agreements etc. Which is all good for GDPR. But it’s likely as is the case with many organizations that policy housekeeping, versioning and centralization is still not up to scratch. Many, many organizations are still not embracing document management principles with GDPR to the point in some cases where de-duplication won’t even work because versioning was never in place. By some industry analysts reporting over 60% of documents including policies are not centralized, hence it’s difficult to determine and authoritative source. Centralization efforts could be done in tandem with Step 6 above where your DLP system could discover where the documents are and be purged or migrated to a DMS system like Sharepoint where version and document access could be controlled properly and published on an intranet for example.

STEP 8 : Data Controller Mandate Checklist.

As an extension to step 7 above, one important GDPR document to add is a data controller mandate. This says in effect that personal data being processed must be collected and processed at all times in a manner consistent with the GDPR and applicable national laws. To that end, I put together 10 items on every data controller mandates list;

1. Data collection activities such as but not limited to; forms (web and paper based) which collect customer personally identifiable information (PII). Customers must be advised plainly in writing of their data privacy rights.
2. Explicit consent for collection of data must be attained at point of collection e.g. “I John Smith understand and agree to the collection of data for the purposes of…”
3. Data being collected must be the minimal amount necessary to perform the function required (based on Data Minimisation principle) and must be for lawful purposes.
4. Paper based and electronically stored customer records must contain an expiration (anniversary) date in line with the data retention policy.
5. Customer electronic records with PII including, database tables, spreadsheets, document management systems, electronic documents etc. must contain a “CUSTOMER DATA” meta tag or other embedded marker to assist in tracking such records.
6. A Data Protection Officer must be assigned with documented roles and responsibilities charter to fulfil GDPR obligations.
7. Controllers are obliged to notify 3rd party data processors of consumer request for the right to be forgotten i.e. data erasure of personal information.
8. Data held on subjects must be kept in an easily accessible format and commonly understandable to data subjects.
9. We as data controllers must maintain accurate and up to date program documentation on the operations of systems that hold customer data, we must also be able to produce the same for data processors who process customer data on our behalf.
10. Annual data protection training must be provided to business functions within the organisation, including general staff, IT developers, data protection officers and data owners. Training completion must be documented, ideally through an LMS system.

STEP 9: External Resources

Well, the good news is, there are more articles being written about GDPR, CCPA and NY Shield every day as the cyclical nature of new rules stir through social media and elsewhere. I like to bookmark things, so a few links that may help.

Link to EU Commission website with full text of new laws http://ec.europa.eu/justice/data-protection/document/review2012/com_2012_11_en.pdf

Two page overview and why GDPR is needed http://ec.europa.eu/justice/data-protection/document/review2012/factsheets/1_en.pdf

International Association of Privacy Professionals https://iapp.org/ (The largest dedicated privacy organization in the world)

Data Protection and Privacy Law for Developers http://www.codeproject.com/Articles/700324/Data-protection-and-privacy-law-for-developers

Role Definition for a Data Protection Officer http://www.eudataprotectionlaw.com/data-protection-officer/

The Enterprise Guide to Preparing for General Data Protection Legislation http://www.information-age.com/technology/security/123458144/enterprise-guide-preparing-eus-new-data-protection-legislation

Not forgetting the national agencies, only a few listed here.
IRL: http://www.dataprotection.ie/ UK: http://www.ico.org.uk Germany: http://www.bfd.bund.de/ France:http://www.cnil.fr/ Italy:http://www.garanteprivacy.it/

For CCPA and Data Shield references I refer back to links in the introduction.

Comparison chart for CCPA and GDPR https://iapp.org/media/pdf/resource_center/CCPA_GDPR_Chart_PracticalLaw_2019.pdf

STEP 10 : Corporate Culture

Two years on from GDPR and several months on from CCPA, corporate culture has by and large adjusted to the consumer first theme of the regulations. But the success and maturity of an organizations GDPR depends on good governance [related presentation] and tearing down silo’d approach to making data protection work. Many companies suffer from poor practices of not documenting what you have particularly in a fast paced agile application development world and the perception that data security is an inhibitor within an organization.
The message of value in GDPR has to come from the top down and be consistently conveyed in training, publications and job descriptions.

Summary

Here we have discussed the importance of a data map, up to date and centralized policies, privacy by design, data protection officer competency, data loss prevention and corporate culture. The watchword of all of those is privacy by design at the moment by the regulators which makes sense as it really means, applying the rules at the early stages of projects when it’s easier to make changes. We can expect to see more specificity around what ‘appropriate security measures are’ in future versions of GDPR and CCPA. But for now, there’s still and administrative weight to get through more most firms, which companies will struggle with until innovation catches up and data management has matured even further in organizations.