Problem solve Get help with specific problems with your technologies, process and projects.

Data protection tips for corporate compliance leaders

Author Rebecca Herold explains why compliance professionals need to understand data protection issues in order to successfully do their job.

Even if all of the compliance requirements on your checklist have been met, a data security breach can still occur. If you're a chief compliance officer, however, and you've done your job, it's not just up to IT and information security to deal with data protection.

In the chapter from The Shortcut Guide to Understanding Data Protection from Four Critical Perspectives, author Rebecca Herold explains why compliance professionals need to know and understand data protection issues in order to successfully do their job.

Download Chapter 2 of "Understanding Data Protection" as a .pdf

Data Protection Responsibilities of Compliance Practitioners
A few years ago, a large manufacturing organization created a Chief Privacy Officer (CPO) with enterprise privacy responsibility within the law office, reporting directly to the CEO. The information security responsibility was many levels down in the organization, with the Information Security Officer (ISO) at the manager level, who reported to the director, who reported to the CIO, who reported to the VP of Operations, who reported to the CEO.

The ISO was worried about the proliferation of laptops being used for business processing, particularly for processing the orders from both individuals and other companies. She did a risk assessment and submitted the resulting report with a recommendation to require encryption on the laptops. The ISO's recommendation was denied because, according to the CPO in the law office, no laws (at that time) explicitly required encryption, and the expense to implement encryption would not be necessary, in his opinion, to advance the business. The law office had not even discussed the matter with the ISO. Information security risks were not considered in this decision; it was based purely on the letter of the law, even though most data protection laws then required consideration of risks to be the basis for security decisions.

Thorough understanding of information security risks is key to determining how to implement safeguards that meet compliance requirements. Close collaboration, and mutual respect, between the areas is necessary for effective information security and privacy programs.

Why Are Compliance Directives Necessary?
Many organizations lament, "Business should be self-regulating with regard to information security and privacy." Indeed, that would be ideal. I believe that the majority of organizational leaders want to do the right thing with regard to protecting the information their business has collected.

But I believe with equal fervor that there is a small, but significant, portion of business leaders who would prefer to gamble experiencing security incidents, breaches of their financial and customer information, and even jail time rather than spend one nickel on information security. Unfortunately, the comparatively small portion of businesses who do not want to invest any more money than they legally are required to do results in the greed of a few necessitating laws for all. Thus, it is important for compliance officers, privacy officers, and internal auditors to know and understand not only the specific data protection directives within the laws that apply to their organizations but also those more nebulous and subjective directives that require thoughtful consideration and analysis, accomplished through productive talks and collaboration with the information security and IT areas.

Back in the mid-1990s, I was responsible for information security at a large multinational insurance and financial services corporation. Our company used one of the Big Six (yes, at that time there were six major public accounting firms, down from the original Big Eight of the 1980s and prior) public accounting firms. The firm had a permanent office within our facilities, and the firm's auditor director always assigned the information security‐related audits to the firm's newest auditor, usually fresh out of school with an undergraduate degree. I was that new auditor's primary contact.

It never failed; whenever the new auditor would start the audit, he or she would meet with me, head down to scrutinize their checklist, and initially not apparently thinking about how my answers impacted all the other issues further down their page. Because I had experience as an IT auditor, I always tried to take time to explain how the questions on their checklists could not always have a black-or-white answer, and indeed how most information security controls must be based upon the risks associated with each unique situation. The security controls that would be acceptable in one organization may be completely unacceptable within another based upon the associated risks. As a result, the audit reports were not only more valuable to the business but also were of much more value to the areas that were audited because they included feasible recommendations based upon the business realities of the area.

Unfortunately, there are still a large portion of compliance practitioners that insist upon doing their reviews and audits strictly according to a checklist. This practice seemed to bloom and thrive along with the passage of the Sarbanes Oxley Act (SOX). However, all compliance practitioners must understand that compliance controls must be implemented to meet the specific risks within an organization and reduce them to an acceptable level that is also in compliance with applicable laws, regulation, industry standards, contractual obligations, and enterprise policies.

New and Emerging Legal Issues
Currently, there are more than 100 data protection laws and regulations throughout the world, a growing number of industry data protection standards, corporate data protection policies for virtually every organization doing business, and many times more contractual requirements for data protection. Whew! This mountain of compliance requirements necessitates compliance activities beyond a checklist.

Most of the regulatory oversight agencies try to assist organizations with compliance guidance documents. These can be extremely useful to compliance practitioners. However, it can also be a bit overwhelming given how many of these guidance documents exist for any one compliance directive.

For example, there are at least 16 guidance documents that apply directly or indirectly to SOX alone. Add to this the thousands of vendor guidance documents that various other groups and vendors have published, and the thought of determining which one of them to use soon becomes overwhelming!

As technology evolves, the number of breaches continues to grow, and the methods of committing crime using business information and personally identifiable information (PII) increase, there are going to be more data protection laws and regulations. It is no longer practical for compliance practitioners to depend upon following checklists for their compliance activities. Instead, compliance practitioners must first understand the basics of data protection, how their applicable compliance directives apply to their own unique organizations, and the realities and feasibility for implementing specific controls to address the most compliance requirements possible within their own business environment.

US Breach Notice Laws
Consider the lessons learned in recent years for businesses trying to be in compliance with data breach notice laws. California SB1386 was the very first US breach notice law, which went into effect on July 1, 2003. Now there are at least 47 US data breach notification laws. Although California SB1386 provided the basis for the subsequent laws, there are significant differences.

Unfortunately, many compliance practitioners use that single law to determine whether their own organizations have practices in place to be in compliance with all their applicable laws. This is not a sound practice. Consider, for instance, the definition of PII; it is NOT the same throughout all 47 US breach notice laws. Compliance practitioners need to check to ensure the business has included the widest definition of PII within the incident response and breach notice plans.

Within the US and specific to privacy breach laws, the first definition of PII, as put forth by California SB 1386 in 2004, was very limited in scope:

  • An individual's first name or first initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted:
  • Social security number.
  • Driver's license number or California Identification Card number.
  • Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account.

So, the majority of businesses decided to make this their organizations' own definition of PII and then built their privacy incident response and breach notice plans around this decidedly narrowly‐defined definition of PII.

However, when California's new law, AB 1298, took effect January 1, 2008, becoming the second state after Arkansas to include medical and health information in the definition of "personal information," organizations nationwide took note about the broader definition of PII. This impacted not only the triggers within security incident and breach response plans, but also the impacts, to individuals as well as organizations, for breaches.

The risks involved with medical PII breaches are different than those for financial PII breaches. Medical PII can include a very wide scope of information, such as medical history, diagnosis, policy number, subscriber number, an application, claims history, and appeals history, according to the laws. The change in the definition of PII in these breach notice laws shifted the focus from preventing identity theft and financial crimes to preventing a very wide range of fraud, crime, and even physical harm that could occur through the compromise of medical information.

Don't forget about the definitions of PII within data protection laws outside of the US. There are at least 100 data protection laws throughout the world that include a definition of PII. Thus, as compliance practitioners check for compliance with breach notice laws, it is important that they know and understand not only what the full definition of PII should be for their organization but also where all that PII is located and how it is being safeguarded.

Defining PII is just one of the issues that compliance practitioners must consider when examining breach notice law compliance. Other topics to consider include, but are not limited to:

  • When, and if, individual notification is required
  • The notification issues involved when PII is encrypted
  • Notification requirements for PII in all forms, including printed and spoken

Use Unified Compliance for Best Efficiency
Trying to comply with a growing number of data protection laws, in the US and worldwide, is a growing challenge for compliance professionals. Just a few years ago, there were only a few federal regulations that US organizations worried about; primarily SOX, the Gramm-Leach-Bliley Act, the Health Insurance Portability and Accountability Act (HIPAA), and the Children's Online Privacy Protection Act (COPPA). At that time, it was comparatively easy for compliance professionals to address compliance with each law separately.

Then, in a very short time period, a large number of state‐level data protection laws, in addition to more federal laws and international laws, were enacted—along with the Payment Card Industry Data Security Standard (PCI DSS), updated auditing and risk standards, and contractual requirements. Many compliance professionals are understandably overwhelmed and worried about how to comply with them all.

It is good to take a step back and consider what it takes to be in compliance with data protection requirements. Compliance is generally and widely defined as following a set of rules. The rules can be in the form of laws, regulations, standards, contractual requirements, policies, and oftentimes procedures. Most organizations must comply with a large, and growing, number of requirements from multiple authoritative bodies. The challenge with those who must implement the requirements is having to be compliant with so many rules and the corresponding amount of overlap found within each of the compliance directives. The challenge to compliance professionals is how to check for compliance with so many different compliance directives.

It wouldn't be a problem if the relationship between each of the compliance directives were one-to-one, would it? In just the past 2 days, I had three practitioners ask me whether participating in the US's EU Safe Harbor program would also then put them into compliance with all other data protection legal requirements worldwide. Unfortunately, it just is not that simple.

Multiple regulations, laws, standards, and other compliance directives use differing terminologies and differing levels of protection requirements. Trying to maintain a one-to-one relationship between each legal compliance requirement would quickly prove to be not only inefficient but also result in risky gaps and frustrating overlaps. This one-off tactic would result in creating an organizational controls nightmare. Compliance professionals would be spending a huge amount of time addressing specific compliance requirements repeatedly, and those areas being reviewed for compliance would spend too much valuable time answering similar compliance questions over and over again, as Figure 2.1 shows.

To view Figure 2.1, and to read the rest of Chapter 2: What Corporate Compliance Leaders Need to Know About Data Protection, download the .pdf.

Check out more from Understanding Compliance from Four Critical Perspectives.

This was last published in October 2009

Dig Deeper on Data loss prevention technology

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.