VP, Product Management
J.R. Cunningham is an accomplished innovator and premier thinker in cyber security and risk management. As vice president of product management, Cunningham is responsible for maintaining Optiv’s industry leading advisory services offerings and developing innovative and practical solutions that solve real-world security challenges.
GDPR Part 2: The Six Information Security Pillars
In the first part of our three-part series, we discussed at a high level the roles of the legal, IT, and information security functions as they pertain to the European Union (EU) General Data Protection Regulation (GDPR) and identified that GDPR compliance is, in fact a legal, IT and information security issue. In this second part of the series, we will discuss Optiv’s Six Information Security Pillars for GDPR compliance. For the information security professional, these six pillars will look familiar as standard components of an effective information security program. For this discussion, however, we will be relating these components of the information security program to the various applicable components of the GDPR. It’s important to note that we are not attempting to tie specific controls or activities to specific recitals within the GDPR, as that is covered in Optiv’s GDPR Readiness Review offering. Our goal here is to view GDPR’s requirements through the lens of existing information risk management activities in order to achieve compliance as a side-effect of a well-run information security program.
Taking a Data-Centric View
While there are many necessary controls and activities within an information security program, the GDPR is, of course, focused around the processing and movement of personal data. For this reason, we must take a data-centric view of the information security program elements to achieve compliance. To some information security professionals this may seem like a familiar approach, and for good reason. The National Association of Corporate Directors (NACD) has been issuing guidance for some time to corporate boards encouraging board members to ask both IT and security leaders to answer key questions around the identification of threats to, and protection of “the crown jewels.” This data-centric guidance has elevated the information security conversation to the board room and it should come as no surprise that we, as information risk professionals, are being driven to take a data-centric approach to achieving GDPR compliance.
The Six Pillars
Taking a data-centric view of the information security program as it pertains to GDPR compliance requires us to evaluate the program along the following pillars:
- Data Governance
- Data Classification
- Data Discovery
- Data Access
- Data Handling
- Data Protection
These pillars align with the obligations called out within the GDPR as well as with how business-aligned security programs are designed. One of the key pitfalls of any security program pursuing compliance with a legal regulation is not pursuing a sustainable information risk program which stays compliant over time and protects the crown jewels of the business by taking a risk-based approach. These six pillars enable such an information security program. In short, these six pillars exist to ask the questions, “What data do we have that is GDPR regulated, how is it classified, where is this data, who has access to it, how is it handled today, and what protections do we have in place?”
The GDPR calls out the general obligations of data controllers and processors in the first section of Chapter 4. These responsibilities are no more acute than in Article 25, “Data Protection by Design and Default.” While at first glance this article appears to be exclusively a data protection requirement, when viewed through the lenses of the preceding Article 24, “Responsibility of the Controller,” and the subsequent sections and articles of Chapter 4, it’s clear that a sound data governance program is essential to not only achieving, but maintaining GDPR compliance. Understanding what data is regulated and why this data is used to support a business function is essential before any other activity can be taken towards classifying the data, administering access and protecting the information. As a matter of fact, the GDPR calls out the requirement to take a risk based approach to protecting regulated data in Article 35. This is, in essence, data governance and entails the simple act of understanding why an organization has a business purpose for such regulated data. Effective data governance that includes business stakeholders, IT, and our legal department enables us to be compliant with the Lawfulness of Processing (Article 6) component of the GDPR. It’s important to note that while this is a key part of the information security program, data governance is a business function which should include a wide audience beyond information security.
Understanding what data in the environment is regulated and ensuring the appropriate classification is critical. Within the GDPR are specific definitions which, by their nature, require us to classify this data. The regulation defines personal data as “…any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person” (Article 4). The regulation goes on, however, to create a second category of personal data defined as “special categories” in Article 9. These special categories are defined as, “personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation.”
Simply by virtue of the GDPR creating separate categories within the regulation itself, we must treat them differently from a data classification perspective. Just as we must enable effective data governance before we can define specific protections (encryption, etc.), we need to effectively classify data (GDPR and otherwise) in our environment so that we can enable the right level of protection based upon the business and regulatory risks associated with such data.
Perhaps the most pressing concern many of Optiv’s clients have regarding GDPR compliance is understanding where regulated data is in their environment. Article 35 requires the data protection impact assessment (DPIA) to contain “a systematic description of the envisaged processing operations.” This statement alone tells us that we must understand our business applications to the extent that enables us to answer the question, “Where is this data and how is it used?” Furthermore, Article 25 requires “Data protection by design and default”, which necessitates a thorough understanding of where the data exists in the enterprise. It’s not uncommon for Optiv’s clients to answer the, “Where is the data?” question with an answer such as, “It’s in this database over here, this database over here, this cloud SaaS provider, these third parties, and a bunch of Excel spreadsheets scattered across the enterprise.” Unfortunately, this answer won’t do for GDPR compliance. We need to be able to clearly articulate where this regulated data is, regardless of whether or not it’s in the cloud, on premises, internal or third-party, structured, or unstructured.
Once we can answer, “What is the data? How is it classified? And where is the data?” we need to next pursue answers to the question, “Who has access to the data and who should have access to the data?” Answering this critical question helps us defend the business need for the data (Article 6, “lawfulness of processing”) as well as helping ensure the data isn’t used for a purpose other than the legitimate interest (also Article 6). Furthermore, it’s hard to imagine a scenario where an organization could be compliant with Article 40 (“codes of conduct”) without effectively regulating data access. As information security programs move towards identity-based security and more contextual awareness regarding enterprise data, data access governance (DAG) becomes even more essential as an information security program element and as a key lynchpin for GDPR compliance. As information security professionals, we want to be able to answer the question, “Who has access,” and enable our business and legal partners to answer the question, “Who should have access?”
How data moves around an enterprise, between enterprises, between applications, and at rest are important elements to ensuring GDPR compliance. Article 32 sets forth obligations regarding the security of processing. This article contains an initial requirement (before going on to more specifics) that organizations implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk.
The article goes onto reference pseudonymisation, encryption, confidentiality, integrity, availability and resilience. Surprisingly enough for a regulation focused on data protection, this article even prescribes for the ability to restore availability and access to data in a timely manner in the event of an incident. Furthermore, the storage limitation and accuracy principles (both in Article 5) require us to both understand how data is moving throughout the enterprise and between enterprises.
Perhaps most importantly, understanding how the organization handles its data is critical to responding to incidents. Article 33 requires notification within 72 hours of becoming aware of a personal data breach. Nowhere does data handling become more important than in understanding when an incident becomes a breach.
Contrary to what much of the noise regarding GDPR compliance would lead us to believe, this is the area of the information security program where GDPR compliance doesn’t leave us with a great deal of specific guidance. The regulation doesn’t specifically say, “You must use strong encryption.” Or, “You must use a next generation firewall.” What the GDPR does specify, however, is that we must take technical and organizational measures to ensure a level of security appropriate to the risk (Article 32) as informed by the Data Protection Impact Assessment (DPIA) (Article 35). This is where the heavy lifting falls upon us as information risk professionals to understand and clearly articulate the risks, enable effective business risk decision making, and deploy controls where appropriate both from a policy and a technology perspective.
Planning, building and running an effective security program requires the precise and effective application of data protection controls, and while at first glance the GDPR may lead us to want to shotgun-style deploy technologies such as data loss prevention (DLP), and privileged access management (PAM) solutions, foundational security is just as important. Are the endpoints protected? Do we have effective vulnerability management? Are we protecting the data in the cloud? These questions are important foundational security questions which are critical to minimizing breach risk as we enable our legal and IT partners to pursue compliance with the GDPR requirements.
The Six Pillars – Aligning with the Business and Responding to Incidents
In this second part of the three-part series we covered the six pillars of the information security program as they pertain to compliance with GDPR. In the third and final part of the series, we’ll tie these six pillars back into the overall security program and discuss how the information security program can best align with the business, help the organization remain GDPR compliant, respond to incidents, and have a healthy information risk program that accomplishes enterprise risk management objectives beyond GDPR compliance.
This marketing material and the related GDPR services offered by Optiv should not be used as a substitute for obtaining legal advice.