--> As I am sure most people agree, and have experienced as well, the majority of projects either come in over budget, late, or even worse, they never finish at all. A critical project like Data Privacy is no exception. But then again failure is not an option because of the consequences.
Before I begin, lets talk about privacy and the foundation of the project.
Politics. Yes I said it. And I am not talking about the govt type of politics, but the ones that all organizations have.
The first step that needs to be addressed is to get upper management sponsorship for a Data Privacy project. This is critical for the success of the project. Someone has to make the decision to bite the bullet to start funding and make sure that all department heads understands that is mandated from the top.
This proposed project is cost centered. It will not generate any revenue. It wouldn't make the widget run faster, nor get more customers. So getting funding for these type of projects is harder to get. One needs to make sure that upper management understand the business need, the ROI etc..
The data in question can span many applications which means many different departments are involved. A number of application owners are the stake holders in a project of this sort. So unless there is someone high up giving directions, most likely roadblocks may appear that could be insurmountable.
This can be very daunting. I suggest that you start with a pilot project, unless you are in a small IT shop. Ideally choose a relatively isolated application, if possible. Start small to be able to learn where the road blocks/pit falls are. It is easier to learn from a mistake now then to tackle more then you can chew.
Who owns the data? Who will decide how the data be scrubbed? How much data will be scrubbed? Who will maintain the process once it is developed? These will be questions that need asking.
Who will lead the project? What resources will be brought to bear on the project? Will the SME of the applications be used as reference, or will they be actually part of the project team?
Who will maintain the process after it is complete?
Ok, we can start, Right? Well not exactly. The next step is to determine what 'methodology'/process/expertise will be used. Are you going to develop something in house? Or are you going to purchase something? The company may already have the tools in place that are capable to obfuscate data. Then all you have to do you is to deploy them.
The next item is determining what exactly needs masking/scrubbing. There are a lot of factors that need consideration. Some examples are, but not limited to, the PCI DSS standard (ie. if you retain/use Credit card information). If you have EU customers/locations/presence then one must be sure to adhere to the EU Privacy Directive. Or if you operate in Canada then one must make sure the company abides by PIPEDA, and so on. Most likely the answer to these questions will come from your legal, privacy or audit departments. So consultation is in order.
So we now have all our ducks in a row. Like most IT projects there are basically four steps for a successful project. They are: analysis, design, coding and implementation, each building on the previous success.
The most critical step, is as you can imagine, is the analysis. In fact I would expect that at least 50% of the time that you spend on the project will be in this first critical phase.
Analysis. In this first step your objectives are:
1 ) Identify all the data stores that have Personnel Identifiable Information (PII).
2) Take all the meta data and scan them for tell tale signs that they contain PII, for example a field that is labeled 'ADDRESS'. That in itself is not enough just to find those fields so named. You will also need to marry the meta data to the actual data store (where the data resides. ie. DB, flat files etc). This should be enough, but trust me it isn't.
The after these two exercises are finished, one needs to actually look at the data and see, if that ADDRESS field is actually PII. It could be the address of your branch office in which case it would probably not be PII, and outside the scope of the project.
Then there are the data field labels that do not reflect what is stored. An example could be a field that is labeled 'NUMBER'. This could be a phone number, a reference number, or the number of times the customer has ordered from your company. You will need to inspect the files, that you have identified (see above) and make sure you have a list of all the data fields, and the data stores that need obfuscating.
This is time consuming to be sure. But if the analysis is not done completely and thoroughly then the project is doomed for problems further down the road.
The results of this phase are a list of files that contain PII, and the fields within those files that need to be worked on..
Design. In this step your objective is to design the various techniques needed to obfuscate the data.
Taking the information developed in the previous step, a systematic approach will prevail.
You need to categorize the various data items that were discovered. For example, all the names should be grouped together and then masked the same way.. They all need to be masked the same way to maintain consistency and interoperability between the different applications. IE you need to make sure that Robert that is scrubbed to Oliver in application A. Then, if Robert appears in application B, it will also be scrubbed to Oliver in that application. This is crucial to the long-term success of this process.
The SME needs to determine the business rules that are applicable to the various groups of data. Are there edits on addresses to make sure that the masked address is located in the specified city? The birthdays of customers are important to be maintained because of insurance rates etc?
The masking rules that are being created against the various data fields need to take all business logic into account. And then to add to the complexity of the situation. the project team may be also be mandated to sub-set the data while copying from the production system. (see one of my previous blogs with a short explanation of various forms of testing that are normally inherent within an IT department).
In the next post I will continue to explore the design stage and then delve into the next two stages of Privacy project.
and as always if you have any questions drop me a line at
rgalambos@gmail.com
Robert Galambos CIPP/C CIPP/IT
No comments:
Post a Comment