Government of Ontario
About the Ministry Services for Business Services for Individuals Employment in the OPS Information Technology Archives of Ontario Related Sites

Privacy Impact Assessment Guidelines

PART THREE

An Overview of the Process

A Privacy Impact Assessment (PIA) is a process that helps to determine whether new technologies, information systems, and proposed programs or policies meet basic privacy requirements. It also measures both technical compliance with privacy legislation, such as the Freedom of Information and Protection of Privacy Act (FIPPA) or the Municipal Freedom of Information and Protection of Privacy Act (MFIPPA), and the broader privacy implications of a given proposal. The PIA is also intended to help policy writers and decision-makers manage potential privacy risks.

The three components of the PIA process include:

Conceptual Analysis

Data Flow Analysis

Follow-up Analysis

Prepare a plain language description of the scope and business rationale of proposed initiative

Identify in a preliminary way potential privacy issues and risks, and key stakeholders

Provide a detailed description of essential aspects of the proposal, including a policy analysis of major issues

Document the major flows of personal information

Compile an environment issues scan to review how other jurisdictions handled a similar initiative

Identify stakeholder issues and concerns

Assessment of public reaction

Analyze data flows through business process diagrams, and identify specific personal data elements or clusters of data

Assess proposal's compliance with FOI and privacy legislation, relevant program statutes, and broader conformity with general privacy principles

Analyze risk based on the privacy analysis of the initiative, and identify possible solutions

Review design options, and identify outstanding privacy issues/concerns that have not been addressed

Prepare response for unresolved privacy issues

Review and analyze physical hardware and system design of proposed initiative to ensure compliance with privacy design requirements

Provide a final review of the proposed initiative

Conduct a privacy and risk analysis of any new changes to the proposed initiative relating to hardware and software design to ensure compliance with FOI and privacy legislation, relevant program statutes, and broader conformity with general privacy principles

Prepare a communications plan

 

The end result of a PIA process is documented assurance that all privacy issues have been appropriately identified and either adequately addressed or, in the case of outstanding privacy issues, brought forward to senior management for further direction. 

The ability to provide such assurances is largely dependent on the extent to which all relevant factors and potential privacy issues have been considered. Sponsoring ministries should, therefore, ensure that they take into account the following four key areas as they work through this process:

  • PEOPLE, consider on-going management, privacy training programs, general organizational awareness of privacy and security issues, an assessment of the level of knowledge required to perform specific functions, the availability of manuals and other forms of guidance, and mechanisms for communicating privacy and security policies.
  • PROCESS, consider what information is collected, why and how it is collected, how privacy and security are ensured operationally, and what mechanisms are in place to provide individual access to information.
  • ENVIRONMENT, consider the physical space where information is housed, physical security measures, the availability of secure document disposal facilities, and processes for secure disposal of old computers that may hold personal information.
  • TECHNOLOGY, consider system design characteristics, data security and integrity measures, access controls, and audit trails.

 

Where to Begin - An Overview of the Process

While a final, complete PIA will include all three components, (e.g., proposal description and rationale, the data map, the privacy analysis, risk analysis, etc.) different components of the PIA may be useful to managers and system designers at various stages in the decision-making process.

For example, if a project is at the Conceptual Analysis, it will be helpful to decision-makers to have a sense of what privacy issues may arise, and what options are available for avoiding or addressing those issues. In this case, it will be more useful to begin with a general analysis of the issues and risks that may arise in relation to a given initiative. Where decisions are being made about system design, by contrast, it may be more helpful do a rough data map in order to understand the implications of different design choices.

Early work on the PIA enables early identification of major issues, allowing project managers and system designers to examine business process and technology options to reduce or eliminate privacy-related issues as the project moves forward. Wherever the process begins, the PIA should be updated at each major project development milestone so that there is no need for a major re-documentation when final approvals for detailed design and implementation are sought. Outlined below is a detailed description of the three components of the PIA process beginning with the Conceptual Analysis.

Conceptual analysis

The Conceptual Analysis is intended to provide a detailed description of the essential aspects of the proposal (e.g., scope, business rationale, etc.) and an environmental issues scan, and identify significant privacy issues and potential risks so that decision-makers have a comprehensive understanding of the potential privacy implications that 

the proposal may generate. For example, a proposal to create a new database (or modify an existing database) that contains particularly sensitive information would require a fairly detailed conceptual analysis to ensure that key issues and risks, stakeholder concerns and input related to such a proposal are thoroughly identified and addressed.

At this stage in the PIA process the overall level of analysis of the proposal and the information provided will be less detailed than that which is provided at the Data Flow Analysis. At the next stage in the assessment process, project managers will be expected to provide more detailed information regarding data flow diagrams, privacy analysis and risk analysis. However, the key objective of the Conceptual Analysis is to establish for decision-makers a general understanding of what the proposed initiative intends to do, and what privacy and stakeholder issues may generally emerge as a result of the proposed initiative.

The conceptual analysis may include a number of features. The first is the identification and description of the business initiative that is being proposed, including high-level information regarding the initiative's scope and rationale, and describe how the initiative fits into the broader business planning cycle of the sponsoring ministry and the government.

The second is a detailed description of the essential aspects of the proposal that includes a comprehensive policy analysis of the proposal's major issues. For example, this description might include an examination of the business case and rationale for using personal information. In some cases an initiative may be able to achieve its business function by using anonymous data instead of personally identifiable information. The analysis of the proposal's essential aspects might also examine whether or not the initiative will introduce new technology options. If so, the technology should be analysed to ensure that it does not unintentionally introduce new privacy risks.

The third feature, a high level documentation of major flows of personal information, is an integral part of the PIA process. Before a thorough privacy analysis of a proposal can occur (see Part Four - PIA Tool Kit for specific analysis questions), the flows of personal information need to be identified and documented.

An initiative's activities can be described from an information management perspective as a series of processes consisting of:

  • Information collection (data inputs);
  • Transaction processing involving the application of rules, validations and decision-making;
  • The provision of a product or service in terms of a decision, benefit, or licence (output); and
  • Transactional data recording the above events. These may be temporary records such as system logs, paper forms used prior to input, and data records or subject files in any media.

The fourth feature of the Conceptual Analysis is an environmental issues scan to review how other jurisdictions have handled a similar initiative. Reviewing the experiences of others will assist project managers in identifying the key privacy concerns and risks of a given proposal. It may also reveal how another jurisdiction solved a specific privacy challenge.

The fifth feature is the identification of stakeholder issues and concerns. This stakeholder impact analysis can assist program managers and decision-makers in anticipating broader reactions to proposals that may have implications for the protection of personal information. Stakeholders include anyone or group who has an interest or concern, or who may be effected by the proposed initiative. It is important that stakeholder views are properly documented and addressed whenever possible. Conducted early in the process, such analysis can help to eliminate hardware, software and/or system design options which may meet with significant stakeholder resistance.

The final feature of the Conceptual Analysis is an assessment of the public reaction towards the proposed initiative regarding its implications for the protection of their personal information. The risk of a proposal meeting with public concern about privacy is present wherever the collection, use or disclosure of personal information is at issue. Assessing the public's reaction toward a proposal can assist decision-makers in anticipating broader public reactions, and help identify what steps need to be taken to improve overall acceptance.

The risks associated with failing to consider the privacy implications of a given proposal can take many forms. For example, if a proposal fails to comply with either the letter or the spirit of FIPPA/MFIPPA, or fair information principles more generally, it may receive public criticism from the Information and Privacy Commissioner (IPC). This criticism may then stimulate public outcry about a perceived loss of privacy or failure to meet expectations about the protection of personal information.

Depending on the type of initiative being proposed or the level of complexity involved, ministries may find it useful to consult broadly with the public or narrowly with key stakeholders. It is assumed that ministries preparing to undertake such consultations will work with their communications branches in developing a communications strategy.

In addition to public consultations, ministries may also wish to monitor public opinion on related topics that may be relevant to their proposals. Such monitoring may assist in anticipating public reaction, and should focus not only on privacy-related issues that may arise in the province, but also on public reaction to similar proposals in other jurisdictions. This will provide a sense of the environment into which the proposal will be received, and may be a good indicator of public expectations. Conducting public assessment early in the process may help to eliminate options which meet with significant resistance.

 

Data Flow Analysis

The Data Flow Analysis provides comprehensive documentation of data flows through business process diagrams, identifies specific personal data elements or clusters of data, assesses the proposal's compliance with FOI and privacy legislation, relevant program statutes and broader conformity with general privacy principles, and identifies potential privacy risks to provide solutions. This component of the PIA process should also review design options, and identify outstanding privacy issues/concerns that have not been addressed, and prepare response for unresolved privacy issues.

This stage may have three features. The first is to analyze data flows through business process diagrams that illustrate the major components of the proposal including specific personal data elements or clusters of data. This stage in the PIA process involves a detailed analysis of data flows by elaborating on the business process diagram.

The documentation of data flows involves a two-part process. The first is the preparation of a business process diagram. At a minimum, the diagram should identify at a general level the major components of the business process and how personal information is collected, used, disclosed, and retained through this process.

The business process diagram may be prepared using any of a number of methodologies. In choosing an approach, ministries should consider the nature and complexity of the proposed project. Some possible approaches to mapping the business process would include flow charts, structured analysis and/or object-oriented analysis (see Part Four - PIA Tool Kit)

While the business process diagram documents the high-level flow of personal information, it does not provide an adequate level of detail for a comprehensive privacy impact assessment. Thus, the second part of the documentation process involves a more detailed analysis of data flows that builds on the business process diagram. The framework and key questions for the privacy analysis can be found in Part Four - PIA Tool Kit.

The second feature is an assessment of the proposal's compliance with FOI and privacy legislation, relevant program statutes, and broader conformity with general privacy principles through a structured privacy analysis.

As a process, a PIA is designed to provide evidence of compliance with privacy principles. The privacy analysis contributes to this goal by taking project managers and system designers through a series of key questions (see Part Four - PIA Tool Kit for specific analysis questions) that identify how personal information is collected, used, and disclosed, and interrogate a proposal's technical compliance with legislation and general privacy requirements. Additional questions assist in anticipating how the public is likely to react to key issues associated with the proposal. The goal, therefore, is not simply to ascertain that legislation and privacy requirements have been met, but also to flesh out and bring to the attention of decision-makers broader privacy issues that may raise public concerns.

Not all questions in the analysis section will be relevant to every proposal. By the same token, the questions listed may not reflect all the considerations that will be important in a given context, particularly where program statutes may outline particular requirements with regard to privacy, or where there is evidence (e.g., from other jurisdictions) that public concern may focus on a particular element of a proposal. Consequently, this section can and should be modified where necessary to ensure that all relevant questions have been considered. Questions should not, however, be focused solely on strict technical compliance with legislative requirements, but should also attempt to identify areas of potential public concern.

The final feature of the Data Flow Analysis is to undertake a risk analysis based on the conclusions generated by the privacy analysis, and when possible provide solutions to address these risks. In those few cases when a solution to privacy concerns are not fully resolved, a legitimate rationale should be provided for why the concerns where not addressed, and brought forward to senior management for further direction

Follow-up Analysis

The Follow-up Analysis is intended to provide a review and analysis of the proposed initiative's physical hardware and system design to ensure that what is eventually built complies with basic privacy design requirements.

Although the substantive data flow analysis and privacy analysis will have already taken place during the Conceptual Analysis and Data Flow Analysis this stage provides further opportunity to identify any circumstances where privacy may be a at risk in the initiative from a physical design and implementation perspective.

Analysis of the proposed initiatives' physical components may reference the Enterprise Information and Information Technology Architecture Privacy Design Principles (EIA Privacy Design Principles). The EIA Privacy Design Principles represent an assessment and compliance framework that is based on both the statutory requirements in FIPPA/MFFIPA and the ten fair information practices in the CSA Model Privacy Code. The Ontario government specifically developed these principles to support the design and implementation of initiatives that will meet basis privacy requirements such as compliance with provincial FOI and privacy legislation and general privacy principles.

By designing initiatives with privacy design principles built in at the out set ensures that the initiative that will be eventually built conforms to basic privacy requirements such as allowing individuals to make informed decisions regarding the purposes for which their personal information is collected and disclosed). Therefore, the analysis of the initiative's physical hardware and system design is critical step in the privacy assessment and compliance process. Consequently, the Follow-up Analysis is intended to provide a final opportunity for project managers and system designers to review whether or not hardware, software and system design issues and concerns related to the proposed initiative have been thoroughly identified and addressed.

In some cases new changes to a proposal may require further privacy and risk analysis. The analysis of new changes ensures compliance with FOI and privacy legislation and relevant program statutes, and broader conformity with general privacy principles. At this stage, the privacy and risk analysis should focus specifically on the new changes and not the entire project. This is analysis should assess the potential impact of the new changes, provide a detailed rationale for why the changes where made, and if necessary indicate what solutions are being proposed to address and mitigate potentials privacy concerns.

A communications plan should be developed in preparation for the implementation of the proposed business initiative. This particularly important if privacy issues or concerns were identified during the PIA process. In such cases the communications plan should include messaging that specifically addresses what issues or concerns were identified and how they have been resolved. In those few cases when privacy concerns were not fully resolved, a legitimate rationale should be prepared for why privacy concerns where not addressed.

Back to Top

[Continue to Part Four]

[Back to Part Two]

[Back to Table of Contents]


This site maintained by the Government of Ontario