|
|
 |
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.

[Continue
to Part Four]
[Back
to Part Two]
[Back to Table of Contents]
|