Privacy Impact Assessments (PIA)—the process of identifying, evaluating, and managing privacy risks—can be one the most challenging aspects of getting started on projects in (and with) the BC Provincial Government. A poorly executed PIA can pose project risk through delays, confusion, and misalignment. As providers of design research, service design, and application development work in government, we have to do a lot of PIA's. Some go well, others not so much.
Having worked with and for government for 20 years, we realize that our experience is not unique. Misunderstanding of the PIA can happen among public servants as much as it can with vendors.
With that in mind, we wanted to shed some light on an often misunderstood and opaque process, a process essential to respecting the privacy of citizens and engendering trust in government.
The purpose of this piece is not to provide a detailed guide to the legislation. (That can be found here and we recommend a read-through if you want a deeper dive.) Instead we want to share lessons learned from our experience in navigating the PIA process as part of design research and service design projects.
In doing so, we hope this post will help you better manage the PIA process and get on with the important work of delivering government projects, programs, and services.
So let’s start at the beginning.
Why do you need to undertake a PIA on your project in the first place?
Simply put, it's the law.
From the BC Government’s PIA Guidelines PDF:
“Completing a PIA is a legislative requirement. A PIA is an assessment tool used to evaluate privacy impacts, including compliance with the privacy protection responsibilities under FOIPPA (Freedom of Information and Protection of Privacy Act). PIAs promote transparency and accountability, and contribute to continued public confidence in the way government manages personal information.”
BC has some of the most thorough and stringent privacy legislation in Canada. It aims to protect personal information while balancing the need for open and transparent government through access to information.
What exactly is "personal information"?
The following is FOIPPA’s simple yet broad definition of personal information:
Recorded information about an identifiable individual other than contact information.
This includes, but is not limited to:
- name, address, email address, or telephone number;
- age, sex, religious beliefs, sexual orientation, marital or family status, blood type;
- an identifying number, symbol or other particular assigned to an individual;
- information about an individual’s health care history, including a physical or mental disability;
- information about an individual’s educational, financial, criminal or employment history; and
- personal views or opinions.
You don't need to be a design researcher or work on service design projects to see how broad citizen data collection in government can be. Using a simple survey to gather data? Engaging with citizens on Twitter or Facebook? Allowing comments on your government YouTube video? You are working with personal information. Protection of that information needs to follow government standards and guidelines.
While the government website presents the PIA process from initiation to final submission as a simple seven step process, the reality is that the understanding of this process varies not only by ministry, but by business or program areas within ministries.
We reflected on our experience of the PIA process over the years. It resulted in three key project considerations:
When to start the PIA for your project
what to include in the PIA about your project
and, as a result of the above,
how the PIA process can impact your project timeline and budget.
Here's our advice on how to manage the PIA process for your next service design-oriented government project.
Lesson one: get started ASAP.
For some projects, the PIA has been in motion before we’ve even signed the contract for project work. That's good news.
Other times, we’ve found that the PIA process is often initiated once the contract is signed and the alignment phase is already underway in earnest. You’re in meetings planning design research and excitement is building. You’re already looking ahead to the outputs from the discovery phase and how they can influence the design and development of policy or service.
Then someone casually asks "Hey, do we need to do a PIA for this?"
No one is really sure. But, as we’ve learned, all project-based work in the BC public service is subject to a PIA. So yes, it is required!
Someone contacts the ministry privacy officer. The privacy officer sends the assessment paperwork over. Writing begins. Language and tactics are debated, reviewed, and rewritten. Weeks pass, full of internal team revisions before the draft assessment is even submitted back to the privacy officer. Suddenly your project timeline is out the window. Depending on the project owner's level of risk tolerance, there’s a strong likelihood you’ll be full-stop waiting for the assessment to occur.
As a vendor, this can have a serious effect on your own capacity management and utilization. As a public servant, this can push out timelines, create undue pressure on your team, and risk running afoul of fiscal spending deadlines.
Our advice: Be proactive and start the PIA the moment you receive approval for the project. Don't wait for some magical "right time" to deal with the documentation. Get your project in front of the privacy officer as soon as you can. Everything will flow more smoothly from there.
"But what if I don't know what the activities of the project are? How can I get in front of the privacy officer if I don't know what to ask for?" you say. "What do we put in the PIA?"
Lesson two: establish a shared understanding of project activities early and often.
Sometimes our government clients put work to tender without fully understanding the proposed approach. This is in no way a critique of this model: their expertise lies in managing and delivering a program area. Which is likely why they contract vendors and experts in design research or service design.
Public servants may have a high-level understanding of design thinking and service design. They might be familiar with some of the tactics (e.g. field research) and outputs (e.g. journey maps). This may not be enough. This knowledge gap can be the root cause of why the PIA wasn't started. It's not that someone was forgetful or ignored it or hoped the PIA would just go away. It's that the team didn't understand what content to put in the PIA, what design research activities look like, and how to describe them.
That's why it is important to develop a shared understanding of the proposed approach as soon as you can. Review the tools, tactics, methodologies, and outputs to ensure alignment. This is critical not only during the PIA period, but for the project as a whole.
A project owner is unlikely to submit a PIA if she doesn't understand the content. You may need to expose yourself to some project schedule risk by taking time to share knowledge and gain this understanding to mitigate much larger privacy risks down the road.
Our advice: Establishing an early, detailed, and shared understanding of the project work (tasks, methods, tools) benefits the project two-fold. It creates content for the PIA and it helps educate all team members on methods they may be unfamiliar with. It's valuable for the entire project team to understand what fieldwork entails or how interview data is collected, especially when this project may be their first exposure to design research or service design.
Lesson three: use templates whenever possible.
PIA templates now exist that have been vetted and approved at the highest level. This is thanks to the hard and thorough work of big-picture thinkers in government who have witnessed how PIAs can be a project blocker. For example, the Government Digital Experience Division (GDX) has developed a blanket PIA template which covers all common service design approaches. While you’ll still be required to submit your specific project PIA for evaluation by the associated ministry, the chances of an expedited approval are increased thanks to these templates.
Our advice: If it worked once, it’ll likely work again. Ask your ministry partner or client if they’ve submitted successful PIAs before or if they work from a standardized template. Connect the ministry privacy officer with the template author if they have any questions or concerns. Avoid doing things over. Government is a culture of precedence, use that to your advantage.
Lesson four: establish a line of communication with the privacy officer.
This may seem obvious, but be proactive in establishing an open line of communication with your ministry privacy officer(s). Don’t be afraid to follow up with them as required. These public servants work on a wider portfolio of responsibilities than your PIA. It's not uncommon for things to get lost in the shuffle as a result. They also do not share the same urgency as you in getting your project going and meeting certain milestones. Nor are they as emotionally invested in the goals of your project or share the same excitement or attachment to the work. Their job is to evaluate risk. Often that means being be analytical and skeptical of your work.
Research activities that feel like standard practice to design and technology practitioners can feel quite novel to those working in privacy. Novelty and innovation can be perceived as threatening, risky, or suspicious. The privacy officer's job is clear: they protect the security of the public’s personal information. They’re accountable for your information management practices having signed off on the PIA. They take that responsibility seriously.
Our advice: Be accessible, plain-spoken, and clear about the project; this is the best way to help privacy offices do their job. The sooner the privacy officer understands the work, feels assured, and approves the work, the sooner you'll be in the field doing research.
Lesson five: be prepared to wait and do what you can in the interim.
Privacy Impact Assessments are slow by design. The nature of the process is rigorous, analytical, and dispassionate. We’ve seen them take from two to six weeks or longer, with clients allowing varying amounts of project work in the interim. Anticipate that there could be a full-stop to the work during this period, and you may spend weeks in total stasis.
Full-stops can place utilization pressure on vendors - their staff are being paid, but are now incapable of generating revenue. If you want to keep your vendors around and on-board, you may need to re-work the project plan. What other activities can be done in the interim that don’t require a PIA?
Our advice: Build your project schedule to include an assessment period. Best case scenario, the PIA is approved earlier than you expected and you’ve gained some contingency time to the overall project schedule. Worst case: build your project schedule with contingency and be aware that six weeks waiting for a PIA to move forward may be a reality.
Finding work to be done in the interim requires careful consideration about what is in and out of bounds during the assessment period. But it's not impossible. Desk research is an obvious activity: going through past reports or service plans, for example.
You can also work on a list of tasks and activities pre-project to tackle during any potential delays. Some examples of this can include:
- Research plan drafting and internal revisions
- Interview subject outreach and relationship building
- Interview compensation coordination (establishing stipend type and denomination, purchasing)
- Interview script drafting
- Interview release form drafting
- Travel logistics for fieldwork
Having a list of admin-related tasks helps ease feelings of frustration when you’re experiencing a lack of momentum in the work. And this way you’re ready to hit the ground running once you receive approval.
Lesson six: create internal systems that adhere to government privacy standards.
Make sure your internal process and toolkits are inline with relevant standards and guidelines. Follow the rules.
For example, data storage of personal information: the Google suite of apps is a no-go with the BC Government. Government requires personal information to be housed on servers located in Canada. Where will you store and share your notes from interviews, photos, video, and contact lists? What about interview release forms and stipend receipts? Does your text meet the legal requirements of the Province? Will these be required for submission as part of your PIA? Can you work with privacy, project management, and the program area to create templates that can work in the future as well?
Our advice: Internal systems and processes generally come about as a product of experience. FOIPPA can have a restrictive effect on the tools you’re allowed to use during a project (no Slack!), but there are plenty of useful and appropriate alternatives if you’re prepared. The trick is to work on this in advance of government projects, so that systems are tested and ready for when the real work commences.
PIA's are crucial to working with citizens. And working with citizens is crucial to designing better government services.
As designers working with and for government, we appreciate and respect the PIA process. As designers in the public service we are also accustomed to looking at how policy is made tangible and how a service is experienced. Our respect and appreciation of the PIA process is not to be confused as endorsement -- and like any experience of policy, we believe it can be improved.
To invoke some of the language of service design, much of what happens during the waiting periods and back and forth with privacy offices occurs beyond the "line of visibility" in our imagined PIA service blueprint. Privacy officers communicate with the Office of the Chief Information Officer (OCIO) privacy analysts. Opinions are sought. Disagreements are had. The wheel seems to be re-invented every time a PIA is sent in. But it's opaque, a black box. We can only guess as we aren't typically granted access to those discussions. Like hitting reload on a FedEx package tracking system that only shows two states "In progress" or "Delivered," we are simply left to sit and speculate about when our PIA is going to arrive and what’s going on behind the scenes.
We would like nothing more than our practical advice on how to manage the PIA process and plan for significant delays to be made obsolete, through a faster, better understood PIA process across all ministries. We hope this piece can be a contribution to a dialogue that continues the improvement of the PIA, taking into account the perspective of a vendor working alongside government to do important privacy-compliant work.
We hope you benefit from these insights when navigating the PIA process in the British Columbia Public Service.
Interested in continuing the conversation? Get in touch with our service design team.