At CyberGRX, we like to use our own tools to solve our problems. For instance, we use our Exchange to manage our third parties, but we also use it to manage and measure the health of our own security program. This includes continuously updating our self-assessment and making the results available to internal stakeholders, so we can make informed security decisions. We also share our self-assessment with potential customers so they can be sure their data will be secure with us.
The latest addition to our CyberGRX assessment is a GDPR (General Data Protection Regulation) module. GDPR is a set of EU-promulgated regulations that affect companies that do business in the EU or with EU Residents. It takes effect May 25th of this year. For companies that do business in the EU, GDPR is a big deal, as it can take a lot of work to become compliant, and non-compliance can carry heavy fines.
The purpose of the new CyberGRX GDPR module is twofold: to help companies determine whether they or their third parties will be affected by GDPR and help them get ready by identifying gaps that need to be closed in preparation for GDPR.
We’re still working our way towards being ready for GDPR, and assessing our own readiness with our GDPR module is a key part of that. Here’s how we’re doing it and what we’re learning on the way. We hope you find it useful.
1. Understand our data flows
The first step we took was to identify how EU Personal Data enters our company. For each data flow we identified, we asked the same questions:
- Where does the data come from?
- What data elements do we collect?
- Where do we store the data?
- Where do we back up the data?
- Where / how do we copy the data (e.g. for reporting)?
- Do we give it to anyone else?
Answering these questions required talking to the business side as well as our engineering and data groups. For CyberGRX, the most obvious source of personal data is our assessment portal, where a user name and email are used to register. Our customers also provide contact information, including telephone numbers, on the platform. We store that data in an encrypted SQL database residing in AWS and create daily encrypted backups. We don’t sell or provide the data to any third parties, and we don’t do reporting that includes individual user names or email addresses.
But the non-obvious sources are the trickiest. Our sales and marketing rely on complex combinations of SalesForce and supporting applications. We also have Europe-based contractors on staff, and that means we’re collecting names, contact information and other personal data from them. It’s easy to forget that GDPR obligations extend to your associates as well as your customers.
2. Determine who holds the hot potato (Data Protection Officer)
The Data Protection Officer (DPO) is responsible under GDPR for the protection of personal data. Every organization subject to GDPR must designate a DPO prior to May 25th. There are various views on where in the organization the DPO should reside:
- Legal: This is a reasonable choice, since legal is responsible for negotiating contracts with third parties and should have a good grasp on the legal requirements.
- Chief Privacy Officer: Larger organizations tend to have a Chief Privacy Officer. Again, a reasonable choice, as this person is likely to have a background in privacy.
- Chief Information Security Officer: The CISO is also a good choice. The CISO is likely to have the best understanding of the technical environment and the best understanding of what technical measures are required for compliance.
My view is that it depends. You need someone with the broadest understanding of the issues, not someone with the “right” title. Does your legal team lack knowledge of your technical environment? They’re probably not the right choice as DPO. Does your CISO think “indemnification” is a useless concept? Probably not the right choice either. For us, the CSO holds the DPO responsibilities due to the technical digging required to operationalize our GDPR responsibilities. But we may transfer that responsibility to legal once the initial technical lift has completed.
3. Assess our readiness
This is where the value of our Exchange and process really kicks in. Our GDPR questionnaire contains a Controller section and a Processor section. Complete the section that’s applicable to you. If you’re a Controller who uses Third Party Processors, you should complete the Controller section and ask your third parties to complete the Processor section.
The GDPR module consists of 13 Controller questions and 8 Processor questions. In addition, there’s a controls maturity section common to both. If you know the answers to the questions, you can complete them fairly quickly. If you don’t know the answers, you can use the question delegation feature to forward them to someone who does and review the answers before they’re submitted. For GDPR purposes, we primarily ingest and process our own data, so our answers and gaps are focused around Controller gaps.
4. Close readiness gaps
Frankly, we’re not done with this yet, but we’re working on it. We found that a lot of our gaps were in three categories:
- Disclosures and policies / procedures for individuals from whom we collect data. Writing the disclosures is the easy part but implementing our GDPR obligations, such as right to erasure, is more difficult.
- Security incident response & notification. A mature security program will already have this, but under GDPR, it’s necessary to do a bit more tracking of who needs to be notified, in case of an incident, and how quickly.
- Terms & Conditions in third-party agreements. This is a key focus area for our legal team. From what I’m seeing, an increasing number of third parties are including GDPR clauses in their contracts but many others are not yet addressing it.
So that’s our experience so far with GDPR. Please feel free to contact us and I’d be happy to provide more details on our progress, or how you can make use of our platform to “get ready”.