Navigate PII data protection and GDPR to meet privacy mandates
Know the commonalities surrounding personally identifiable information to better navigate and comply with the regulations and penalties IT managers must contend with today.
The European Union's GDPR has been in effect since May 25, 2018. Every business or organization collecting personally identifiable information on EU or U.K. residents is subject to its requirements and penalties for noncompliance. In addition to GDPR, there are numerous other PII laws and regulations organizations must comply with or face harsh penalties.
PII noncompliance fines associated with GDPR have been harsh over the past year. Singapore's Personal Data Protection Act of 2012, Japan's Act on the Protection of Personal Information and California's Consumer Privacy Act of 2018, for example, also have severe fines. Noncompliance means fiduciary irresponsibility, which can result in business failure and potential incarceration. This means PII data protection isn't optional, it's essential.
At the one-year anniversary of GDPR, the European Data Protection Board reported more than 500,000 registered data protection officers, more than 280,000 cases and 144,000 complaints, data breach notifications numbering above 89,000 and over 446 cross-border cases. The fines levied were assessed in excess of 56 million euros.
More importantly, GDPR is not alone when it comes to PII compliance. There are dozens of PII data protection laws and regulations worldwide, and more are in the works. Keeping up with all of them requires a full-time effort, especially for organizations conducting business globally.
It's important to note that many countries have adjusted their PII data protection laws and regulations to align with the EU's GDPR. The GDPR includes cross-border provisions that encourage alignment. This makes it easier for homegrown organizations to do business in the EU. The majority of European countries that are not part of the EU, and those located in northern Africa and the Pacific Rim, have aligned with GDPR or are in the process of doing so because it is generally considered the PII gold standard.
However, there are important differences IT organizations must pay attention to. For example, if a business collects information on Russian residents, any and all databases with that information must stay in Russia. Failure to do so will cause the website to be blocked, a fine to be imposed and possibly result in the business being banned from the country.
Fragmentation and market barriers have emerged around requirements for PII as data flows across borders that make international business a growing challenge. There are substantial differences among these laws, regulations and penalties. Fortunately, substantial commonalities among these laws should help IT departments more effectively navigate the growing labyrinth of laws, rules, regulations and fines.
General PII commonalities
While not a comprehensive listing, here are the most frequent commonalities IT organizations should pay attention to. These are not the only items you need be concerned about. That will depend on the countries in which you do business.
PII responsibility. Someone needs to be in charge of and responsible for PII laws and regulation compliance. Whatever title they are given -- data protection officer (DPO), chief security officer (CSO) or something else -- they are the person with primary accountability for all PII data protection and compliance. The role can have responsibilities other than PII accountability.
Managing consent. This can vary a bit between GDPR and those laws and regulations aligned with GDPR, and countries such as the U.S. and Canada. There are three issues with consent:
Opt-in versus opt-out. The GDPR states that consent must be given, or -- in other words -- individuals must opt-in. The U.S. and Canada allow implied consent and only require individuals be allowed to opt-out. It is safer and smarter to always assume an opt-in procedure. In both cases, opt-out is required.
Purpose of the PII collection. There must be a defined use case when collecting data. If that use case goes away, PII data must be deleted and cannot be repurposed. This is one of the most controversial aspects of PII data protection because it generally means PII data cannot be sold.
Documentation of user consent. This information must be produced upon demand by different PII laws and regulations.
There are dozens of PII data protection laws and regulations worldwide, and more are in the works. Keeping up with all of them requires a full-time effort, especially for organizations conducting business globally.
Right to access. IT organizations must provide a complete accounting of the personally identifiable information their organizations have on any given individual upon request. This requires an organization to know what information it has, where it's located and be able to retrieve a copy of it within 30 days or less.
Doing this for unstructured data is harder than it seems. Finding PII in a database is not difficult, but some of this information will be unstructured data that exists in the data center and, more likely, at the edge in laptops. Finding PII in unstructured data requires knowing where to look and search tools that can look beyond the metadata and into the data itself. Doing this centrally when there are numerous laptops isn't easy.
One way to accomplish this task is to use backups. Because they tend to be centralized, backups have the latest personally identifiable information. You will have to mount the data and use the data search tools to locate the correct PII data.
Backup vendors Druva with e-discovery partners, Actifio, Cohesity, Commvault and Rubrik, can effectively do this. In addition, Cloudtenna DirectSearch can search on any mounted data from any backup vendor.
You can also use data management software that aggregates, harvests, parses, categorizes, copies and moves unstructured data. Examples include Dell EMC ClarityNow, Komprise Intelligent Data Management, Spectra Logic StorCycle, Starfish Storage and StrongBox Data Solution's StrongLink.
Protecting PII data. Too many organizations view data protection as a cost and skimp on related products, processes and budgets. PII laws and regulations make doing so much riskier. Most require protecting PII data against human errors, system failures, software failures, corruption, disasters, malware and ransomware.
Organizations need to build comprehensive data protection into the PII data collection processes and must be able to restore PII availability and access to personal data in a timely manner. This could range from hours for most situations to no more than 30 days for a full-fledged disaster. To ensure this capability, implement a documented process to regularly test, assess and effectively evaluate these processes. Clearly lay out, test annually -- or more frequently -- and update DR and business continuity procedures.
Processes must be state of the art, but that does not mean a specific technology or vendor. It involves using processes that are equivalent to what the market offers to meet PII data protection requirements at any given point in time. An organization can't assume that what it has done in the past is good enough. That is considered deliberate noncompliance. If data protection processes fail and PII data is lost, the organization is at risk of being noncompliant if they are not state of the art and fined appropriately.
How GDPR fines and penalties are assessed
GDPR appears to be the personally identifiable information protection gold standard that many countries are emulating or aligning with their own PII laws. GDPR imposes stiff fines for noncompliance.
European Union regulators use the following 10 benchmarks to determine the amount of the fine for GDPR noncompliance:
Nature of infringement. How many people were affected, how much damage was suffered, how long was the infringement duration and what was the processing purpose?
Intention. Was the infringement intentional or negligent?
Mitigation. What actions were taken to mitigate damage to data subjects?
Preventative measures. How much technical and organizational preparation was previously implemented to prevent noncompliance?
History. Has the organization had any past relevant infringements, which may be interpreted to include infringements under the Data Protection Directive -- the predecessor to GDPR -- and past administrative corrective actions under GDPR, from warnings to bans on processing and fines?
Cooperation. How cooperative has the organization been with the supervisory authority to remedy the infringement?
Data type. What types of data are affected by the infringement?
Notification. Was the infringement proactively reported to the supervisory authority by the organization itself or by a third party?
Certification. Did the organization qualify under approved certifications or adhere to approved conduct codes?
Other. Are there any additional aggravating or mitigating factors that may include financial impact on the firm from the infringement?
If an organization infringes on multiple provisions of the GDPR, it shall be fined according to the gravest infringement, as opposed to being separately penalized for each provision. However, this may not offer much relief considering the potential fine amounts.
Up to 10 million euros, or 2% of the worldwide annual revenue of the prior financial year, whichever is higher, shall be issued for the following infringements:
controllers and processors under Articles 8, 11, 25 to 39, 42 and 43;
certification body under Articles 42 and 43; and
monitoring body under Article 41(4).
Up to 20 million euros, or 4% of the worldwide annual revenue of the prior financial year, whichever is higher, shall be issued for the following infringements:
the basic principles for processing, including conditions for consent, under Articles 5, 6, 7 and 9;
the data subjects' rights under Articles 12 to 22 ("Right to be Forgotten" is Article 17);
the transfer of personal data to a recipient in a third country or an international organization under Articles 44 to 49;
any obligations pursuant to Member State law adopted under Chapter IX; and
any noncompliance with an order by a supervisory authority.
Reporting a PII data breach.Reporting a breach can be devastating to an organization's stock price, bonuses, reputation, ongoing revenues and the careers of IT managers and C-level executives. It is required, however, and typically must be done within 72 hours of discovery. Some laws and regulations only require reporting a breach to the government. The majority require notifying both the government and those affected by the breach.
Right to be erased, aka right to be forgotten. Erasing PII data is one of the most difficult aspects of PII laws and regulations. Organizations must erase PII data from all IT systems when one of three things occur:
The owner requests PII data be deleted.
The PII data collection purpose is no longer necessary.
The owner withdraws their PII data consent.
PII data must be permanently erased in a timely manner -- usually less than or equal to 30 days. It also means personally identifiable information must be erased everywhere it's located, including databases, servers, laptops, the cloud, archives, backups, tape libraries and in unstructured data such as spreadsheets, documents and presentations.
Some PII data protection and compliance laws and regulations allow exceptions or best efforts. Others, such as GDPR, do not, although waivers are occasionally possible. The problem is that many IT professionals use backups as an easy form of archiving and keep them for years or even forever. It's a very poor archive because the data has to be recovered or mounted to be searched and there are numerous physical or virtual copies to be searched.
This is highly problematic, especially for image backups, which are the most common backup today. They're how most hypervisors -- VMware vSphere, Microsoft Hyper-V, Nutanix Acropolis and KVM -- and their VMs are backed up. Erasing data from one backup does not propagate to previous or subsequent backups. It actually corrupts all of the backups that were made after the backup in which PII data is erased. This means each backup, from the newest to the oldest, must be mounted; PII data searched, found and erased; and the backup returned to its backup state.
It may be a bit onerous for a handful or even a month of backups, but it is an impossible task for several years' worth of backups, especially in a 30-day window.
Many backup managers argue that erasing PII data from primary systems is all that's necessary. This is because those systems will be backed up again within 24 hours without the erased PII data. And since the vast majority of recoveries will be from the most recent backups, it should not be a problem. There are a few exceptions, however.
For example, if DevOps uses backup data for development, they could be using supposedly erased PII data. But if the backups have been infected with a ransomware virus that lays dormant for months, when the ransomware detonates in the primary systems, the data recovery from the most recent backups will fail as it detonates in the recovered data in what is called an attack loop. That pushes the IT manager to go further back in time to initiate a recovery -- likely to a point in time that will contain PII data that was supposed to be erased.
Some backup vendors such as Asigra and ioFabric address this problem. They can erase PII data from a single backup and have that erasure propagated to all of the other backups without having to mount each one or corrupting the backups that follow.
Minimizing PII data collection. Several PII laws and regulations specifically require the amount of PII data collection, storage and time retained be kept to a minimum. There are exemptions for health and criminal records.
Processing security. The PII security rules emphasize using the appropriate security for the risk level -- for example, the use of pseudonyms, aliases, encryption, biometrics, multifactor authentication, antimalware software, firewalls, deep packet inspection and so on. The security should ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services.
Like PII data protection procedures, security needs to be tested on a periodic basis to ensure it does what it is supposed to do.
Cross-border PII data movement. These regulations compel organizations to store captured PII data in the country where it was collected, or in countries that align with the PII laws and regulations of the country where the data was collected.
Closing thoughts
PII laws and regulations are varied and confusing, so it falls on IT to ensure compliance with the general commonalities. Being the DPO or CSO in this regulatory environment can have one of two outcomes: a career-enhancing move or a career-ending move. Which one it turns out to be depends on you and your organization.
