NIST SP 800-122 日本語訳

Special Publication 800-122

Erika McCallister Tim Grance Karen Scarfone

NIST Special Publication 800-122

Recommendations of the National Institute of Standards and Technology

Erika McCallister Tim Grance Karen Scarfone

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

April 2010

U.S. Department of Commerce

Gary Locke, Secretary

National Institute of Standards and Technology

Dr. Patrick D. Gallagher, Director

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation‘s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL‘s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL‘s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-122 Natl. Inst. Stand. Technol. Spec. Publ. 800-122, 59 pages (Apr. 2010)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

The authors, Erika McCallister, Tim Grance, and Karen Scarfone of the National Institute of Standards and Technology (NIST), wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content. Of particular note are the efforts of Joseph Nusbaum of Innovative Analytics & Training, Deanna DiCarlantonio of CUNA Mutual Group, and Michael L. Shapiro and Daniel I. Steinberg of Booz Allen Hamilton, who contributed significant portions to previous versions of the document. The authors would also like to acknowledge Ron Ross, Kelley Dempsey, and Arnold Johnson of NIST; Michael Gerdes, Beth Mallory, and Victoria Thompson of Booz Allen Hamilton; Brendan Van Alsenoy of ICRI, K.U.Leuven; David Plocher and John de Ferrari of the Government Accountability Office; Toby Levin of the Department of Homeland Security; Idris Adjerid of Carnegie Mellon University; The Federal Committee on Statistical Methodology: Confidentiality and Data Access Committee; The Privacy Best Practices Subcommittee of the Chief Information Officers Council; and Julie McEwen and Aaron Powell of The MITRE Corporation, for their keen and insightful assistance during the development of the document.

Executive Summary

The escalation of security breaches involving personally identifiable information (PII) has contributed to the loss of millions of records over the past few years.¹ Breaches involving PII are hazardous to both individuals and organizations. Individual harms² may include identity theft, embarrassment, or blackmail. Organizational harms may include a loss of public trust, legal liability, or remediation costs. To appropriately protect the confidentiality of PII, organizations should use a risk-based approach; as McGeorge Bundy³ once stated, “If we guard our toothbrushes and diamonds with equal zeal, we will lose fewer toothbrushes and more diamonds.” This document provides guidelines for a risk-based approach to protecting the confidentiality⁴ of PII. The recommendations in this document are intended primarily for U.S. Federal government agencies and those who conduct business on behalf of the agencies,⁵ but other organizations may find portions of the publication useful. Each organization may be subject to a different combination of laws, regulations, and other mandates related to protecting PII, so an organization‘s legal counsel and privacy officer should be consulted to determine the current obligations for PII protection. For example, the Office of Management and Budget (OMB) has issued several memoranda with requirements for how Federal agencies must handle and protect PII. To effectively protect PII, organizations should implement the following recommendations.

Organizations should identify all PII residing in their environment.

An organization cannot properly protect PII it does not know about. This document uses a broad definition of PII to identify as many potential sources of PII as possible (e.g., databases, shared network drives, backup tapes, contractor sites). PII is “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.” 6 Examples of PII include, but are not limited to:

Organizations should minimize the use, collection, and retention of PII to what is strictly necessary to accomplish their business purpose and mission.

The likelihood of harm caused by a breach involving PII is greatly reduced if an organization minimizes the amount of PII it uses, collects, and stores. For example, an organization should only request PII in a new form if the PII is absolutely necessary. Also, an organization should regularly review its holdings of previously collected PII to determine whether the PII is still relevant and necessary for meeting the organization‘s business purpose and mission. For example, organizations could have an annual PII purging awareness day.⁷

OMB M-07-168 specifically requires agencies to:

Organizations should categorize their PII by the PII confidentiality impact level.

All PII is not created equal. PII should be evaluated to determine its PII confidentiality impact level, which is different from the Federal Information Processing Standard (FIPS) Publication 1999 confidentiality impact level, so that appropriate safeguards can be applied to the PII. The PII confidentiality impact level—low, moderate, or high—indicates the potential harm that could result to the subject individuals and/or the organization if PII were inappropriately accessed, used, or disclosed. This document provides a list of factors an organization should consider when determining the PII confidentiality impact level. Each organization should decide which factors it will use for determining impact levels and then create and implement the appropriate policy, procedures, and controls. The following are examples of factors:

Organizations should apply the appropriate safeguards for PII based on the PII confidentiality impact level.

Not all PII should be protected in the same way. Organizations should apply appropriate safeguards to protect the confidentiality of PII based on the PII confidentiality impact level. Some PII does not need to have its confidentiality protected, such as information that the organization has permission or authority to release publicly (e.g., an organization‘s public phone directory). NIST recommends using operational safeguards, privacy-specific safeguards, and security controls,¹¹ such as:

Organizations should develop an incident response plan to handle breaches involving PII.

Breaches involving PII are hazardous to both individuals and organizations. Harm to individuals and organizations can be contained and minimized through the development of effective incident response plans for breaches involving PII. Organizations should develop plans¹² that include elements such as determining when and how individuals should be notified, how a breach should be reported, and whether to provide remedial services, such as credit monitoring, to affected individuals.

Organizations should encourage close coordination among their chief privacy officers, senior agency officials for privacy, chief information officers, chief information security officers, and legal counsel¹³ when addressing issues related to PII.

Protecting the confidentiality of PII requires knowledge of information systems, information security, privacy, and legal requirements. Decisions regarding the applicability of a particular law, regulation, or other mandate should be made in consultation with an organization‘s legal counsel and privacy officer because relevant laws, regulations, and other mandates are often complex and change over time. Additionally, new policies often require the implementation of technical security controls to enforce the policies. Close coordination of the relevant experts helps to prevent incidents that could result in the compromise and misuse of PII by ensuring proper interpretation and implementation of requirements.

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies, also referred to as organizations in the guide. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

The purpose of this document is to assist Federal agencies in protecting the confidentiality of personally identifiable information (PII) in information systems. The document explains the importance of protecting the confidentiality of PII in the context of information security and explains its relationship to privacy using the Fair Information Practices, which are the principles underlying most privacy laws and privacy best practices. PII should be protected from inappropriate access, use, and disclosure. This document provides practical, context-based guidance for identifying PII and determining what level of protection is appropriate for each instance of PII. The document also suggests safeguards that may offer appropriate levels of protection for PII and provides recommendations for developing response plans for incidents involving PII. Organizations are encouraged to tailor the recommendations to meet their specific requirements.

The primary audience for this document is the individuals who apply policies and procedures for protecting the confidentiality of PII on Federal information systems, as well as technical and non-technical personnel involved with implementing system-level changes concerning PII protection methods. Individuals in many roles should find this document useful, including chief privacy officers and other privacy officers, privacy advocates, privacy support staff, public affairs staff, compliance officers, human resources staff, system administrators, chief information security officers, information system security officers, information security support staff, computer security incident response teams, and chief information officers.

The remainder of this document is organized into the following sections:

The following appendices are also included for additional information:

One of the most widely used terms to describe personal information is PII. Examples of PII range from an individual‘s name or email address to an individual‘s financial and medical records or criminal history. Unauthorized access, use, or disclosure of PII can seriously harm both individuals, by contributing to identity theft, blackmail, or embarrassment, and the organization, by reducing public trust in the organization or creating legal liability. This section explains how to identify and locate PII¹⁴ maintained within an organization‘s environment and/or under its control, and it provides an introduction to the Fair Information Practices. Sections 3 and 4 discuss factors for assigning PII impact levels and selecting safeguards, respectively. Section 5 discusses incident response for breaches involving PII.

PII is “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.”¹⁵

To distinguish an individual¹⁶ is to identify an individual. Some examples of information that could identify an individual include, but are not limited to, name, passport number, social security number, or biometric data.¹⁷ In contrast, a list containing only credit scores without any additional information concerning the individuals to whom they relate does not provide sufficient information to distinguish a specific individual.¹⁸

To trace an individual is to process sufficient information to make a determination about a specific aspect of an individual‘s activities or status. For example, an audit log containing records of user actions could be used to trace an individual‘s activities.

Linked information is information about or related to an individual that is logically associated with other information about the individual. In contrast, linkable information is information about or related to an individual for which there is a possibility of logical association with other information about the individual. For example, if two databases contain different PII elements, then someone with access to both databases may be able to link the information from the two databases and identify individuals, as well as access additional information about or relating to the individuals. If the secondary information source is present on the same system or a closely-related system and does not have security controls that effectively segregate the information sources, then the data is considered linked. If the secondary information source is maintained more remotely, such as in an unrelated system within the organization, available in public records, or otherwise readily obtainable (e.g., internet search engine), then the data is considered linkable.

Organizations are required to identify all PII residing within their organization or under the control of their organization through a third party (e.g., a system being developed and tested by a contractor). Organizations should use a variety of methods to identify PII. Privacy threshold analyses (PTAs), also referred to as initial privacy assessments (IPAs), are often used to identify PII.¹⁹ Some organizations require a PTA to be completed before the development or acquisition of a new information system and when a substantial change is made to an existing system. PTAs are used to determine if a system contains PII, whether a Privacy Impact Assessment (PIA) is required, whether a System of Records Notice (SORN) is required, and if any other privacy requirements apply to the information system. PTAs are usually submitted to an organization‘s privacy office for review and approval. PTAs are comprised of simple questionnaires that are completed by the system owner in collaboration with the data owner. PTAs are useful in initiating the communication and collaboration for each system between the privacy officer, the information security officer, and the information officer. Other examples of methods to identify PII include reviewing system documentation, conducting interviews, conducting data calls, using data loss prevention technologies (e.g., automated PII network monitoring tools), or checking with system and data owners. Organizations should also ensure that retired hardware no longer contains PII and that proper sanitization techniques are applied.²⁰

The following list contains examples of information that may be considered PII.

The protection of PII and the overall privacy of information are concerns both for individuals whose personal information is at stake and for organizations that may be liable or have their reputations damaged should such PII be inappropriately accessed, used, or disclosed. Treatment of PII is distinct from other types of data because it needs to be not only protected, but also collected, maintained, and disseminated in accordance with Federal law.²² The Privacy Act, as well as other U.S. privacy laws, is based on the widely-recognized Fair Information Practices, also called Privacy Principles. The Organisation for Economic Co-operation and Development (OECD)²³ Privacy Guidelines are the most widely-accepted privacy principles, and they were endorsed by the Department of Commerce in 1981.24 The OECD Fair Information Practices are also the foundation of privacy laws and related policies in many other countries, (e.g., Sweden, Australia, Belgium).²⁵ In 2004, the Chief Information Officers (CIO) Council issued the Security and Privacy Profile for the Federal Enterprise Architecture²⁶ that links privacy protection with a set of acceptable privacy principles corresponding to the OECD‘s Fair Information Practices.

The OECD identified the following Fair Information Practices.

Privacy is much broader than just protecting the confidentiality of PII. To establish a comprehensive privacy program that addresses the range of privacy issues that organizations may face, organizations should take steps to establish policies and procedures that address all of the Fair Information Practices. For example, while providing individuals with notice of new information collections and how their personal information will be used and protected is central to providing individuals with privacy protections and transparency, it may not have a significant impact on protecting the confidentiality of their personal information. On the other hand, the Fair Information Practices related to establishing security safeguards, purpose specification, use limitation, collection limitation, and accountability are directly relevant to the protection of the confidentiality of PII. As a result, these principles are highlighted throughout this document as appropriate.

For more information on the Fair Information Practices, see Appendix D.

This publication focuses on protecting PII from losses of confidentiality. The security objective of confidentiality is defined by law as “preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.”²⁷

The security objectives of integrity and availability are equally important for PII, and organizations should use the NIST Risk Management Framework²⁸ to determine the appropriate integrity and availability impact levels. Organizations may also need to consider PII-specific enhancements to the integrity or availability impact levels. Accuracy is a required Fair Information Practice for most PII, and the security objective of integrity helps to ensure accuracy. Integrity is also important for preventing harm to the individual and the organization. For example, unauthorized alterations of medical records could endanger individuals‘ lives, and medical mistakes based on inaccurate information can result in liability to the organization and harm to its reputation.

The confidentiality of PII should be protected based on its impact level. This section outlines factors for determining the PII confidentiality impact level for a particular instance of PII, which is distinct from the confidentiality impact level described in Federal Information Processing Standards (FIPS) Publication 199, Standards for Security Categorization of Federal Information and Information Systems.²⁹ The PII confidentiality impact level takes into account additional PII considerations and should be used to determine if additional protections should be implemented. The PII confidentiality impact level—low, moderate, or high—indicates the potential harm that could result to the subject individuals and/or the organization if PII were inappropriately accessed, used, or disclosed. Once the PII confidentiality impact level is selected, it should be used to supplement the provisional confidentiality impact level, which is determined from information and system categorization processes outlined in FIPS 199 and NIST Special Publication (SP) 800-60, Volumes 1 and 2: Guide for Mapping Types of Information and Information Systems to Security Categories.³⁰ Supplementation of the provisional confidentiality impact level should be included in the documentation of the security categorization process.

Some PII does not need to have its confidentiality protected, such as information that the organization has permission or authority to release publicly (e.g., an organization publishing a phone directory of employees‘ names and work phone numbers so that members of the public can contact them directly). In this case, the PII confidentiality impact level would be not applicable and would not be used to supplement a system‘s provisional confidentiality impact level. PII that does not require confidentiality protection may still require other security controls to protect the integrity and the availability of the information, and the organization should provide appropriate security controls based on the assigned FIPS 199 impact levels.

The harm caused from a breach of confidentiality should be considered when attempting to determine which PII confidentiality impact level corresponds to a specific set of PII. For the purposes of this document, harm means any adverse effects that would be experienced by an individual whose PII was the subject of a loss of confidentiality, as well as any adverse effects experienced by the organization that maintains the PII. Harm to an individual includes any negative or unwanted effects (i.e., that may be socially, physically, or financially damaging). Examples of types of harm to individuals include, but are not limited to, the potential for blackmail, identity theft, physical harm, discrimination, or emotional distress. Organizations may also experience harm as a result of a loss of confidentiality of PII maintained by the organization, including but not limited to administrative burden, financial losses, loss of public reputation and public confidence, and legal liability.

The following describe the three impact levels—low, moderate, and high—defined in FIPS 199, which are based on the potential impact of a security breach involving a particular system:³¹

“The potential impact is LOW if the loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. A limited adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.

The potential impact is MODERATE if the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.

The potential impact is HIGH if the loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. A severe or catastrophic adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries.”

Harm to individuals as described in these impact levels is easier to understand with examples. A breach of the confidentiality of PII at the low impact level would not cause harm greater than inconvenience, such as changing a telephone number. The types of harm that could be caused by a breach involving PII at the moderate impact level include financial loss due to identity theft or denial of benefits, public humiliation, discrimination, and the potential for blackmail. Harm at the high impact level involves serious physical, social, or financial harm, resulting in potential loss of life, loss of livelihood, or inappropriate physical detention.

Determining the impact from a loss of confidentiality of PII should take into account relevant factors. Several important factors that organizations should consider are described below. It is important to note that relevant factors should be considered together; one factor by itself might indicate a low impact level, but another factor might indicate a high impact level, and thus override the first factor. Also, the impact levels suggested for these factors are for illustrative purposes; each instance of PII is different, and each organization has a unique set of requirements and a different mission. Therefore, organizations should determine which factors, including organization-specific factors, they should use for determining PII confidentiality impact levels and should create and implement policy and procedures that support these determinations.

Organizations should evaluate how easily PII can be used to identify specific individuals. For example, PII data composed of individuals‘ names, fingerprints, or SSNs uniquely and directly identify individuals, whereas PII data composed of individuals‘ ZIP codes and dates of birth can indirectly identify individuals or can significantly narrow large datasets.³³ However, data composed of only individuals‘ area codes and gender usually would not provide for direct or indirect identification of an individual depending upon the context and sample size.³⁴ Thus, PII that is uniquely and directly identifiable may warrant a higher impact level than PII that is not directly identifiable by itself.

Organizations may also choose to consider how many individuals are identified in the information (e.g., number of records). Breaches of 25 records and 25 million records may have different impacts, not only in terms of the collective harm to individuals, but also in terms of harm to the organization‘s reputation and the cost to the organization in addressing the breach. For this reason, organizations may choose to set a higher impact level for particularly large PII datasets than would otherwise be set. However, organizations should not set a lower impact level for a PII dataset simply because it contains a small number of records.

Organizations should evaluate the sensitivity of each individual PII data field, as well as the sensitivity of the PII data fields together.³⁵ For example, an individual’s SSN, medical history, or financial account information is generally considered more sensitive than an individual’s phone number or ZIP code. Organizations often require the PII confidentiality impact level to be set at least to moderate if a certain data field, such as SSN, is present. Organizations may also consider certain combinations of PII data fields to be more sensitive, such as name and credit card number, than each data field would be considered without the existence of the others. Data fields may also be considered more sensitive based on potential harm when used in contexts other than their intended use. For example, basic background information, such as place of birth or parent’s middle name, is often used as an authentication factor for password recovery at many web sites.

The context of use factor is related to the Fair Information Practices of Purpose Specification and Use Limitation. Context of use is defined as the purpose for which PII is collected, stored, used, processed, disclosed, or disseminated. Examples of context include, but are not limited to, statistical analysis, eligibility for benefits, administration of benefits, research, tax administration, or law enforcement. Organizations should assess the context of use because it is important in understanding how the disclosure of data elements can potentially harm individuals and the organization. Organizations should also consider whether disclosure of the mere fact that PII is being collected or used could cause harm to the organization or individual. For example, law enforcement investigations could be compromised if the mere fact that information is being collected about a particular individual is disclosed.

The context of use factor may cause the same types of PII to be assigned different PII confidentiality impact levels in different instances. For example, suppose that an organization has three lists that contain the same PII data fields (e.g., name, address, phone number). The first list is people who subscribe to a general-interest newsletter produced by the organization. The second list is people who have filed for retirement benefits, and the third list is individuals who work undercover in law enforcement. The potential impacts to the affected individuals and to the organization are significantly different for each of the three lists. Based on context of use only, the three lists are likely to merit impact levels of low, moderate, and high, respectively.

An organization that is subject to any obligations to protect PII should consider such obligations when determining the PII confidentiality impact level. Many organizations are subject to laws, regulations, or other mandates³⁶ governing the obligation to protect personal information,³⁷ such as the Privacy Act of 1974, OMB memoranda, and the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Additionally, some Federal agencies, such as the Census Bureau and the Internal Revenue Service (IRS), are subject to additional specific legal obligations to protect certain types of PII.³⁸ Some organizations are also subject to specific legal requirements based on their role. For example, organizations acting as financial institutions by engaging in financial activities are subject to the Gramm-Leach-Bliley Act (GLBA).³⁹ Also, some agencies that collect PII for statistical purposes are subject to the strict confidentiality requirements of the Confidential Information Protection and Statistical Efficiency Act (CIPSEA).⁴⁰ Violations of these laws can result in civil or criminal penalties. Organizations may also be obliged to protect PII by their own policies, standards, or management directives.

Decisions regarding the applicability of a particular law, regulation, or other mandate should be made in consultation with an organization‘s legal counsel and privacy officer because relevant laws, regulations, and other mandates are often complex and change over time.

Organizations may choose to take into consideration the nature of authorized access to PII. When PII is accessed more often or by more people and systems, there are more opportunities for the confidentiality of the PII to be compromised. Another aspect of the nature of access to PII is whether PII is being stored on or accessed from teleworkers‘ devices or other systems and other systems, such as web applications, outside the direct control of the organization.⁴¹ These considerations could cause an organization to assign a higher impact level to widely-accessed PII than would otherwise be assigned to help mitigate the increased risk caused by the nature of the access.

Additionally, organizations may choose to consider whether PII that is stored or regularly transported off-site by employees should be assigned a higher PII confidentiality impact level. For example, surveyors, researchers, and other field employees often need to store PII on laptops or removable media as part of their jobs. Another example is the offsite storage of backup and archive data. PII located offsite could be more vulnerable to unauthorized access or disclosure because it is more likely to be lost or stolen than PII stored within the physical boundaries of the organization.

The following examples illustrate how an organization might assign PII confidentiality impact levels to specific instances of PII. The examples are intended to help organizations better understand the process of considering the various impact level factors, and they are not a substitute for organizations analyzing their own situations. Certain circumstances within any organization or specific system, such as the context of use or obligation to protect, may cause different outcomes.

Obligation to protect is a particularly important factor that should be determined early in the categorization process. Since obligation to protect confidentiality should always be made in consultation with an organization‘s legal counsel and privacy officer, it is not addressed in the following examples.

A Federal government agency maintains an electronic roster of its computer incident response team members. In the event that an IT staff member detects any kind of security breach, standard practice requires that the staff member contact the appropriate people listed on the roster. Because this team may need to coordinate closely in the event of an incident, the contact information includes names, professional titles, office and work cell phone numbers, and work email addresses. The agency makes the same types of contact information available to the public for all of its employees on its main web site.

Identifiability: The information directly identifies a small number of individuals using names, phone numbers, and email addresses.

Quantity of PII: The information directly identifies fewer than twenty individuals.

Data field sensitivity: Although the roster is intended to be made available only to the team members, the individuals‘ information included in the roster is already available to the public on the agency‘s web site.

Context of use: The release of the individuals‘ names and contact information would not likely cause harm to the individuals, and disclosure of the fact that the agency has collected or used this information is also unlikely to cause harm.

Access to and location of PII: The information is accessed by IT staff members who detect security breaches, as well as the team members themselves. The PII needs to be readily available to teleworkers and to on-call IT staff members so that incident responses can be initiated quickly.

Taking into account these factors, the agency determines that unauthorized access to the roster would likely cause little or no harm, and it chooses to assign the PII confidentiality impact level of low.⁴²

An organization maintains a web use audit log for an intranet web site accessed by employees. The web use audit log contains the following:

Identifiability: By itself, the log does not contain any directly identifiable data. However, the organization has a closely-related system with a log that contains domain login information records, which include user IDs and corresponding IP addresses. Administrators who have access to both systems and their logs could correlate information between the logs and identify individuals. Potentially, information could be stored about the actions of most of the organization‘s users involving web access to intranet resources. The organization has a small number of administrators who have access to both systems and both logs.

Quantity of PII: The log contains a large number of records containing linked PII.

Data field sensitivity: The information on which internal web pages and topics were accessed could potentially cause some embarrassment if the pages involved certain human resources-related subjects, such as a user searching for information on substance abuse programs. However, since the logging is limited to use of intranet-housed information, the amount of potentially embarrassing information is minimal.

Context of use: Creation of the logs is known to all staff members through the organization‘s acceptable use policies. The release of the information would be unlikely to cause harm, other than potential embarrassment for a small number of users.

Access to and location of PII: The log is accessed by a small number of system administrators when troubleshooting operational problems and also occasionally by a small number of incident response personnel when investigating incidents. All access to the log occurs only from the organization‘s own systems.

Taking into account these factors, the organization determines that a breach of the log‘s confidentiality would likely cause little or no harm, and it chooses to assign the PII confidentiality impact level of low.

A database contains web form submissions by individuals claiming possible fraud, waste, or abuse of organizational resources and authority. Some of the submissions include serious allegations, such as accusing individuals of accepting bribes or not enforcing safety regulations. The submission of contact information is not prohibited, and individuals often enter their personal information in the form‘s narrative text field. The web site is hosted by a server that logs IP address and referring web site information.

Identifiability: By default, the database does not request PII, but a significant percentage of users choose to provide PII. The web log contains IP addresses, which could be identifiable. However, the log information is not linked or readily linkable with the database or other sources to identify specific individuals.

Quantity of PII: A recent estimate indicated that the database has approximately 50 records with PII out of nearly 1000 total records.

Data field sensitivity: The database‘s narrative text field contains user-supplied text and frequently includes information such as name, mailing address, email address, and phone numbers.

Context of use: Because of the nature of the submissions (i.e., reporting claims of fraud, waste, or abuse), the disclosure of individuals‘ identities would likely cause some of the individuals making the claims to fear retribution by management and peers. Additionally, it could negatively impact individuals about whom accusations are made. The ensuing harm could include blackmail, severe emotional distress, loss of employment, and physical harm. A breach would also undermine employee and public trust in the organization.

Access to and location of PII: The database is only accessed by a few people who investigate fraud, waste, and abuse claims. All access to the database occurs only from the organization‘s internal systems.

Taking into account these factors, the organization determines that a breach of the database‘s confidentiality would likely cause catastrophic harm to some of the individuals and chooses to assign the PII confidentiality impact level of high.

PII should be protected through a combination of measures, including operational safeguards, privacy-specific safeguards, and security controls. Many of these measures also correspond to several of the Fair Information Practices. Organizations should use a risk-based approach for protecting the confidentiality of PII. The PII safeguards provided in this section are complementary to other safeguards for data and may be used as one part of an organization‘s comprehensive approach to protecting the confidentiality of PII and implementing the Fair Information Practices.

This section describes two types of operational safeguards for PII protection: policy and procedure creation; and education, training, and awareness. Organizations can choose whether these policy, education, and awareness activities are combined with related security controls (e.g., AT-1, AT-2) or are separated as part of a privacy program.

As agencies work to establish a variety of safeguards to protect the confidentiality of PII, they must also ensure that mechanisms are in place to make certain that individuals are held accountable for implementing these controls adequately and that the controls are functioning as intended. Accountability is also an important Fair Information Practice. In this context, agencies may already have some pre-established processes for providing oversight and accountability for the implementation of key controls, such as those related to information system assessment and authorization, Privacy Impact Assessments, and Privacy Act compliance. However, some additional oversight mechanisms or amendments to pre-existing procedures could be necessary to ensure that all measures for protecting PII are being considered and properly implemented.

Organizations should develop comprehensive policies and procedures for handling PII at the organization level, the program or component level, and where appropriate, at the system level.⁴³ Some types of policies include foundational privacy principles, privacy rules of behavior, policies that implement laws and other mandates, and system-level policies. The foundational privacy principles reflect the organization‘s privacy objectives. Foundational privacy principles may also be used as a guide against which to develop additional policies and procedures. Privacy rules of behavior policies provide guidance on the proper handling of PII, as well as the consequences for failure to comply with the policy. Some policies provide guidance on implementing laws and OMB guidance in an organization‘s environment based upon the organization‘s authorized business purposes and mission. Organizations should consider developing privacy policies and associated procedures for the following topics:

If the organization permits access to or transfer of PII through interconnected systems external to the organization or shares PII through other means, the organization should implement the appropriate documented agreements for roles and responsibilities, restrictions on further sharing of the information, requirements for notification to each party in the case of a breach, minimum security controls, and other relevant factors. Also, Interconnection Security Agreements (ISA) should be used for technical requirements as necessary.⁴⁴ These agreements ensure that the partner organizations abide by rules for handling, disclosing, sharing, transmitting, retaining, and using the organization‘s PII.

PII maintained by the organization should also be reflected in the organization‘s incident response policies and procedures. A well-defined incident response capability helps the organization detect incidents rapidly, minimize loss and destruction, identify weaknesses, and restore IT operations rapidly. OMB M-07-16 sets out specific requirements for reporting incidents involving the loss or inappropriate disclosure of PII. For additional information, see Section 5.

Awareness, training, and education are distinct activities, each critical to the success of privacy and security programs.⁴⁵ Their roles related to protecting PII are briefly described below. Additional information on privacy education, training, and awareness is available in NIST SP 800-50, Building an Information Technology Security Awareness and Training Program.

Awareness efforts are designed to change behavior or reinforce desired PII practices. The purpose of awareness is to focus attention on the protection of PII. Awareness relies on using attention-grabbing techniques to reach all different types of staff across an organization. For PII protection, awareness methods include informing staff of new scams that are being used to steal identities, providing updates on privacy items in the news such as government data breaches and their effect on individuals and the organization, providing examples of how staff members have been held accountable for inappropriate actions, and providing examples of recommended privacy practices.

The goal of training is to build knowledge and skills that will enable staff to protect PII. Laws and regulations may specifically require training for staff, managers, and contractors. An organization should have a training plan and implementation approach, and an organization‘s leadership should communicate the seriousness of protecting PII to its staff. Organizational policy should define roles and responsibilities for training; training prerequisites for receiving access to PII; and training periodicity and refresher training requirements. To reduce the possibility that PII will be accessed, used, or disclosed inappropriately, all individuals that have been granted access to PII should receive appropriate training and, where applicable, specific role-based training. Depending on the roles and functions involving PII, important topics to address may include:

Education develops a common body of knowledge that reflects all of the various specialties and aspects of PII protection. It is used to develop privacy professionals who are able to implement privacy programs that enable their organizations to proactively respond to privacy challenges.

Privacy-specific safeguards are controls for protecting the confidentiality of PII. These controls provide types of protections not usually needed for other types of data. Privacy-specific safeguards help organizations collect, maintain, use, and disseminate data in ways that protect the confidentiality of the data.

The practice of minimizing the use, collection, and retention of PII is a basic privacy principle.⁴⁷ By limiting PII collections to the least amount necessary to conduct its mission, the organization may limit potential negative consequences in the event of a data breach involving PII. Organizations should consider the total amount of PII used, collected, and maintained, as well as the types and categories of PII used, collected, and maintained. This general concept is often abbreviated as the “minimum necessary” principle. PII collections should only be made where such collections are essential to meet the authorized business purpose and mission of the organization. If the PII serves no current business purpose, then the PII should no longer be used or collected.

Also, an organization should regularly review⁴⁸ its holdings of previously collected PII to determine whether the PII is still relevant and necessary for meeting the organization‘s business purpose and mission.⁴⁹ If PII is no longer relevant and necessary, then PII should be properly destroyed. The destruction or disposal of PII must be conducted in accordance with any litigation holds and the Federal Records Act and records control schedules approved by the National Archives and Records Administration (NARA).⁵⁰ Organizations should also ensure that retired hardware has been properly sanitized before disposal (e.g., no disk images contain PII, the hard drive has been properly sanitized).⁵¹ The effective management and prompt disposal of PII, in accordance with NARA-approved disposition schedules, will minimize the risk of unauthorized disclosure.

PIAs are structured processes for identifying and mitigating privacy risks, including risks to confidentiality, within an information system. According to OMB, PIAs are “structured reviews of how information is handled: (i) to ensure handling conforms to applicable legal, regulatory, and policy requirements, (ii) to determine the risks and effects of collecting, maintaining and disseminating information in identifiable form⁵² in an electronic information system, and (iii) to identify and evaluate protections and alternative processes for handling information to mitigate potential privacy risks.”⁵³ If used effectively, a PIA should address confidentiality risks at every stage of the system development life cycle (SDLC). Many organizations have established their own templates that provide the basis for conducting a PIA. The following are some topics that are commonly addressed through the use of a PIA:

Full data records are not always necessary, such as for some forms of research, resource planning, and examinations of correlations and trends. The term de-identified information is used to describe records that have had enough PII removed or obscured, also referred to as masked or obfuscated, such that the remaining information does not identify an individual and there is no reasonable basis to believe that the information can be used to identify an individual.⁵⁴ De-identified information can be re-identified

For example, de-identification could be accomplished by removing account numbers, names, SSNs, and any other identifiable information from a set of financial records. By de-identifying the information, a trend analysis team could perform an unbiased review on those records in the system without compromising the PII or providing the team with the ability to identify any individual. Another example is using health care test results in research analysis. All of the identifying PII fields can be removed, and the patient ID numbers can be obscured using pseudo-random data that is associated with a cross-reference table located in a separate system. The only means to reconstruct the original (complete) PII records is through authorized access to the cross-reference table.

Additionally, de-identified information can be aggregated for the purposes of statistical analysis, such as making comparisons, analyzing trends, or identifying patterns. An example is the aggregation and use of multiple sets of de-identified data for evaluating several types of education loan programs. The data describes characteristics of loan holders, such as age, gender, region, and outstanding loan balances. With this dataset, an analyst could draw statistics showing that 18,000 women in the 30-35 age group have outstanding loan balances greater than $10,000. Although the original dataset contained distinguishable identities for each person, the de-identified and aggregated dataset would not contain linked or readily identifiable data for any individual.

Anonymized information⁵⁷ is defined as previously identifiable information that has been de-identified and for which a code or other association for re-identification no longer exists.⁵⁸ Anonymizing information usually involves the application of statistical disclosure limitation techniques⁵⁹ to ensure the data cannot be re-identified, such as: 60

Using these techniques, the information is no longer PII, but it can retain its useful and realistic properties.⁶¹

Anonymized information is useful for system testing.⁶² Systems that are newly developed, newly purchased, or upgraded require testing before being introduced to their intended production (or live) environment. Testing generally should simulate real conditions as closely as possible to ensure the new or upgraded system runs correctly and handles the projected system capacity effectively. If PII is used in the test environment, it is required to be protected at the same level that it is protected in the production environment, which can add significantly to the time and expense of testing the system.

Randomly generating fake data in place of PII to test systems is often ineffective because certain properties and statistical distributions of PII may need to be retained to effectively test the system. There are tools available that substitute PII with synthetic data generated by anonymizing PII. The anonymized information retains the useful properties of the original PII, but the anonymized information is not considered to be PII. Anonymized data substitution is a privacy-specific protection measure that enables system testing while reducing the expense and added time of protecting PII. However, not all data can be readily anonymized (e.g., biometric data).

In addition to the PII-specific safeguards described earlier in this section, many types of security controls are available to safeguard the confidentiality of PII. Providing reasonable security safeguards is also a Fair Information Practice. Security controls are often already implemented on a system to protect other types of data processed, stored, or transmitted by the system. The security controls listed in NIST SP 800-53 address general protections of data and systems. The items listed below are some of the NIST SP 800-53 controls that can be used to help safeguard the confidentiality of PII. Note that some of these controls may not be in the recommended set of security controls for the baselines identified in NIST SP 800-53 (e.g., a control might only be recommended for high-impact systems). However, organizations may choose to provide greater protections than what is recommended; see Section 3.2 for a discussion of factors to consider when choosing the appropriate controls. In addition to the controls listed below, NIST SP 800-53 contains many other controls that can be used to help protect PII, such as incident response controls.

Handling incidents and breaches involving PII is different from regular incident handling and may require additional actions by an organization.⁶⁸ Breaches involving PII can receive considerable media attention, which can greatly harm an organization‘s reputation and reduce the public‘s trust⁶⁹ in the organization. Moreover, affected individuals can be subject to embarrassment, identity theft, or blackmail as the result of a breach involving PII. Due to these particular risks of harm, organizations should develop additional policies, such as determining when and how individuals should be notified, when and if a breach should be reported publicly, and whether to provide remedial services, such as credit monitoring, to affected individuals. Organizations should integrate these additional policies into their existing incident handling response policies.⁷⁰

Management of incidents involving PII often requires close coordination among personnel from across the organization, such as the CIO, CPO, system owner, data owner, legal counsel, and public relations officer. Because of this need for close coordination, organizations should establish clear roles and responsibilities to ensure effective management when an incident occurs.

FISMA requires Federal agencies to have procedures for handling information security incidents, and it directed OMB to ensure the establishment of a central Federal information security incident center, which is the U.S. Computer Emergency Readiness Team (US-CERT). Additionally, NIST provided guidance on security incident handling in NIST SP 800-61 Revision 1, Computer Security Incident Handling Guide. In 2007, OMB issued M-07-16, which provided specific guidance to Federal agencies for handling incidents involving PII.⁷¹

Incident response plans should be modified to handle breaches involving PII. Incident response plans should also address how to minimize the amount of PII necessary to adequately report and respond to a breach. NIST SP 800-61 Revision 1 describes four phases of handling security incidents. Specific policies and procedures for handling breaches involving PII can be added to each of the following phases identified in NIST SP 800-61: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. This section provides additional details on PII-specific considerations for each of these four phases.

Preparation requires the most effort because it sets the stage to ensure the breach is handled appropriately. Organizations should build their response plans for breaches involving PII into their existing incident response plans. The development of response plans for breaches involving PII requires organizations to make many decisions about how to handle breaches involving PII, and the decisions should be used to develop policies and procedures. The policies and procedures should be communicated to the organization‘s entire staff through training and awareness programs. Training may include tabletop exercises to simulate an incident and test whether the response plan is effective and whether the staff members understand and are able to perform their roles effectively. Training programs should also inform employees of the consequences of their actions for inappropriate use and handling of PII.

The organization should determine if existing processes are adequate, and if not, establish a new incident reporting method for employees to report suspected or known incidents involving PII. The method could be a phone hotline, email, online form, or a management reporting structure in which employees know to contact a specific person within the management chain. Employees should be able to report any breach involving PII immediately on any day, at any time. Additionally, employees should be provided with a clear definition of what constitutes a breach involving PII and what information needs to be reported. The following information is helpful to obtain from employees who are reporting a known or suspected breach involving PII.⁷²

Federal agencies are required to report all known or suspected breaches involving PII, in any format, to US-CERT within one hour.⁷³ To meet this obligation, organizations should proactively plan their breach notification response. A breach involving PII may require notification to persons external to the organization, such as law enforcement, financial institutions, affected individuals, the media, and the public.⁷⁴ Organizations should plan in advance how, when, and to whom notifications should be made. Organizations should conduct training sessions on interacting with the media regarding incidents. Additionally, OMB M-07-16 requires federal agencies to include the following elements in their plans for handling breach notification:

Additionally, organizations should establish a committee or person responsible for using the breach notification policy to coordinate the organization‘s response. Organizations also need to determine how incidents involving PII will be tracked within the organization.

The organization should also determine what circumstances require the organization to provide remedial assistance to affected individuals, such as credit monitoring services. The PII confidentiality impact level should be considered for this determination because it provides an analysis of the likelihood of harm for the loss of confidentiality for each instance of PII.

Organizations may continue to use their current detection and analysis technologies and techniques for handling incidents involving PII. However, adjustments to incident handling processes may be necessary, such as ensuring that the analysis process includes an evaluation of whether an incident involves PII. Detection and analysis should focus on both known and suspected breaches involving PII. Detection of an incident involving PII also requires reporting internally, to US-CERT, and externally, as appropriate.

Existing technologies and techniques for containment, eradication, and recovery may be used for breaches involving PII. However, changes to incident handling processes may be necessary, such as performing additional media sanitization steps when PII needs to be deleted from media during recovery. 76 PII should not be sanitized until a determination has been made about whether the PII must be preserved as evidence.⁷⁷ Particular attention should be paid to using proper forensics techniques⁷⁸ to ensure preservation of evidence. Additionally, it is important to determine whether PII was accessed and how many records or individuals were affected.

As with other security incidents, information learned through detection, analysis, containment, and recovery should be collected for sharing within the organization and with the US-CERT to help protect against future incidents. The incident response plan should be continually updated and improved based on the lessons learned during each incident. Lessons learned might also indicate the need for additional training, security controls, or procedures to protect against future incidents.

Additionally, the organization should use its response policy, developed during the planning phase, to determine whether the organization should provide affected individuals with remedial assistance. When providing notice to individuals, organizations should make affected individuals aware of their options, such as obtaining a free copy of their credit report, obtaining a freeze credit report, placing a fraud alert on their credit report, or contacting their financial institutions.⁷⁹

Exercises involving PII scenarios within an organization provide an inexpensive and effective way to build skills necessary to identify potential issues with how the organization identifies and safeguards PII. Individuals who participate in these exercises are presented with a brief PII scenario and a list of general and specific questions related to the scenario. After reading the scenario, the group then discusses each question and determines the most appropriate response for their organization. The goal is to determine what the participants would really do and to compare that with policies, procedures, and generally recommended practices to identify any discrepancies or deficiencies and decide upon appropriate mitigation techniques.

The general questions listed below are applicable to almost any PII scenario. After the general questions are scenarios, each of which is followed by additional scenario-specific questions. Organizations are encouraged to adapt these questions and scenarios for use in their own PII exercises. Also, additional scenarios and questions specific to PII incident handling are available from NIST SP 800-61 Revision 1, Computer Security Incident Handling Guide.⁸⁰

Scenario 1: A System Upgrade

An organization is redesigning and upgrading its physical access control systems, which consist of entry-way consoles that recognize ID badges, along with identity management systems and other components. As part of the redesign, several individual physical access control systems are being consolidated into a single system that catalogues and recognizes biometric template data (a facial image and fingerprint), employee name, employee identification number (an internal identification number used by the organization) and employee SSN. The new system will also contain scanned copies of “identity” documentation, including birth certificates, driver’s licenses, and/or passports. In addition, the system will maintain a log of all access (authorized or unauthorized) attempts by a badge. The log contains employee identification numbers and timestamps for each access attempt.

Scenario 2: Protecting Survey Data

Recently, an organization emailed to individuals a link to an online survey, which was designed to gather feedback about the organization‘s services. The organization identified each individual by name, email address, and an organization-assigned ID number. The majority of survey questions asked individuals to express their satisfaction or dissatisfaction with the organization, but there were also questions asking individuals to provide their ZIP code along with demographic details on their age, income level, educational background, and marital status.

The following are additional questions for this scenario:

Scenario 3: Completing Work at Home

An organization‘s employee needed to leave early for a doctor‘s appointment, but the employee was not finished with her work for the day and had no leave time available. Since she had the same spreadsheet application at home, she decided to email a data extract as an attachment to her personal email address and finish her work at home that evening. The data extract was downloaded from an access-controlled human resources database located on a server within the organization‘s security perimeter. The extract contained employee names, identification numbers, dates of birth, salary information, manager names, addresses, phone numbers, and positions. As she was leaving, she remembered that she had her personal USB flash drive in her purse. She decided the USB drive would be good to use in case she had an attachment problem with the email she had already sent. Although much of the USB drive‘s space was taken up with family photos she had shared with her coworkers earlier in the day, there was still enough room to add the data extract. She copied the data extract and dropped it in her purse as she left for her appointment. When she arrived home that evening, she plugged the USB drive into her family‘s computer and used her spreadsheet application to analyze the data.

The following are additional questions for this scenario:

Scenario 4: Testing Systems

An organization needed to test an upgrade to its fingerprint matching system before the upgrade could be introduced into the production environment. Because it is difficult to simulate fingerprint image and template data, the organization used real biometric image and template data to test the system. In addition to the fingerprint images and templates, the system also processed the demographic data associated with each fingerprint image, including name, age, sex, race, date of birth, and nationality. After successful completion of the testing, the organization upgraded its production system.

Privacy and security leadership and staff, as well as others, may have questions about identifying, handling, and protecting the confidentiality of personally identifiable information (PII). This appendix contains frequently asked questions (FAQ) related to PII. Organizations are encouraged to customize this FAQ and make it available to their user community.

PII is “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.”⁸¹

The following examples are meant to offer a cross-section of the types of information that could be considered PII, either singly or collectively, and is not an exhaustive list of all possibilities. Examples of PII include financial transactions, medical history, criminal history, employment history, individual‘s name, social security number, passport number, driver‘s license number, credit card number, vehicle registration, x-ray, patient ID number, and biometric data (e.g., retina scan, voice signature, facial geometry).⁸²

OMB defined the term individual, as used in the definition of PII, to mean a citizen of the United States or an alien lawfully admitted for permanent residence, which is based on the Privacy Act definition.⁸³ For the purpose of protecting the confidentiality of PII, organizations may choose to administratively expand the scope of application to foreign nationals without creating new legal rights. Expanding the scope may reduce administrative burdens and improve operational efficiencies in the protection of data by eliminating the need to maintain separate systems or otherwise separate data. Additionally, the status of citizen, alien, or legal permanent resident can change over time, which makes it difficult to accurately identify and separate the data of foreign nationals. Expanding the scope may also serve additional organizational interests, such as providing reciprocity for data sharing agreements with other organizations.

Agencies may also, consistent with individual practice, choose to extend the protections of the Privacy Act to foreign nationals without creating new judicially enforceable legal rights. For example, DHS has chosen to extend Privacy Act protections (e.g., access, correction) to foreign nationals whose data resides in mixed systems, which are systems of records with information about both U.S. persons and non-U.S. persons.⁸⁴

Organizations should consult with legal counsel to determine if they have an additional obligation to protect the confidentiality of the personal information relating to foreign nationals, such as the Immigration and Nationality Act, which requires the protection of the confidentiality of Visa applicant data.⁸⁵

With the increased use of computers for the processing and dissemination of data, the protection of PII has become more important to maintain public trust and confidence in an organization, to protect the reputation of an organization, and to protect against legal liability for an organization. Recently, organizations have become more concerned about the risk of legal liability due to the enactment of many federal, state, and international privacy laws, as well as the increased opportunities for misuse that accompany the increased processing and dissemination of PII.

In the United States, Federal privacy laws are generally sector-based. For example, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) applies to the health care sector, and the Gramm-Leach-Bliley Act of 1999 (GLBA) applies to the financial services sector. In contrast, many states have enacted their own generally applicable privacy laws, such as breach notification laws. Some U.S.-based organizations that conduct business abroad must also comply with international privacy laws, which vary greatly from country to country. Organizations are responsible for determining which laws apply to them based on sector and jurisdiction.

For Federal government agencies, the need to protect PII was first established by the Privacy Act of 1974. It required Federal agencies to protect PII and apply the Fair Information Practices to PII. Also, the Privacy Act required agencies to “establish appropriate administrative, technical, and physical safeguards to ensure the security and confidentiality of records and to protect against any anticipated threats or hazards to their security or integrity which could result in substantial harm, embarrassment, inconvenience, or unfairness to any individual on whom information is maintained.”

In response to the increased use of computers and the Internet to process government information, the E-Government Act of 2002 was enacted to ensure public trust in electronic government services. It required Federal agencies to conduct Privacy Impact Assessments (PIAs) and to maintain privacy policies on their web sites. The E-Government Act also directed OMB to issue implementation guidance to Federal agencies. In 2003, OMB issued M-03-22 to provide guidance on PIAs and web site privacy policies. OMB has continued to provide privacy guidance to Federal agencies on many PII protection topics such as remote access to PII, encryption of PII on mobile devices, and breach notification (see Appendix G for additional information).

Additionally, Federal agencies are required to comply with other privacy laws, such as the Children‘s Online Privacy Protection Act (COPPA) and HIPAA (only if the agency acts as a health care provider or other covered entity as defined by the statute).

The Privacy Act of 1974 is the foundation of public sector privacy law in the U.S. It applies only to Federal agencies and provides a statutory basis for the required use of Fair Information Practices. The Privacy Act pertains only to data maintained within a System of Records (SOR), which means any “group of any records under the control of any agency from which information is retrieved by the name of the individual or by some identifying number, symbol, or other identifying particular assigned to the individual.”⁸⁶ Record is defined broadly to include any item of information about an individual, both paper and electronic.

The basic provisions of the Privacy Act include the following:

Violations of the Privacy Act can result in civil and criminal liability.

Most information contained within a Privacy Act SOR is considered to be PII, but not all PII is contained within a Privacy Act SOR. Organizations that seek to protect systems (e.g., via security controls) containing PII may be able to realize efficiencies by coordinating with efforts to comply with the Privacy Act, as these activities will often be similar.

The E-Government Act of 2002 required Federal agencies to conduct PIAs, which are processes for identifying and mitigating privacy risks within an information system. PIAs should address risk at every stage of the system development life cycle (SDLC). Most organizations have established their own templates that provide the basis for conducting a PIA. The E-Government Act of 2002 requires Federal agencies to conduct PIAs when:

The E-Government Act authorized OMB to provide Federal agencies with guidance on conducting PIAs, which resulted in OMB Memorandum 03-22. The Memorandum provided examples of system changes that create new privacy risks and trigger the requirement for a new PIA:

The E-Government Act requires publication of PIAs,⁸⁸ which must analyze and describe the following information:

The Paperwork Reduction Act (PRA) gives OMB and other Federal agencies responsibilities for the management of information resources.⁸⁹ The PRA is relevant to PII protection for two major reasons. First, it places privacy among the responsibilities of agency CIOs. However, the extent to which agency CIOs are responsible for privacy depends on a number of factors, including whether the agency is covered by any other statutory mandate for the designation of a chief privacy officer (CPO).⁹⁰ Second, the PRA created a process for OMB review and approval of Federal agency information collections from the public. This process is relevant to PII protection because it provides a mechanism for agencies to limit the collection of PII, as mandated by the Fair Information Practice of Collection Limitation. It is also relevant to PII protection because its terms partly define the scope of E-Government Act PIAs. The purpose of the PRA information collection review process is to minimize the burdens of paperwork on the public, minimize the cost of information collections, and increase the quality of Federal information.⁹¹ The PRA requires Federal agencies to get clearance from OMB when an agency plans to collect information from ten or more persons using identical reporting, recordkeeping, or disclosure requirements. The term persons is defined broadly to include people, organizations, local government, etc., but it does not include Federal agencies or employees of Federal agencies when acting in their official capacities. Agencies must also provide notice of the collection in the Federal Register before submitting the information collection to OMB for clearance.

OMB reviews the proposed information collection and assigns a control number to the collection, which must be displayed on the collection form.

Depending on the type of information lost, an individual may suffer social, economic, or physical harm. If the information lost is sufficient to be exploited by an identity thief, the person can suffer, for example, from a loss of money, damage to credit, a compromise of medical records, threats, and/or harassment. The individual may suffer tremendous losses of time and money to address the damage. Other types of harm that may occur to individuals include denial of government benefits, blackmail, discrimination, and physical harm.

Organizations also face risks to their finances and reputation. If PII is misused, organizations may suffer financial losses in compensating the individuals, assisting them in monitoring their credit ratings, and addressing administrative concerns. In addition, recovering from a major breach is costly to many organizations in terms of time spent by key staff in coordinating and executing appropriate responses. If a loss of PII constitutes a violation of relevant law, the organization and/or its staff may be subject to criminal or civil penalties, or it may have to agree to receive close government scrutiny and oversight. Another major risk to organizations is that their public reputation and public confidence may be lost, potentially jeopardizing the organizations‘ ability to achieve their missions.

Key considerations to review are any legal requirements that could impact PII collections. One should ask what laws, regulations, and guidance are applicable to the organization considering the type of PII that is collected (e.g., Privacy Act, Paperwork Reduction Act, and the E-Government Act for general PII; HIPAA for health PII; GLBA for financial PII; COPPA for children‘s PII). An organization‘s legal counsel and privacy officer should always be consulted to determine whether there are restrictions on collecting PII.

Consistent with the Fair Information Practices of Collection Limitation and Use Limitation, one could more specifically ask if the collected PII is absolutely necessary to do business (i.e., does it support the business purpose of the system or the organization‘s mission?). If it does not serve a viable business purpose, then Federal agencies may not collect that PII. If the collection of PII does serve a business purpose, then it should be collected, used, shared, and disseminated appropriately.

In many cases, protection of PII is similar to protection of other data and includes protecting the confidentiality, integrity, and availability of the information. Most security controls used for other types of data are also applicable to the protection of PII. For PII, there are several privacy-specific safeguards, such as anonymization, minimization of PII collection, and de-identification.

In addition to protection requirements for PII, there are other requirements for the handling of PII. The Fair Information Practices provide best practice guidelines, such as Purpose Specification, Use Limitation, Accountability, and Data Quality. Moreover, the factors for assigning a confidentiality impact level to PII are different than other types of data. Breaches to the confidentiality of PII harm both the organization and the individual. Harm to individuals should be factored in strongly because of the magnitude of the potential harm, such as identity theft, embarrassment, and denial of benefits.

Laws, regulations, and guidance documents provide various terms and definitions used to describe personal information, such as information in identifiable form (IIF), system of records (SOR), and protected health information (PHI). Some of these are similar to the definition of PII used in this document. However, organizations should not use the term PII (as defined in this document) interchangeably with these terms and definitions because they are specific to their particular context. The table below provides examples of these other terms and definitions, and it is not intended to be comprehensive.

The Fair Information Practices, also known as Privacy Principles, are the framework for most modern privacy laws around the world. Several versions of the Fair Information Practices have been developed through government studies, Federal agencies, and international organizations. These different versions share common elements, but the elements are divided and expressed differently. The most commonly used versions are discussed in this appendix.⁹²

In 1973, the U.S. Department of Health, Education, and Welfare (HEW) (now the Department of Health and Human Services) issued a report entitled Records, Computers, and the Rights of Citizens (commonly referred to as the HEW Report). The report was the culmination of an extensive study into data processing in the public and private sectors. The HEW Report recommended that Congress enact legislation adopting a “Code of Fair Information Practices” for automated personal data systems. The recommended Fair Information Practices became the foundation for the Privacy Act of 1974. The HEW Report Fair Information Practices included the following:

In 1980, the Organisation for Economic Co-operation and Development (OECD)⁹³ adopted Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, which provide a framework for privacy that has been referenced in U.S. Federal guidance and internationally. The OECD Guidelines, along with the Council of Europe Convention,⁹⁴ became the foundation for the European Union’s Data Protection Directive.⁹⁵ The OECD Guidelines include the following Privacy Principles:

In 2004, the Federal CIO Council published the Federal Enterprise Architecture Security and Privacy Profile (FEA-SPP).⁹⁶ It included a set of privacy control families based on Fair Information Practices. The privacy control families were intended to provide guidance for integrating privacy requirements into the Federal Enterprise Architecture. In 2009, the CIO Council drafted a revised set of privacy control families.⁹⁷ The revised set contains the following privacy control families:

In 2004, the Asia-Pacific Economic Cooperation (APEC) ministers officially endorsed the Privacy Framework⁹⁸ developed within one of its committees. The APEC Privacy Framework was based on the OECD Privacy Guidelines and was developed to encourage electronic commerce among the member states and to build trust with the international community. The Privacy Framework includes the following Privacy Principles:

Selected terms used in the publication are defined below.

Aggregated Information: Information elements collated on a number of individuals, typically used for the purposes of making comparisons or identifying patterns.

Anonymized Information: Previously identifiable information that has been de-identified and for which a code or other association for re-identification no longer exists.

Confidentiality: “Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.”⁹⁹

Context of Use: The purpose for which PII is collected, stored, used, processed, disclosed, or disseminated.

De-identified Information: Records that have had enough PII removed or obscured such that the remaining information does not identify an individual and there is no reasonable basis to believe that the information can be used to identify an individual.

Distinguishable Information: Information that can be used to identify an individual.

Harm: Any adverse effects that would be experienced by an individual (i.e., that may be socially, physically, or financially damaging) or an organization if the confidentiality of PII were breached.

Linkable Information: Information about or related to an individual for which there is a possibility of logical association with other information about the individual.

Linked Information: Information about or related to an individual that is logically associated with other information about the individual.

Obscured Data: Data that has been distorted by cryptographic or other means to hide information. It is also referred to as being masked or obfuscated.

Personally Identifiable Information (PII): “Any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.”¹⁰⁰

PII Confidentiality Impact Level: The PII confidentiality impact level—low, moderate, or high— indicates the potential harm that could result to the subject individuals and/or the organization if PII were inappropriately accessed, used, or disclosed.

Privacy Impact Assessment (PIA): “An analysis of how information is handled that ensures handling conforms to applicable legal, regulatory, and policy requirements regarding privacy; determines the risks and effects of collecting, maintaining and disseminating information in identifiable form in an electronic information system; and examines and evaluates protections and alternative processes for handling information to mitigate potential privacy risks.”¹⁰¹

System of Records: “A group of any records under the control of any agency from which information is retrieved by the name of the individual or by some identifying number, symbol, or other identifying particular assigned to the individual.”¹⁰²

Traceable: Information that is sufficient to make a determination about a specific aspect of an individual's activities or status.

Selected acronyms and abbreviations used in the publication are defined below.

APEC — Asia-Pacific Economic Cooperation

CD — Compact Disc

C.F.R. — Code of Federal Regulations

CIO — Chief Information Officer

CIPSEA — Confidential Information Protection and Statistical Efficiency Act

COPPA — Children’s Online Privacy Protection Act

CPO — Chief Privacy Officer

DHS — U.S. Department of Homeland Security

FAQ — Frequently Asked Questions

FEA-SPP — Federal Enterprise Architecture Security and Privacy Profile

FIPS — Federal Information Processing Standards

FISMA — Federal Information Security Management Act

GAO — Government Accountability Office

GLBA — Gramm-Leach-Bliley Act

GRS — General Record Schedule

HEW — U.S. Department of Health, Education, and Welfare

HIPAA — Health Insurance Portability and Accountability Act

ID — Identification

IIF — Information in Identifiable Form

IIHI — Individually Identifiable Health Information

IP — Internet Protocol

IPA — Initial Privacy Assessment

IRS — Internal Revenue Service

ISA — Interconnection Security Agreement

IT — Information Technology

ITL — Information Technology Laboratory

MAC — Media Access Control

NARA — National Archives and Records Administration

NIST — National Institute of Standards and Technology

NPPI — Non-Public Personal Information

OECD — Organisation for Economic Co-operation and Development

OMB — Office of Management and Budget

OPM — Office of Personnel Management

PDA — Personal Digital Assistant

PHI — Protected Health Information

PIA — Privacy Impact Assessment

PII — Personally Identifiable Information

PRA — Paperwork Reduction Act

PTA — Privacy Threshold Analysis

SDLC — System Development Life Cycle

SOR — System of Records

SORN — System of Records Notice

SP — Special Publication

SSN — Social Security Number

URL — Uniform Resource Locator

USB — Universal Serial Bus

U.S.C. — United States Code

US-CERT — United States Computer Emergency Readiness Team

Personnel involved with protecting PII and concerned about individual and organizational impact may want to review the following privacy laws and requirements that apply to Federal agencies.¹⁰³ Additionally, OMB has issued several memoranda that provide policy guidance and instructions for the implementation of privacy requirements.

107 NIST SP 800-63-1 was released as a draft in December 2008, http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf.