5 Steps to Build an Enterprise Data Protection Framework
Every board member of every company is concerned about data breaches. No executive wants to see their logo (let alone their face) on the news next to a major headline about leaked fingerprints or credit card details. However, not many board members understand the technical aspects of securing data. Getting a firm-wide view and grip on data protection is difficult, yet necessary, more than ever before. New regulations such as the General Data Protection Regulation (GDPR) make data protection even more complex. It’s no longer just about finding data and making sure its secure. It’s about capturing the context of data and being able to prove everything is being done to protect the subject’s data and the rights of the subject itself.
As Chiara Rustici points out in a recent article:
“If your colleagues who do most of the data collection don’t appreciate it’s who the data is about, not where the data lives that matters for the GDPR, you may end up spending a lot of your cyber security budget to defend data that should not have been collected.”
In this blog post, we’ll outline the steps it takes to get an enterprise data protection program going by leveraging core data governance principles. These steps close the gap between the board, who have a huge stake in getting the right data protection measures in place, and the IT functions who are busy with geo-fencing, masking, and other physical protection measures. These guidelines will form the base for a data protection framework that is ready to support the concept of Crown Jewels, GDPR, and more.
1. Identify Business Data Owners
One of the most crucial changes that data governance brings to an organization is the recognition of data owners within the business (data citizens). It’s these owners that will also play a key role in establishing our data protection program. After all, they are the best source to know what critical data is being stored and processed. There might already be a list of applications in your organization or you might have to ask each data citizen to register each application/data store or data processing activity.
The end result will be a register of all applications, their context, and the data citizens that use them.
2. Define a Taxonomy of Sensitive Data Elements
At the core of the data protection program, you’ll have a taxonomy of critical or sensitive data elements (SDE). Elements such as fingerprints, customer contact information, social security number, or employee background checks. It’s from this taxonomy that each data citizen will pick assets that they use within their application or processing activity, together with other pieces of context such as the purpose, location, and more.
In this taxonomy, each SDE will have an assigned classification, for example:
- Confidentiality—The required level of secrecy and cost/risk impact of unexpected disclosure
- Integrity—How tolerant (or not) any section of the information can be to being changed or lost entirely
- Availability—How important it is to have timely access to the information when we need it
- Consent—Whether there are legal requirements or restrictions in place that impact where the information can go. This applies to personal information.
3. Assign Compliance Controls
Based on the assigned data elements and their classification, each governed application will get a policy (ie public, internal, confidential) and risk type assigned. With this assignment comes a set of security and compliance controls ideally owned and governed by the Data Protection Office(r) (DPO). These controls will be very different for public data than for restricted data. Each control is managed within the governance function together with expected answers.
By pushing these control questions in questionnaires to the business owners, you can get their assessment of what controls are in place and which ones are lacking. Alternatively, you might want to use your GRC tool for this.
4. Tracking Gaps and Breaches, No Matter How Small
After this exercise, you’ll end up with a baseline view of what applications or processing activities are most at risk and what type of risk is involved. Each item of non-compliance becomes a gap, a data issue where the data owner needs to work with the Chief Information Security Officer (CISO) and security managers to put in place the right controls. This is where the actual protection comes in: what data will we encrypt? What will we geo-fence? What should not be on-line at all? Do we keep data longer than we should? Where should we ask for consent to our users?
Aside from these gaps we can start tracking data breaches or infractions – no matter how small – per application so we can start seeing the relations between incidents and the impact they might have on LOB’s, business owners and risk types. Prevention in the end is the ultimate goal.
“… It is also important for organizations to try and spot trends in any data problems that occur, and to not just record issues separately. Otherwise there will be a risk that each incident will be seen as unique, rather than having common root causes – which can then be rectified and solve the entire issue.“
5. Reporting Back to the Board
It will be the responsibility of the data governance council to use the heat maps and KPI’s coming out of our continuous collaboration and monitoring efforts to update the board. A 360-degree view of all critical applications and their assets, linked to the lines of business with indications of gaps and risks will be a huge differentiator to keep them well informed on their level. Apply stewardship to this and we have a data protection framework that reflects the living body of our business.
The days where ‘keeping threats outside of your network’ was enough are over. The biggest leaks and risks originate from within an organization. Data is the prize and needs to be protected from within. A proper data governance framework will prove to to be the foundation needed for any successful cyber security program.
Koen is responsible for delivering real-world data governance solutions to the problems raised by different regulations such as BCBS239, Solvency II, and GDPR. Before joining Collibra, he worked as principal consultant for Wolters Kluwer Financial Services and Financial Architects on Basel, Compliance, and Solvency projects worldwide.