Navigate PII data protection and GDPR to meet privacy mandates

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 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:

  1. 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?
  2. Intention. Was the infringement intentional or negligent?
  3. Mitigation. What actions were taken to mitigate damage to data subjects?
  4. Preventative measures. How much technical and organizational preparation was previously implemented to prevent noncompliance?
  5. 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?
  6. Cooperation. How cooperative has the organization been with the supervisory authority to remedy the infringement?
  7. Data type. What types of data are affected 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 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 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.