This week, I had the privilege of sitting on a panel, with Crispen Maung, the chief compliance officer at Box along with Hendrik Reese, a senior manager and GDPR practice lead from PwC’s consulting practice in Germany. The topic for the panel was “The reality of GDPR: Learnings from the First Three Months”. We addressed a variety of topics, but I wanted to recap on some of the key takeaways from my perspective.
I do not pretend to be a GDPR expert and rarely cite article and clause references. I get to work with an outstanding team of practitioners that live, eat, breathe, and sleep them. I am someone that has worked within many domains of technology compliance and security for more than 20 years. It was that seasoned auditor’s perspective that I provided, along with what we are seeing first-hand at our clients.
I am someone that has worked within many domains of technology compliance and security for more than 20 years. It was that seasoned auditor’s perspective that I provided, along with what we are seeing first-hand at our clients.
Topic one – we learn from history that we don't learn from history
During the panel, I made at least two comparisons to Sarbanes-Oxley (SOX) compliance. Why is that? One, the two laws hold companies accountable to their word and two, companies are modifying processes in many cases just for the sake of compliance.
To be more specific, what happened after SOX’s 2002 passing and 2006 section 404 mandate is still very much alive today. While it does not have the urgency it once did, public companies are rightfully still held accountable by law. The same is true for companies regarding EU citizen personal data.
One of the dangers that we learned from SOX in the mid-2000s, was that a “checkbox” mentality, and overreach, created more complexity than was required. I can remember vividly a situation at a client where the payables department said, “we can’t pay without X documentation due to SOX.” Projects that were SOX related got immediate approval. And it went on and on. One CFO I worked with during that time joked that he was expecting to see SOX referenced in a proposal to require the re-painting of the parking spaces at the office building.
The same appears to be true for GDPR and data processing/protection agreements (DPA). Many companies have instituted policies to issue DPAs for their vendors around the May 25 GDPR effective date. In most cases, this means a template DPA for all vendors. Procurement professionals are blindly sending out agreements just for compliance but are not necessarily considering the context for the services being provided. Additionally, not every vendor is a processor and even more important is an understanding of types of data that is either collected or processed by that vendor, which vastly changes the DPA terms.
In almost every case, compliance is a journey...
Topic two – management systems and risk assessments
This was a topic where all three of us weighed in. Each of us on the panel had extensive backgrounds in ISO 27001 certification, so the concept of a management system was not foreign. The management system in this case is the broader set of policies and processes that enable a company to identify gaps that may exist on its own. In almost every case, compliance is a journey, a cliché used by all three of us. But it is true. The more mature compliance frameworks require that the company is covered under these frameworks in fact risk assess and audit themselves to identify their own issues. If perfection or 100% compliance was the expectation, frameworks like ISO, FedRAMP, and HIPAA would not have these types of components.
Topic three – to be or not to be certified!
This topic came up a couple times. My colleague from PWC Germany voiced his frustration over the fact that there was not a mechanism for organizations to undergo certification with GDPR. He noted that there were several frameworks out there that could be adopted for leveraged and made a plug for the Germany focused C5.
In the US, we have grown to be patient. The HIPAA law has shown us that even though a law was passed in 1996, 22 years later there is still no industry-wide accepted certification (although there are several types of reports, such as HIPAA attestations and HITRUST certifications that are accepted by some providers).
Additionally, it is well documented that GDPR has enforced the certification through the member states, many of which have differing opinions on what certification framework should be utilized. As auditors, we are agnostic on the topic of what framework should be utilized for certification. However, we do have an opinion that the certification framework should be consistent across the member states. When you think of all the multi-national organizations, this consistent framework would make the certification process less onerous. Additionally, it would be almost impossible for organizations to determine consistent compliance with GDPR in the absence of a consistent certification framework.
Final topic – commitment-oriented dataflow diagram
At the end of the session, we were asked if there was one thing we could recommend companies do today who are just setting out to evaluate GDPR.
Crispin from Box spoke about the fundamental need for organizations to map their data flows and obtain a picture where all personal information may reside. This is not only required by GDPR but necessary for compliance and frankly, should be employed by all organizations. However, I responded with a slightly different approach. For Processors, when constructing your data flow diagram describe the flow of data from the perspective of your customers and what you commit to them. For example:
- Data Types - What types of data (i.e., only names and email) have they instructed to and not to provide to you (i.e., home address)?
- User Interface - What instructions have they given you for browser and/or mobile device?
- Ingestion - Through what means have you committed to take data, sftp, file upload, etc.?
- What locations have you committed for the storage of data?
- What level of encryption do they require for data in storage?
- What are the SLAs for retention?
- What are the SLAs for deletion?
- Additional commitments as applicable – Ensure you read the contracts to determine other types of commitments that have been made
Mapping how data flows in relation to commitments to your customers sets up the exact type of context to conduct a thorough and thoughtful assessment of whether or not you were meeting those requirements. In addition to GDPR, this will also help you with SOC 2 examinations, the new CaCPA, and other types of security and privacy requirements you may need to adhere too.
As I mentioned in the panel discussion, if you don’t have a sense of what your delivery model or your strategy for working with European customers is, GDPR compliance will be a difficult area for your organization to tackle and an independent assessors' role is somewhat limited. However, if you have done your data commitment mapping and have at least a good start on data flow, a firm like Schellman can evaluate your service and its detailed compliance against the GDPR articles.
Last, I want to thank the Box product and compliance team for allowing me to participate in a very productive and interactive session.