In an earlier blog, I talked about privacy risk. Now I want to focus in on the primary means to identify and manage privacy risk, namely the Privacy Impact Assessment (PIA).
According to the US Federal Trade Commission, a “…Privacy Impact Assessment, or PIA, is an analysis of how personally identifiable information is collected, used, shared, and maintained…” The PIA is just like any other impact assessment where the goal is to analyze privacy risk to programs, projects and processes with emphasis sometimes seen in the steps of the system development life cycle. The idea being the age-old fact that addressing problems at the beginning of the development cycle is much more afforable than later in the development cycle.
At a broad stroke, the end goal of the PIA is to assess compliance with privacy directives, assess risk of data loss and specify controls to mitigate any risks found.
Having roots in audit practices, and like other Impact assessments at a high level, these are the steps:
- Planning of the Impact Assessments.
- Carrying out the impact analysis.
- Consultation of affected stakeholders and the general public.
- Coordination with affected departments.
- Summary and presentation of findings in a report.
- Forwarding findings to decision makers.
- Publication of the IA report (not in all countries) .
For the purposes of this blog, I will focus on #1, #2 and #3 above, the actual analysis part, because the rest are pretty straightforward tasks.
The first step is planning, which I read is where you set scope.
Structured analysis dictates that the boundaries of the project be set. Are you going to analyze all processes in your company, or are you going to analyze the new HR system? While both efforts have merit, the level of effort in the former far exceeds the latter. Given that compliance programs are overhead, and dilute earnings, firms should scope what will provide the highest return on investment given the fact that resources cost money. It may be cheaper to set your own scope and then bring in outside resources to perform the work. That is the decision making you need to do in the planning phase.
Next, carry out the impact analysis with your first step being data flow analysis.
I employ the principle of progressive elaboration to data flows, which is a form of top down analysis. Start with the big picture, and then keep peeling back the layers until you get down to the data element. Be sure to document what you find along the way. Data flow analysis should give you an accurate idea of where the data flows through your firm and the result should be a flow diagram. One method I have seen used is sticky notes.
Pull the stakeholders into a room and have them write on sticky notes the steps in a process, stick them on a whiteboard, and then continue until you’ve broken down the process into its component process and data elements. Transfer the sticky notes to a diagram. You are looking for personally identifiable information (PII), clusters of PII (read: storage), where does it come in and where does it go?
Progressing, take the results of the data flow analysis and perform privacy analysis on it. Here is where the art, experience and understanding of data analysis comes in. What happens is the person performing the analysis takes the data element and decides if it can be used to specifically identify an individual or can be used as an identifying factor of that individual. The context of which framework/regulation is being addressed is also a factor as personal data for one regulation may not constitute PII for another regulation. Some PII is straightforward, such as a driver’s license number, but others may need some thought. For instance, if you have a birthday, it may not by itself be PII, but if combined with other elements publicly available, it may be PII. The important part the person performing the analysis must do is ask if it could be perceived by the owner of the PII as constituting harm were it to be released.
After capturing the data elements, the next steps are to interview staff to fully understand how the PII is used, how it is protected, and who has access to it.
That analysis is necessary so that recommendations on how to protect the data can be formed. It’s also a good opportunity to ask the basic question of “Does the entity really need the data at all?” I have seen many cases where data is gathered and is not used. In one case, I saw where sensitive data was sent to a web server, but not used by the receiving entity. When asked why my client did not ask the sender to stop sending the data, the response was that it would involve expensive programmatic changes for the sender, who would then bill my client for the services. That is a classic situation where the cost to make the changes must be weighed against the cost to protect the data, in this case protection in transit. My client felt the cost of using encryption in transit is fairly low, but there are other potential costs. If the link were breached by say a man-in-the-middle-attack (MITM), and that sensitive data was captured by unauthorized outside parties, the cost would go up dramatically and quickly.
The remaining steps are straightforward.
You share results with the stakeholders, prepare a report and deliver the report to the appropriate parties that commissioned the study. Publishing the report is the decision of the owner, not necessarily the person/team who performed the analysis. A report could possibly be deemed too sensitive to be distributed publicly if a private company. Public firms, such as government entities, typically publicly publish reports due to transparency.
That is it. At a high level these steps lend themselves to a project, with a defined beginning, end, and a goal, so a project manager can be assigned to push it to completion. A project charter would help with the scope definition up front and maybe avoid problems down the line when scope creep could possibly happen.
In closing, I have noted that privacy inevitably deals with the legal department in many firms. If you are looking for a place to start, that would probably be your best bet by asking, “Do we have any privacy concerns?”
SecureTrust, a Trustwave division, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.
CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.
Drew Cathey has been a member of the SecureTrust team for five years and has been in IT for 35 years. Coming from a background in telecommunications IT operations, he has held positions in engineering, project management and IT security. Drew holds degrees in biology, engineering and an MBA in Information Technology management along with PMP, CISSP, CISA and QSA certifications. He resides in St. Petersburg, FL with his two children and enjoys running, bicycling and tennis.