|
|
 |
Privacy Impact Assessment Guidelines
PART TWO
What
is Privacy?
Privacy encompasses a number of inter-related
values, rights, and interests unique to individuals. It is generally considered
to have at least four dimensions:
- Privacy of the person:
refers to the integrity of an individual's body, and spans issues such as
compulsory immunization, blood transfusions, or sampling of body fluids or
tissue.
- Privacy of personal
behavior:
refers to the right of privacy relating to such matters as sexual preferences
and habits, political activities and religious practices.
- Privacy of personal communications:
the right to communicate with others without routine monitoring.
- Privacy of personal data:
also called information privacy, this refers to the right to determine when,
how and to what extent you will share personal information about yourself.
This PIA methodology
is principally concerned with the privacy of personal data, or information privacy,
as it is generally the most relevant in the context of government proposals for
new or revised service delivery projects. Where a ministry proposes a course of
action that may have implications for other types of privacy, such as privacy
of the person, the PIA will continue to be relevant, but
will require additional questions and analysis focusing on the particular risks
raised by the proposal. Sponsoring ministries are encouraged to seek assistance
from the Access and Privacy Office in these cases.
An important aspect of information
privacy is freedom from surveillance. Surveillance is the systematic investigation
or monitoring of an individual's activities or communications. Its primary purpose
is to collect information about that individual, their activities, or their
associates.
The government's specific legal obligations
to protect the privacy of personal information are outlined in the FIPPA/MFIPPA.
In some instances,
additional requirements may form part of program statutes.
Under the FIPPA, personal information is recorded information
about an identifiable individual, including:
(a) information relating to the race,
national or ethnic origin, colour, religion, age, sex, sexual orientation or
marital or family status of the individual;
(b) information relating to the
education or the medical, psychiatric, psychological, criminal or employment
history of the individual or information relating to financial transactions
in which the individual has been involved;
(c) any identifying number, symbol
or other particular assigned to the individual;
(d) the address, telephone number,
fingerprints or blood type of the individual;
(e) the personal opinions or views
of the individual except if they relate to another individual;
(f) correspondence sent to an institution
by the individual that is implicitly or explicitly of a private or confidential
nature, and replies to that correspondence that would reveal the contents
of the original correspondence,
(g) the views or opinions of another
individual about the individual; and
(h) the individual's name if it
appears with other personal information relating to the individual or where
disclosure of the name would reveal other personal information about the individual.
Personal information must be about an
identifiable individual, however an individual's name need not be attached to
the information to qualify as personal information. A physical description or
a photograph of a person attached to other personal information about that person
is personal information even where no name is given. An individual's name on its
own is not personal information. To be personal information within the meaning
of the Act, the name must be associated with other personal information.
In addition to obligations to protect
personal information under FIPPA/MFIPPA, and relevant program statutes, ministries
contemplating proposals likely to effect privacy should be aware of general
standards for privacy -- such as the Canadian Standards Association's Model
for the Protections of Personal Information (CSA Standard) - which may influence
public opinion, and of how similar proposals in other jurisdictions have been
received. Such considerations may well be key to appropriately identifying the
privacy risks associated with the proposal.
ASSESSING PRIVACY
RISK IN GOVERNMENT SERVICE DELIVERY
The
Challenge of Electronic Service Delivery
Just as the private sector has begun
to invest in electronic commerce as a way of bringing consumers better service,
more choice and better prices, governments have begun to look to electronic
service delivery (ESD) as a way of interacting with the public more rapidly, more
efficiently, and more responsively.
Citizens, while welcoming client-driven,
interactive, integrated information and services from government, have some
concerns about privacy and security in electronic contexts. Studies show that
86% of Canadians are very concerned about giving out personal information on
the Internet, and 91% of Canadians are concerned about giving out credit card
information online.
Experience suggests that citizens
will not participate in electronic transactions where privacy and security concerns
have not been appropriately addressed. In some jurisdictions, public outcry
about privacy has resulted in programs having to be withdrawn or substantially
redesigned at a significant cost. As we design and implement ESD systems, then, we must be sensitive to the concerns that may arise
as a result of computerized information systems that can monitor, track, or
observe individuals without their knowledge or consent. These features may contribute
to a lack of public confidence, and must be addressed as a critical element
of achieving truly client-driven electronic service delivery. Well-designed
ESD systems can enhance both personal privacy and information security, minimizing
risk while providing better and more efficient service.
Perspectives
on Risk
The risk of a proposal meeting with
public concern about privacy is present wherever the collection, use, or disclosure
is at issue.
The risks associated with failing
to consider the privacy implications of a given proposal can take many forms,
and may include, for example:
- Stimulating public outcry as a
result of a perceived loss of privacy or a failure to meet expectations with
regard to the protection of personal information;
- Loss of credibility or public
confidence where the public feels that a proposed program or project has not
adequately considered or addressed privacy concerns;
- Underestimating privacy requirements
such that systems need to be redesigned or retrofitted late in the development
stage at considerable expense.
To minimize risk, potential causes
of concern should be addressed as early in the design process as possible,
with reference to the Enterprise Information and Information Technology Architecture
Privacy Design Principles (EIA Privacy Design Principles). Where risk cannot be mitigated through technical
or policy instruments, such as effective system design or the use of privacy-enhancing
technologies, sponsoring ministries should provide decision-makers with a
full assessment of the risks and a strategy for responding to pubic concerns.
To successfully identify design or program
features in a given initiative that may contribute to a lack of public confidence,
and to appropriately anticipate public reaction to an initiative, the clients
perspective on risk must be considered, as they will generally bear the consequences
of privacy breaches.
Proposals may be subject to public
criticism even where the requirements of FIPPA or MFIPPA have been met. Broader
fair information principles, and the public expectations that flow from those
principles and other relevant legislation, such as the federal government's
Personal Information Protection and Electronic Documents Act (federal Act ) must also be considered.
The federal Act regulates the collection,
use, and disclosure of personal information in the private sector, based on
the CSA Standard. Representatives from the public sector, industries (including transportation,
telecommunications, information technology, insurance, health, and banking),
consumer advocacy groups, unions and other general-interest groups developed
the CSA Standard in the 1990s. It represents a consensus among all stakeholders, and
is based on the Organisation for Economic Co-operation and Development's Guidelines
Governing the Protection of Privacy and Transborder Flows of Personal Data (OECD
Guidelines). It addresses two broad concerns: the way in
which organizations collect, use, disclose and protect personal information;
and the right of individuals to have access to personal information about themselves
and to have the information corrected if necessary.
The federal Act responds to a number
of pressures, including growing public concern about privacy, the need to provide
the right framework to stimulate electronic commerce, and addressing the European
Union Data Protection Directive (EU Directive). The EU Directive requires member states to block transfers of
information to non-member states that do not offer "adequate" protection.
The scope of the federal Act is
extensive, and it is likely to form the basis of public expectations of privacy. Significantly, the
federal Act enshrines the notion that individuals
should have the opportunity to consent to the collection, use, or disclosure
of their personal information. In developing project proposals, ministries should
be aware that the federal Act is likely to stimulate higher public expectations
for consent-based privacy protection.
RISK
MANAGEMENT: TOOLS FOR PROTECTING PRIVACY
Experience over time and across jurisdictions
has shown that the most effective way to protect personal information is to
use a combination of tools and strategies, which include the implementation
of fair information practices, privacy-enhancing technologies, privacy impact
assessments, standards, and public education.
Fair
Information Practices
In 1980, the OECD developed privacy
guidelines on the protection of privacy and transborder flows of personal
information. Canada signed the OECD Guidelines
in 1984. While there have been numerous developments in the protection of personal
information since that time, the principles enshrined in the OECD Guidelines continue
to serve as the foundation for most efforts to protect personal information
around the world.
The OECD Guidelines are based on
fair information practices (FIPs). FIPs are basic principles for the collection,
use, disclosure, retention and disposal of personal information.
While there
are some variations, fair information principles normally include the following:
- ensuring public awareness and
transparency (openness) of information policies and practices
- establishing necessity and relevance
of the information collected
- building in finality (establishing
the uses of the information in advance and eventually destroying it)
- identifying the person who has
responsibility for protecting personal information within an organization
- getting informed consent from
the individual
- maintaining accuracy and completeness
of records
The international influence of
the OECD Guidelines, and of FIPs more generally, has been
significant, and is apparent in Ontario's FIPPA and MFIPPA legislation.
Decision-makers must recognize
that, while changing service delivery mechanisms and the extensive use of
new technologies may alter programs and information systems, FIPS continue
to be relevant as a minimum standard for the protection of personal information.
Program or project sponsors must ensure that adequate steps have been taken
to protect personal information through adherence to such practices.
Privacy-Enhancing
Technologies
In the last decade, a number of technologies
have been specifically developed to be privacy-enhancing technologies (PETs).
Such tools assist in protecting privacy, and often do so by providing genuine,
untraceable anonymity.
PETs such
as encryption, digital signatures, and anonymous electronic cash and service
delivery systems, may protect personal information from unauthorized collection,
use and disclosure. The effective incorporation of such technologies into basic
program or system design can often alleviate pressures on privacy that result
from program goals or efficiency requirements with little or no increase in
cost.
A good example of practical use of
PETs is pseudo-identification, which can authenticate
individuals for the receipt of government services. It does so by allowing the
authentication of people's eligibility rather than their identity. A pseudonymous
record or transaction is one that cannot, in the normal course of events, be
associated with a particular individual. Hence a transaction is pseudonymous
in relation to a particular party if the transaction data contains no direct
identifier for that party, and can only be related to them in the event that
a very specific piece of additional data is associated with it. To be effective,
pseudonymous mechanisms must involve legal, organizational and technical protections,
such that the link between a transaction and an identifiable individual can
be made only under appropriate circumstances.
Pseudonymity, and other PETs, can provide innovative ways of addressing fundamental issues in
system design while protecting personal information. Used to their full potential,
such technologies can provide more secure identification to reduce fraud; more
secure networking to reduce losses from theft; and more secure payment systems
which will dispense with the administrative costs of cash while permitting high
levels of user anonymity and privacy protection. Applied in association with
FIPS, PETs make it clear that cost savings and privacy
protection need not be opposing values.
Privacy
Impact Assessments
Privacy impact assessments help to
determine whether new technologies, information systems, or proposed programs
or policies meet basic privacy requirements. They provide a framework for identifying
and reviewing privacy issues as they arise within particular contexts.
Standards
Sector or activity-specific privacy
standards, such as the Electronic Service Delivery Privacy Standard, that reflect the kinds
of fair information principles embodied in the CSA Standard, can provide a vehicle
for clearly articulating privacy expectations in a given context, and may be
particularly useful where partnerships are involved.
Public and/or Key Stakeholder
Consultation
It may be appropriate to consult
on major initiatives proposing new collections, uses, or disclosures of personal
information, or on significant overhauls of existing programs. 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.
Focused, strategically-timed public
discussions can assist program or system designers in anticipating broader public
reactions to proposals that may have implications for the protection of personal
information. Conducted early in the process, such consultations may help to
eliminate options which meet with significant resistance.
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 some sense of the environment into which the proposal will
be received, and may be a good indicator of public expectations.
Common
Sources of Risk
Elements of program design, system
characteristics, and/or the choice or design of delivery channels may contribute
to risks to privacy and violations of fair information practices. Some of the
more common sources of risk are summarized below.
It is important to note that the
PIA is not designed to dictate specific courses of action, or to curtail the
sponsoring ministry's range of options in terms of program design or technology
options. The function of the PIA is simply to ensure that privacy risks associated
with a given proposal are properly identified and addressed wherever possible,
and that decision-makers have been informed of these risks and the options available
for mitigating them.
Program characteristics
Risks to privacy may arise as a result
of any of a number of program characteristics, including:
Data profiling/data linkage:
combining unrelated personal information obtained from a variety of sources
to create new information about individuals. Data linkage may be facilitated
through the storing of personal information in centralized databases or
by linking unrelated databases.
Transaction monitoring:
tracking an individual's transactions with one or more programs. This
usually results in the creation of new personal information describing
an individual's overall experience with one or more programs.
Identification of individuals:
ESD generally requires identification of individuals
and authentication of that identity as a way of managing security risks.
Surveillance risks exist where the use of common identifiers or identification
systems facilitates data sharing, profiling, or transaction monitoring.
Physical observation
of individuals: tracking the movement or location of individuals
through the use of vehicle transponders, satellite locators, cameras,
or mechanisms for recording individual use of kiosks.
Publishing or re-distributing
public databases containing personal information: this might include
publishing assessment rolls on the Internet or on compact disks, or publishing
court records on the Internet. Electronic publishing frequently eliminates
practical limits on the misuse of information, as it can be easily manipulated
and used for purposes entirely unrelated to its intended use in manual
form.
System
Characteristics and Technical Architecture
The degree to which ESD programs preserve or erode privacy is generally determined by the architecture
or design of the systems that support them, and by the technologies that drive
those systems. Business and technology managers should review technical architecture
to determine whether and how certain inherent functional characteristics may
pose a risk to privacy. Common examples of such characteristics are summarized
below.
Common
(Network) Directory Services
Most systems seek to maximize ease of
access for many users from any number of locations. A central list is maintained
of individuals authorized to access the system and their privileges. Most central
listing activity is automated, and is designed to collect similar listings from
linked or related systems that make it possible to find someone with an ID, electronic
address, or privileges within the connected systems. This function is known as
common directory services.
Where common directory services list
personal information about individuals as customers of government programs,
privacy issues may arise. This is particularly relevant in self-service electronic
program delivery models, or where a directory is shared or aggregated between
programs such that data profiling or data matching may be facilitated.
Alternative
Service Delivery
Alternative service delivery (ASD) may raise
a number of issues with regard to the protection of personal information. In assessing
ASD arrangements, it is important to keep key differences between public and private
sector service delivery in mind:
- Government has demand powers,
which the private sector does not generally have;
- In most cases, there is the
possibility of choice in consumer dealings with the private sector;
- The data being collected through
these arrangements is, in many cases, more sensitive than data that would
normally be collected by the private sector.
Depending on the sensitivity of the
data, relatively straightforward out-sourcing of IT services or program intake
functions where personal information is collected and processed on behalf of a
public body and subject to FIPPA may not raise significant privacy issues.
In many cases, however, ASD arrangements
are relatively complex and so require more careful scrutiny. Examples of such
arrangements would include:
- Merging previously isolated transaction
systems into a common governmental window,
- Localizing data collection activities
through a common private sector window for previously isolated program data
collections systems, which may also include concurrent data collection for
private sector transactions,
- Materially changing the status
of personally identifiable information, organizational accountability, and
oversight of the business by accepted mechanisms such as internal auditors,
a Provincial Auditor, the IPC, or an Ombudsman.
Regardless of the specific details of
the ASD arrangement, it is important that personal information continues to be
protected when it passes into the hands of contractors and sub-contractors.
Service
Monitoring
There is growing pressure for program
areas to monitor service delivery in order to measure customer satisfaction and
allocate resources. Careful system design can allow for monitoring with little
or no privacy invasion. For example, Internet browser cookies and transaction
logging systems can be designed and used to capture generic, non-identifiable
or anonymized data which provides an adequate basis for service management without
significant privacy risks. In such cases, a PIA will not generally be required.
Where service monitoring does involve
the use of personally-identifiable data, however, a privacy impact assessment
will likely be necessary.
Delivery
Channel Management
The shift toward new delivery channels
can pose distinct challenges for security and privacy. Moving from systems based
on personal interaction at a counter, or signed paper mail, to computer or kiosk-based
transactions, automated voice response, call centres, or remote access systems,
raises new issues with regard to client identification and authentication, and
to the provision of notice or consent. Call centres, for example, may access program
data for a range of programs, making data profiling both easier to perform and
more difficult to detect. Sponsoring ministries may wish to preserve a range of
access channels for service delivery, allowing customers to choose their preferred
level of personal comfort, risk and convenience.
Wherever changes in delivery channels
result in changes to how personal information is collected, used, or disclosed,
a PIA will be required.
Data
Warehousing and Data Marts
Data warehouses and data marts may,
over time, provide a venue for limitless data matching and creation of new forms
of personal information inconsistent with client expectations. By their nature,
data warehouses and marts challenge or violate the basic privacy principles relating
to limiting collection, disclosure, use, and obtaining consent for new uses. Thus,
they entail a high degree of risk from a privacy perspective, and may well meet
with public resistance. A PIA is required wherever data warehousing and/or data
marts are being proposed.
Risks must be carefully measured
against the expected benefits to be derived from the data warehouse. In proceeding
with the PIA, sponsoring ministries should pay particular attention to any proposal
to integrate personal data from separately legislated program databases or private
sector databases.
The risks associated with data warehousing
and data marts may be reduced in a number of ways, including:
- Using artificial intelligence
(AI) products to research trends within a single program database as an alternative
to data warehousing;
- Anonymizing the data, thereby
limiting potential threats to identification and privacy loss to a small number
of individuals managing the data stripping or ID conversions;
- Soliciting voluntary individual
consent for inclusion in the data warehouse. This approach may limit the size
and cost of the data warehouse while providing sufficient strategic information;
- Providing value-added information
services to interested parties instead of allowing direct access to identifiable
data;
- Ensuring the custodianship and
control of identifiable data remains subject to FIPPA, and that such data
are subject to frequent formal independent audits for compliance with project
privacy and security standards.
Where such strategies are employed,
the scope of the PIA will be significantly reduced.

[Continue
to Part Three]
[Back
to Part One]
[Back to Table of Contents]
|