I am very careful on the scoping activity in any project, let alone a privacy specific one, it is all too easy for other ‘related’ elements to creep in. They are not really invisible (I sort of think about this dog I had when I was little, who knew he is not allow to sit in the armchair and would creep up whilst you’re watching TV, bottom upwards watching you all the time, checking you don’t notice), but it’s easy (and for the -not so invisible- dog, amusing) to ignore, until it is too late, and then you as PM get the backlash for allowing your project to grow in scope.
This is why I have created some rules when it comes to: a) rolling out a privacy program, and b) conducting a PIA, which I am going to share with you now.
1. Separate corporate risk from privacy risk
Corporate risk belongs with the business risk guys, and privacy risk belongs in privacy program team, either at the program level or at the project level. However, clearly risk identified at the project level (PIA) can transpire as corporate risks, and this is why we get confused, and your project gets out of scope. But I can hear you saying….After all it is a privacy risk assessment, which means you must do corporate risks too, like ‘brand damage’? Sorry, but the short answer is No, at least that’s not how I see it.
Now here is the long answer…..There needs to be a clear definition so those involved understand the parameters of corporate risk versus privacy risks, i.e. Some privacy risks can surface into corporate risks, but these are not normally specific to a single data-set, unless the company only has a single product or service. Privacy risks managed at the corporate level are those activities at the program level, e.g. Privacy policy/notice, T&C, lack of evidence, lack of procedures to the rights of the data subject, etc. Corporate risks such as ‘brand damage’ should not be included in a privacy risk assessment. If they are included, there is risk of overlap and confusion. That doesn’t mean that the risk of ‘brand damage’ is ignored, No.
You may for example find that your project involves collecting personal data (potentially sensitive) which is new. It is your job to inform the corporate guys that the scope of their corporate risk assessment on ‘brand damage’ needs to be extended to include this new data-set (target of your PIA for example), and you need to provide them with the information necessary to enable them to do this. They have the threat landscape which they’ve translated into organizational risks, against which are mapped mitigating controls, and one of these will be the PIA that you are conducting. From their level they can place into context at the organizational level factors identified in the PIA, i.e. this is new sensitive personal data being collected, that are risks at the corporate level. This helicopter view enables them to make strategic decisions on spend across the organization which offers an economies of scale you will not see at the project level.
2. Breakdown PIA into simple discrete steps
Now I hear you, my Followers calling out, but what is a Privacy Impact Assessment, if it doesn’t include a risk assessment? After all that seems to be all that everyone is talking about when discussing a PIA. Well there is a privacy risk assessment. I have a 7-step PIA process which is pulled from best practices around the globe, and made simple. There is no standard globally yet, so this is what I use, until something better comes along!
The PIA is more than a risk assessment, it is more than documenting data flows, and this why it makes sense to create steps, then it is easy to assign appropriate tools fulfill the task at hand.
- Identify entry points – for the data-set being assessed, e.g. web-page, email, etc., there maybe multiple entry points.
- Purpose necessity – of personal data collected, and alignment with Privacy Notice, identify Purpose mismatches, i.e. personal data-set being assessed has no purpose!
- Accountability boundaries – where do they start and stop, who is the Controller/Processor?
- Personal data lifecycle – document the personal data life-cycle flows (PDLC)
- Use mapping – map Use to Purpose, identify mismatches
- Privacy Risk assessment – identify potential harm to data subject, and those risks (outside of PIA scope) that should to be passed up to privacy program risk and corporate risk teams
- Legal compliance – with national data protection laws, e.g. GDPR, heathcare laws, etc.
3. Separate security from privacy
I have been challenged -mainly from security guys, that it is smarter economies of scale to place privacy and security in the same project/budget/systems/applications, etc? I’ve already talked a lot on the importance of keeping privacy and security separate. However, this does not stop both coming under the information security umbrella, but I still insist that they must be treated separately. Why?
Because personal data belongs to the data subject, and IP belongs to the organization.
It just doesn’t work to treat personal data identically to intellectual property (IP) of the organization, because the compliance needs are completely different. Clearly personal data needs to be protected from unauthorized access, modification, etc., same as IP, but this is where the similarities end. One example, is to think that a large component of compliance with the GDPR is to do with the Rights of the Data Subject; they have the right to know if you collect, what you collect on them, and if it is stored, and for how long, etc. They have the right to challenge the quality of personal data which your organization collects and keeps in storage, and right for redress if you refuse. Your organization needs to have the business processes and techniques in place to comply with these requirements. It just doesn’t make technical or business process sense to physically/logically store personal data together with organizational IP. So I would love to know where are the economies of scale are now?