In my August blog I offered seven tips for how to conduct effective Privacy Impact Assessments (PIAs), and then I sat back and felt very pleased with myself for solving all the world’s problems. OK, not all of the problems, but at least the problem of how to assess new projects for privacy risk. But then BAM! Out of the blue in September we had the story about a Sydney high school implementing finger scanning technology just so kids could go to the toilet.
Now I do have sympathy for the school principal, who was likely at the end of her tether about what to do about vandalism at the school. I also imagine that school principals know better than me what is best in terms of the education and well-being of their students. However I do not imagine school principals to be experts in conducting privacy risk assessments of new technologies – and nor should they be!
For some time now, education departmental policy has been to give school principals autonomy over decisions for their school, including the implementation of technology. But that obviously creates risks. So that incident with the high school highlights a really critical compliance risk for all organisations, which is the problem of ‘shadow IT’.
The question for privacy professionals is whether you know what technology other people in your organisation are buying or implementing. And if you don’t know, what privacy risks are they introducing? And how are you going to assess and mitigate those risks?
You might be great at conducting PIAs, but if people across your organisation don’t know that they should come to you for an assessment before they go and implement some new tech, or design a new product, or change a business system… well then, those PIA skills are going to waste.
You’re going to need a PIA framework as well.
In my experience, there are a number of matters which need to be considered, in order to develop a successful PIA framework, such that PIAs become embedded into an organisation’s standard risk assessment methodology.
So to help you draw up your blueprints, here are nine tips on how to build a PIA framework for your organisation. If my previous piece on PIAs was the ‘what’, consider this month’s contribution as the who, when, how and what next.
Align with enterprise risk management framework – or go broader
When assessing the level of privacy risk posed by a project, a PIA should align with the organisation’s risk management framework, which may include a risk rating methodology, risk appetite statement, and/or categorisation of business impacts.
A PIA should include, for any particular privacy impact identified, an assessment as to:
- the likelihood of the risk eventuating (e.g. from ‘rare’ to ‘almost certain’), as well as
- what consequence (e.g. from ‘insignificant’ to ‘catastrophic’) might arise for:
- one or more affected individuals, and/or
- business impacts for the organisation.
In our experience, some organisations’ risk management frameworks have been developed with primary reference to information security, rather than overall data management. As a result, some risk frameworks consider only the impacts which could arise from the ‘compromise’ of data. Such frameworks will be focused on preventing data breaches and unauthorised disclosure of personal information.
However privacy considerations must extend much further than just unauthorised disclosure, or a data breach. A PIA will need to consider privacy impacts on individuals even when the system works exactly as planned. When you think about some of the really big tech project failures and scandals, from Cambridge Analytica to the Australian Government’s ‘robodebt’ program, the harms were not caused by the technology failing, or by failures of information security, but were the terrible consequences of human decisions made to allow the collection, use and disclosure of personal information in the first place.
Clarify what constitutes a ‘project’ to be assessed
Settling what constitutes a ‘project’ to be assessed under the PIA Framework will be important. Should it be every activity which will involve any handling personal information? And what do we mean by ‘handling’ personal information anyway? (The Privacy Code for Australian government agencies defines handling personal information as “dealing with personal information in any way, including managing, collecting, holding, using or disclosing personal information”.)
Or do you only want to capture every activity which will change the way personal information will be handled? Or only every ICT project?
Build in gateways or triggering mechanisms
It will also be important to ensure there is clarity around the triggering points for application of the PIA Framework.
For example, you may need to have triggers spread across:
- business case development
- change management processes
- procurement processes
- budget approval processes
- ICT project initiation, etc.
Ensuring that the triggering points encompass all manner of activities is important, as the Australian Federal Police (AFP) discovered. The OAIC found the AFP in breach of APP 1 and the Privacy Code for failing to conduct a PIA on the use of new software. Even though the AFP had policies, guidance and a procedure for conducting PIAs, the adoption of Clearview AI technology by members of one unit bypassed all the normal procedures for assessing privacy risks of new projects. Because individual officers set up free ‘trial’ accounts to use the facial recognition software, no funding or procurement processes were involved, and therefore nothing triggered a privacy impact assessment.
Triage according to inherent risk
A common problem we see is a PIA Framework which captures all projects, and all types of changes, and then applies the same risk assessment methodology to everything. In reality, some projects are obviously more likely to create negative privacy impacts or compliance risks than others, so the most comprehensive form of assessment should be left for the more inherently impactful projects.
Thus while I recommend taking a broad approach to defining the types of activities which will constitute a ‘project’ for the purpose of triggering application of a PIA Framework, this does not mean that every single project will require a PIA.
Instead, the PIA Framework should enable projects to be very quickly assessed against some threshold criteria, and sorted into inherently low, medium or high risk categories. Only the ‘high risk’ projects will typically need a comprehensive PIA. Medium risk projects may require some review and documented advice from a privacy advisor, while low risk projects may only need informal advice.
Determine what constitutes a high risk project
The Privacy Code notes that “a project may be a high privacy risk project if the agency reasonably considers that the project involves any new or changed ways of handling personal information that are likely to have a significant impact on the privacy of individuals”.
The OAIC has issued guidance on the types of factors that may point to the potential for a high privacy risk project, as has the European Data Protection Board. Some factors relate to the nature of the data (e.g. health data, location data), the nature of the people involved (e.g. children or other vulnerable populations), the nature of the tech involved, the nature of the activity, or the consequences for individuals.
You will need to tailor the list to suit your organisation. For example, the presence of children in a dataset alone would not be a ‘high risk’ factor in the context of a school (since so much of their data is about children), but should absolutely ring alarm bells for an online gambling website.
(We have drawn on various regulators’ lists with our own experience to produce a template Threshold Privacy Assessment tool, which is included in our PIA resources found in a number of our Compliance Kits.)
Settle who should conduct the PIA
A PIA Framework should establish who should perform what tasks in a PIA process. How this should be developed will depend on the availability of specialist privacy advisors within the organisation, their location (e.g. is there one central privacy team, or are there pockets of privacy expertise across different business lines), as well as the extent to which project managers have the skills to themselves assess privacy risk and develop solutions.
A project manager, loosely defined, may be able to answer a questionnaire about compliance with privacy requirements, but would not typically develop findings or recommendations about addressing privacy impacts. Someone with privacy subject matter expertise will be needed to complete the assessment, and write up the PIA Report. However this will need to be a collaborative effort, with the project manager on hand to answer questions about the nature of the project.
Develop the PIA methodology
The OAIC has guidelines available on the ‘how’ of conducting a PIA, but for each organisation you will need to be clear about what the deliverables should be, such as what should be included in a PIA Report, and how it should be structured.
(We also offer training in how to conduct PIAs, both via small group workshops and online modules, and resources such as privacy risk assessment questionnaires and PIA report templates to guide people charged with conducting a PIA.)
Map out what should happen with a PIA Report
A PIA Framework should clarify what should happen with completed PIA reports, including:
- who needs to complete the risk rating methodology
- who needs to approve the PIA Report as completed
- who needs to be provided with a copy of the completed PIA Report
- when and where the PIA Report is to be shared with stakeholders or published
- where residual risks are to be recorded (e.g. in a project or enterprise risk register)
- in relation to any risks rated as ‘high’ or above, to whom these need to reported for formal acceptance (e.g. the project sponsor, the Board, an Audit & Risk Committee, or the senior leadership team), and
- who has the power to stop the project from proceeding until something else has happened (i.e. the risks have been lowered through additional controls, or the risks have been formally accepted).
Socialise the framework
Once a PIA Framework has been settled, it will be important to socialise the framework so that all staff know that it exists, and when it applies. This means more than just publishing your PIA Framework to an intranet page.
Again, the AFP experience is instructive, with the OAIC ordering that the AFP train “all personnel that handle personal information”, not only in terms of foundational privacy compliance training, but also the more advanced topic of privacy risk assessments, including “how to undertake such an assessment, when to do so, and when to involve the Privacy Officer or other privacy experts”.
So your PIA Framework can’t just be ‘set and forget’: everyone needs to know when PIAs will be needed, the basics of how to do one, and what their role will be.
And that concludes my architecture lesson. Hopefully these nine tips will set you on your way to design, build and implement your very own PIA Framework.
With easy-to-use templates + Salinger Privacy know-how via checklists and more, we can help you build your PIA Framework and steer your PIAs in the right direction. Take a look at our complete range of Compliance Kits to see which suits you best.
Photograph © Daniel McCullough on Unsplash
