GDPR Q&A with a Cybersecurity, Compliance and Privacy Expert

This blog on the General Data Protection Regulation (GDPR) features guest Tom Cornelius. Tom is the Senior Partner at ComplianceForge, an industry leader in cybersecurity and privacy documentation. He is also the founder of the Secure Controls Framework (SCF), a not-for-profit initiative to help companies identify and manage their cybersecurity and privacy requirements.

In my last blog (What you need to know about Article 32), and the blog before that (GDPR Compliance for the IT Security Professional), I’ve been breaking down the security related GDPR articles for IT professionals—focusing on the sections in the regulation that IT professionals can reasonably address. Over 50 percent of companies surveyed in our new 2018 GDPR Compliance Report assigned GDPR ownership responsibilities to IT Security teams.  Additionally, the report highlighted that only 7 percent of these companies said they would be ready when the GDPR came into force on May 25, 2018—citing lack of expert staff, budget, and understanding of GDPR Compliance as the top 3 reasons for not being ready.

AP: Hi Tom, what have been your observations regarding companies’ efforts to comply with the GDPR?

TC: GDPR focuses on fundamentals. A lack of technology, cybersecurity and privacy governance is the root cause of issues in complying with GDPR, not the actual regulation itself. For privacy and cybersecurity lawyers, consultants and product vendors (outside service providers), GDPR is an immense financial windfall. Similar to SOX and HIPAA, this regulation spawned an entirely new professional specialization. It is in their absolute best interest to keep GDPR nebulous so that long-term professional service contracts and new technologies can be purchased to solve the problem of complying with GDPR.

You can’t blame these outside service providers for embracing capitalism and taking advantage of the free market. After all, they are merely filling a void that was left by a fundamental failure by many organizations to identify, implement and manage basic cybersecurity and privacy principles.

AP: Compared to regulations like SOX, HIPAA or PCI DSS Compliance, what new requirements does GDPR introduce?

TC: Other than redefining a more restrictive view of Personal Information (PI), GDPR did not create any new requirements that were not already reasonable expectations from well-established cybersecurity and privacy practices. To highlight a few articles of GDPR that are lamented as “new requirements” by many organizations:

• Article 5, Principles relating to processing of personal data – Being able to demonstrate “appropriate security” is a fundamental component of Plan-Do-Check-Act with maintaining any cybersecurity program through recurring assessments to validate controls exist and are operating as expected.
• Article 17, Right to erasure (‘right to be forgotten’) – While rebranded with the concept of “right to erasure” or “right to be forgotten,” the retention and secure disposal of data is not a new concept and has always focused on only storing data as long as there is a legitimate business need.
• Article 25, Data protection by design and by default – A basic expectation of any Secure Development Life Cycle (SDLC) where secure engineering principles are designed and implemented throughout the lifecycle of the asset, application or process. Note: Agile, waterfall or any other development methodology are expected to build security and privacy into the development processes.
• Article 30, Records of processing activities – Documenting data flows is nothing new. High-Level Diagrams (HLDs), Low-Level Diagrams (LLDs) and System Security Plans (SSP) have been used for ages as a way to capture “records of processing activities” and are a basic expectation for compliance-related oversight. Unless a process is documented, it is impossible to properly assess it and assign the appropriate controls to secure the systems, applications and processes that are within scope.
• Article 33, Notification of a personal data breach to the supervisory authority – Mature breach notification processes have been an expectation since 2003 when California released SB 1386. GDPR just shortened the timeline to notify regulators.
• Article 35, Data protection impact assessment (DPIA) – Performing Business Impact Analysis (BIA) and risk assessments are nothing new. GDPR just rephrased it as a “Data Protection Impact Assessment.”

AP: Why doesn’t the GDPR provide more specific guidance, especially for IT and cybersecurity professionals responsible for an organization’s security compliance mandates?

TC: While it might sound overly simplistic, the articles that comprise the GDPR are designed to be vague and put the burden on the organization to define what “right looks like” to comply. The bottom line is an expectation that your organization can demonstrate three things, which essentially govern GDPR compliance efforts:

1. Alignment with a cybersecurity framework (e.g., ISO 27002, NIST 800-53 or NIST Cybersecurity Framework) to ensure appropriate technical, administrative and physical controls in place;
2. Alignment with a privacy framework to ensure appropriate privacy controls are in place; and
3. Oversight mechanisms that routinely provide ongoing validation that privacy and cybersecurity principles are in place and operating as designed.

How those three points are implemented will vary by organization, since the available People, Processes and Technology (PPT) vary depending on resources of the organization. Not everything can be accomplished through a “silver bullet” technology solution, so it definitely involves staffing appropriate roles and managing processes to address GDPR compliance requirements.

In practical terms, alignment of PPT with a cybersecurity framework means that your organization has policies, standards and procedures that are aligned with a leading cybersecurity framework, such as NIST 800-53, ISO 27002 or the NIST Cybersecurity Framework. Many organizations have some form of alignment with these frameworks.

AP: What is preventing so many organizations from complying with the GDPR if they already align with these frameworks?

TC: From a GDPR perspective, many of the stumbling blocks are around pre-production testing and being able to demonstrate that cybersecurity principles were designed and implemented by design and by default. This is a common weakness in Secure Development Life Cycle (SDLC) processes, where resources are constrained to generate the necessary documentation to provide evidence of due care and due diligence. Without a champion in senior leadership to do it properly, SDLC is generally a “paper tiger” that lacks the ability to compel project teams to generate necessary artifacts.

For alignment with a privacy framework, this is often less mature than the alignment with a cybersecurity framework. In many cases, Governance, Risk & Compliance (GRC) and privacy teams do not have any informal or formal alignment with a set of privacy principles. While there are many to choose from, the most common are ISO 29100, Generally Accepted Privacy Principles (GAPP), US Privacy Shield and SOC 2’s privacy principles. Similar to picking a cybersecurity framework to align with, there is no right or wrong answer for picking a privacy framework. It just needs to be supportable by the organization and be implemented to address EU GDPR requirements.

AP: What advice do you have for organizations without an established set of privacy principles?

TC: By leveraging the Secure Controls Framework (SCF), I created the EU GDPR Compliance Criteria (EGCC) that breaks down the articles of the GDPR into actionable controls from the SCF and maps those to common cybersecurity and privacy frameworks, providing alignment with a company’s existing frameworks with a “paint by numbers” approach to complying with the GDPR, and free for any business to use.

The GDPR is process-related and not “checklist based” as compared to requirements such as PCI DSS compliance. With a focus on process, this requires good documentation in order to demonstrate how people, processes and technology (PPT) are managed to ensure that both cybersecurity and privacy principles are implemented consistently.

The EGCC maps GDPR articles to the following:

• Secure Controls Framework (SCF) controls, including the focus (e.g., management, technical users or all users)
• Cybersecurity frameworks such as: ISO27001 and NIST
• Privacy frameworks such as: SOC 2, HIPAA and GAPP
• A RACI-style diagram that shows the most common parties involved in managing certain controls

AP: This is great, I really like how you have broken this down into steps using existing frameworks. Any other advice you have for my readers?

TC: Well, I love the phrase “Never let a good crisis go to waste.” For many organizations, the GDPR is a crisis due to legacy business processes and technical debt. For organizations that actually took steps to operationalize cybersecurity and privacy principles, GDPR compliance should be manageable by simply adding the required oversight, which will improve the maturity of their existing privacy and security controls. If anyone has questions about my EGCC check-list, I can be reached at tcornelius@complianceforge.com.

***

Thanks to Tom Cornelius for patiently grinding through all my questions. If I could feature a guest every week, I could be a prolific blogger.

My next blog post will go deeper into using existing compliance frameworks in your organization to accelerate (or plan) your GDPR compliance efforts. Or, I might just end up writing about 2018 World Cup developments.